Advanced ALB Ingress configurations - Container Compute Service

An Application Load Balancer (ALB) Ingress is an API object that provides Layer 7 load balancing to manage external access to Services in a Kubernetes cluster. This topic describes how to use ALB Ingresses in Alibaba Cloud Container Compute Service (ACS) clusters to forward requests to backend server groups based on domain names and URL paths, redirect HTTP requests to HTTPS, and implement canary releases.

Prerequisites

An ACS cluster is created. For more information, see Create an ACS cluster.
An AlbConfig object is created. For more information, see Getting started with ALB Ingress.

Forward requests based on domain names

Perform the following steps to create an Ingress with a domain name and an Ingress without a domain name, and then use the Ingresses to forward requests.

Forwarding Requests Based on Normal Domains

Use the following template to create a Deployment, a Service, and an Ingress. Requests to the domain name of the Ingress are forwarded to the Service.

apiVersion: v1
kind: Service
metadata:
  name: demo-service
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: demo.domain.ingress.top
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Run the following command to access the application using the specified domain name.
Replace ADDRESS with the domain name of the ALB instance, which you can retrieve by running the kubectl get ing command.
```
curl -H "host: demo.domain.ingress.top" <ADDRESS>/hello
```
Expected output:
```
{"hello":"coffee"}
```

Create an Ingress without a domain name

The following template shows the configuration of the Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - host: ""
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello

Run the following command to access the application using the domain name.
Replace ADDRESS with the domain name of the ALB instance. You can obtain this domain name by running the kubectl get ing command.
```
curl <ADDRESS>/hello
```
Expected output:
```
{"hello":"coffee"}
```

Forward requests based on URL paths

ALB Ingress can forward requests based on URL paths. You can set the pathType field to specify a URL matching policy. pathType supports three match types: Exact, ImplementationSpecific (the default), and Prefix.

Note

URL match policies may conflict with each other. When conflicting URL match policies exist, requests are matched against these policies in the descending order of policy priorities. For more information, see Configure forwarding rule priorities.

Match mode	Rule	URL path	Whether the URL path matches the rule
Prefix	/	(All paths)	Yes
Prefix	/foo	/foo /foo/	Yes
Prefix	/foo/	/foo /foo/	Yes
Prefix	/aaa/bb	/aaa/bbb	No
Prefix	/aaa/bbb	/aaa/bbb	Yes
Prefix	/aaa/bbb/	/aaa/bbb	Yes. The URL path ignores the trailing forward slash (/) of the rule.
Prefix	/aaa/bbb	/aaa/bbb/	Yes. The rule matches the trailing forward slash (/) of the URL path.
Prefix	/aaa/bbb	/aaa/bbb/ccc	Yes. The rule matches the subpath of the URL path.
Prefix	Configure two rules at the same time: / /aaa	/aaa/ccc	Yes. The request path matches the `/` prefix of the rule path.
Prefix	Configure two rules at the same time: /aaa /	/aaa/ccc	Yes. The request path matches the `/aaa` prefix of the rule path.
Prefix	Configure two rules at the same time: /aaa /	/ccc	Yes. The request path matches the `/` prefix of the rule path.
Prefix	/aaa	/ccc	No
Exact or ImplementationSpecific	/foo	/foo	Yes
Exact or ImplementationSpecific	/foo	/bar	No
Exact or ImplementationSpecific	/foo	/foo/	No
Exact or ImplementationSpecific	/foo/	/foo	No

The following are examples of the three matching methods:

Exact

The following template shows the configuration of the Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-path
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /hello
          backend:
            service:
              name: demo-service
              port: 
                number: 80
          pathType: Exact

Run the following command to access the application.
Replace ADDRESS with the domain name of the ALB instance. You can run the kubectl get ing command to obtain the domain name.
```
curl <ADDRESS>/hello
```
Expected output:
```
{"hello":"coffee"}
```

ImplementationSpecific: the default match policy

In an ALB Ingress, this policy is handled in the same way as the Exact policy.

The following template shows the configuration of the Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-path
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /hello
          backend:
            service:
              name: demo-service
              port:
                number: 80
          pathType: ImplementationSpecific

Run the following command to access the application.
Replace ADDRESS with the domain name of the ALB instance, which you can obtain by running the kubectl get ing command.
```
curl <ADDRESS>/hello
```
Expected output:
```
{"hello":"coffee"}
```

Prefix

This policy performs a case-sensitive prefix match on URL path elements that are delimited by /.

The following template shows the configuration of the Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-path-prefix
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /
          backend:
            service:
              name: demo-service
              port:
                number: 80
          pathType: Prefix

Run the following command to access the application.
Replace ADDRESS with the domain name of the ALB instance, which you can obtain by running the kubectl get ing command.
```
curl <ADDRESS>/hello
```
Expected output:
```
{"hello":"coffee"}
```

Configure health checks

You can configure health checks for ALB Ingresses using the following annotations. The following YAML template provides an example on how to create an Ingress for which health checks are enabled.

The following YAML template provides an example on how to create an Ingress that has health check enabled:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/healthcheck-enabled: "true"
    alb.ingress.kubernetes.io/healthcheck-path: "/"
    alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-httpcode: "http_2xx"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
    alb.ingress.kubernetes.io/healthy-threshold-count: "3"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      # Configure a context path.
      - path: /tea
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      # Configure a context path.
      - path: /coffee
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

The following table describes the parameters in the YAML template.

Parameter	Description
alb.ingress.kubernetes.io/healthcheck-enabled	(Optional) Specifies whether to enable health checks. By default, this feature is disabled (false).
alb.ingress.kubernetes.io/healthcheck-path	Optional. The URL path based on which health checks are performed. Default value: /. Enter the URL of the web page on which you want to perform health checks. We recommend that you enter the URL of a static web page. The URL must be 1 to 80 characters in length, and can contain letters, digits, hyphens (-), forward slashes (/), periods (.), percent signs (%), question marks (?), number signs (#), and ampersands (&). The URL can also contain the following extended characters: _ ; ~ ! ( ) * [ ] @ $ ^ : ' , +. The URL must start with a forward slash (/). By default, the ALB instance sends HTTP HEAD requests to the default application homepage configured on a backend Elastic Compute Service (ECS) instance to perform health checks. The ALB instance sends the requests to the private IP address of the ECS instance. If you do not want to use the default application homepage for health checks, you must specify a URL path.
alb.ingress.kubernetes.io/healthcheck-protocol	Optional. The protocol that is used for health checks. HTTP: The ALB instance sends HEAD or GET requests to a backend server to simulate access from a browser and check whether the backend server is healthy. This is the default protocol. TCP: The ALB instance sends TCP SYN packets to a backend server to check whether the port of the backend server is available to receive requests.
alb.ingress.kubernetes.io/healthcheck-method	Optional. The request method that is used for health checks. HEAD: By default, the ALB instance sends HEAD requests to a backend server to perform HTTP health checks. Make sure that your backend server supports HEAD requests. If your backend server does not support the HEAD method or the HEAD method is disabled, health checks may fail. In this case, you can use the GET method. GET: If the size of a response exceeds 8 KB, the response is fragmented. This does not affect the health check result.
alb.ingress.kubernetes.io/healthcheck-httpcode	The status codes that are returned when backend servers pass health checks. Valid values: http_2xx (default), http_3xx, http_4xx, and http_5xx.
alb.ingress.kubernetes.io/healthcheck-timeout-seconds	The timeout period of a health check. If a backend server does not respond within the specified timeout period, the server fails to pass the health check. Valid values: 1 to 300. Default value: 5. Unit: seconds.
alb.ingress.kubernetes.io/healthcheck-interval-seconds	The interval between two consecutive health checks. Unit: seconds. Valid values: 1 to 50. Default value: 2. Unit: seconds.
alb.ingress.kubernetes.io/healthy-threshold-count	The number of times that an unhealthy backend server must consecutively pass health checks before the server is considered healthy. Valid values: 2 to 10. Default value: 3.
alb.ingress.kubernetes.io/unhealthy-threshold-count	The number of times that a healthy backend server must consecutively fail health checks before the server is considered unhealthy. Valid values: 2 to 10. Default value: 3.

Configure a redirection from HTTP requests to HTTPS requests

You can set the alb.ingress.kubernetes.io/ssl-redirect: "true" annotation in an ALB Ingress to redirect HTTP requests to HTTPS port 443.

Important

You cannot create listeners using an ALB Ingress. To ensure that an ALB Ingress can work as expected, you need to specify the ports and protocols of listeners in an AlbConfig, and then associate the listeners with Services in the ALB Ingress. For more information about how to create ALB listeners, see Use AlbConfigs to configure ALB listeners.

Example:

apiVersion: v1
kind: Service
metadata:
  name: demo-service-ssl
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo-ssl
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-ssl
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-ssl
  template:
    metadata:
      labels:
        app: demo-ssl
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo-ssl
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/ssl-redirect: "true"
  name: demo-ssl
  namespace: default
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - ssl.alb.ingress.top
  rules:
    - host: ssl.alb.ingress.top
      http:
        paths:
          - backend:
              service:
                name: demo-service-ssl
                port: 
                  number: 80
            path: /
            pathType: Prefix

Configure HTTPS or gRPC as the backend protocol

ALB supports HTTPS and gRPC as backend protocols. To configure the backend protocol for an ALB Ingress, you only need to set the alb.ingress.kubernetes.io/backend-protocol: "grpc" or alb.ingress.kubernetes.io/backend-protocol: "https" annotation. To use an Ingress to forward gRPC services, the corresponding domain name must have an SSL certificate and use the TLS protocol. The following example shows a sample configuration for the gRPC protocol:

Note

You cannot modify the backend protocol. To change the protocol, delete and rebuild the Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-protocol: "grpc"
  name: lxd-grpc-ingress
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:  
      - path: /
        pathType: Prefix
        backend:
          service:
            name: grpc-demo-svc
            port:
              number: 9080

Configure regular expressions

To configure custom forwarding conditions, you can write regular expressions in the path field. The following example shows a sample configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/use-regex: "true" # Supports regular expressions in the path field. 
   alb.ingress.kubernetes.io/conditions.service-a: | # The Service specified in the annotation must be an existing Service in the cluster, and the Service name must be the same as the Service name in backend of the rule field. 
     [{
       "type": "Path",
       "pathConfig": {
           "values": [
              "~*^/pathvalue1", # The regular expression must follow the regular expression flag ~ *. 
              "/pathvalue2" # No need to add ~ * before the path for exact match. 
           ]
       }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: service-a
            port:
              number: 88

Configure rewrite rules

ALB supports the rewrite feature. To configure this feature for an ALB Ingress, add the alb.ingress.kubernetes.io/rewrite-target: /path/${2} annotation. The following rules apply:

In the rewrite-target annotation, variables in the ${number} format must be configured on a path whose pathType is set to Prefix.
By default, you cannot use regular expression symbols, such as * and ?, in the path field. You must configure the rewrite-target annotation to use regular expression symbols.
The path must start with a /.

Note

If you want to specify regular expressions in rewrite rules, take note of the following items:

You can write one or more regular expressions that contain multiple sets of parentheses () in the path field of an Ingress. However, the rewrite path in the rewrite-target annotation can use a maximum of three variables: ${1}, ${2}, and ${3}.
Variables that match the regular expressions are concatenated to form the path that overwrites the original path.
The logic for rewriting by regular expression replacement is as follows: A client request matches a regular expression that contains multiple sets of parentheses (), and the rewrite-target annotation contains one or more of the ${1}, ${2}, and ${3} variables.

For example, if the path of an Ingress is set to /sys/(.*)/(.*)/aaa and the rewrite-target annotation is set to /${1}/${2}, when a client sends a request to the path /sys/ccc/bbb/aaa, the path matches /sys/(.*)/(.*)/aaa. The rewrite-target annotation replaces ${1} with ccc and ${2} with bbb. The final request path that the backend server receives is /ccc/bbb.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true" # Supports regular expressions in the path field. 
    alb.ingress.kubernetes.io/rewrite-target: /path/${2} # Variables that match the regular expressions are concatenated to form the path that overwrites the original path. 
  name: rewrite-ingress
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /something(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

Configure custom listening ports

ALB Ingresses allow you to configure custom listening ports. This lets you expose a service through ports 80 and 443 at the same time.

Important

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Configure forwarding rule priorities

By default, forwarding rules are prioritized based on the following rules:

Ingresses are sorted by the lexicographical order of their namespace/name. A smaller value indicates a higher priority.
Within the same Ingress, rules are sorted based on their order in the rule field. Rules that are configured earlier have a higher priority.

If you do not want to modify the namespace/name of the Ingress, you can configure the following Ingress annotation to define forwarding rule priorities:

Note

Rule priorities must be unique within the same listener. You can use the alb.ingress.kubernetes.io/order annotation to specify the priority of an Ingress. The value must be an integer from 1 to 1,000. A smaller value indicates a higher priority. The default priority is 10. To assign a higher priority, specify a smaller value.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
   alb.ingress.kubernetes.io/order: "2"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Use annotations to perform phased releases

ALB provides complex routing capabilities and supports canary releases based on headers, cookies, and weights. You can implement canary releases by setting annotations. To enable canary releases, you must set the alb.ingress.kubernetes.io/canary: "true" annotation. You can use different annotations to implement different canary release features:

Note

Canary releases that use different rules take effect in the following order: header-based > cookie-based > weight-based.
When you perform canary releases to test a new application version, do not modify the original Ingress rules. Otherwise, access to the application may be interrupted. After the new application version passes the test, replace the backend Service used by the earlier application version with the backend Service used by the new application version. Then, delete the Ingress rules for implementing canary releases.

alb.ingress.kubernetes.io/canary-by-header and alb.ingress.kubernetes.io/canary-by-header-value: This rule specifies the value of the request header and must be used with alb.ingress.kubernetes.io/canary-by-header.
- If the header and header-value in a request match the set values, the request is allocated to the phased release service endpoint.
- For other header values, the header is ignored, and request traffic is allocated based on phased release priority to the phased release service set by other rules.
If the request header is location: hz, the request is routed to the canary release service. Requests with other headers are routed based on the canary release weight. The following example shows a sample configuration:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "1"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-header: "location"
    alb.ingress.kubernetes.io/canary-by-header-value: "hz"
  name: demo-canary
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-hello
                port: 
                  number: 80
            path: /hello
            pathType: ImplementationSpecific
```

alb.ingress.kubernetes.io/canary-by-cookie: Splits traffic based on cookies.

If the cookie value is set to always, request traffic is allocated to the phased release service endpoint.
If the cookie value is set to never, request traffic is not allocated to the phased release service endpoint.

Note

Cookie-based canary releases support only the always and never values. Custom values are not supported.

If the request cookie is demo=always, the request is routed to the canary release service. The following example shows a sample configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "2"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-by-cookie: "demo"
  name: demo-canary-cookie
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-hello
                port: 
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

alb.ingress.kubernetes.io/canary-weight: Specifies the percentage of requests that are routed to the canary service. The value must be an integer from 0 to 100.

In the following example, the percentage of requests that are routed to the new application version is set to 50%:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "3"
    alb.ingress.kubernetes.io/canary: "true"
    alb.ingress.kubernetes.io/canary-weight: "50"
  name: demo-canary-weight
  namespace: default
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-hello
                port: 
                  number: 80
            path: /hello
            pathType: ImplementationSpecific

Configure session persistence using annotations

ALB Ingresses allow you to configure session persistence using the following annotations:

alb.ingress.kubernetes.io/sticky-session: Specifies whether to enable session persistence. Valid values: true or false. Default value: false.
alb.ingress.kubernetes.io/sticky-session-type: The method for handling cookies. Valid values: Insert or Server. Default value: Insert.
- Insert: Inserts a cookie. When a client sends the first request, Server Load Balancer inserts a cookie (SERVERID) into the response. When the client sends the next request with this cookie, Server Load Balancer forwards the request to the previously recorded backend server.
- Server: Rewrites a cookie. When Server Load Balancer finds a user-defined cookie, it rewrites the original cookie. When the client sends the next request with the new cookie, Server Load Balancer forwards the request to the previously recorded backend server.
Note
This parameter takes effect only when StickySessionEnabled is set to true for the server group.
alb.ingress.kubernetes.io/cookie-timeout: The cookie timeout period in seconds. You can specify an integer from 1 to 86,400. The default value is 1000.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-v3
  annotations:
    alb.ingress.kubernetes.io/sticky-session: "true"
    alb.ingress.kubernetes.io/sticky-session-type: "Insert"
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      # Configure a context path. 
      - path: /tea2
        backend:
          service:
            name: tea-svc
            port: 
             number: 80
      # Configure a context path. 
       - path: /coffee2
         backend:
           service:
              name: coffee-svc
              port: 
               number: 80

Specify a load balancing algorithm for backend server groups

ALB Ingress lets you specify a load balancing algorithm for a server group by setting the Ingress annotation alb.ingress.kubernetes.io/backend-scheduler. The following example shows a sample configuration. By default, the cluster version must be 1.19 or later:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-scheduler: "uch" # Replace uch with wrr, sch, or wlc as needed. 
    alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # This parameter is required only if the load balancing algorithm is uch. You do not need to configure this parameter if the scheduling algorithm is wrr, sch, or wlc. 
  name: cafe-ingress
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

The following values are supported for the alb.ingress.kubernetes.io/backend-scheduler annotation:

wrr: This is the default value. Requests are distributed to backend servers based on their weights. Backend servers with higher weights receive more requests.
wlc: Requests are distributed to backend servers based on their weights and the number of existing connections. If backend servers have the same weight, the server with the fewest connections is selected.
sch: Requests from the same source IP address are routed to the same backend server.
uch: Requests that contain the same URL parameter are routed to the same backend server. If you set the scheduling algorithm to uch, you can use the alb.ingress.kubernetes.io/backend-scheduler-uch-value annotation to specify the URL parameter for consistent hashing.

Configure CORS

The following code block shows a sample Cross-origin Resource Sharing (CORS) configuration supported by ALB Ingresses:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/enable-cors: "true"
    alb.ingress.kubernetes.io/cors-expose-headers: ""
    alb.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
    alb.ingress.kubernetes.io/cors-allow-credentials: "true"
    alb.ingress.kubernetes.io/cors-max-age: "600"

spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

Parameter	Description
`alb.ingress.kubernetes.io/cors-allow-origin`	The URLs that can be used to access resources on the origin server using a browse. Separate multiple URLs with commas (,). Each URL must start with http:// or https:// and contain a valid domain name or a top-level wildcard domain name. Default value: `*`. Example: `alb.ingress.kubernetes.io/cors-allow-origin: "https://example.com:4443, http://aliyundoc.com, https://example.org:1199"`.
`alb.ingress.kubernetes.io/cors-allow-methods`	The HTTP methods that are allowed. The values are not case-sensitive. Separate multiple HTTP methods with commas (,). Default value: `GET, PUT, POST, DELETE, PATCH, OPTIONS`. Example: `alb.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS"`.
`alb.ingress.kubernetes.io/cors-allow-headers`	The request headers that are allowed. The request headers can contain letters, digits, underscores (_), and hyphens (-). Separate multiple request headers with commas (,). Default value: `DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization`. Example: `alb.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For, X-app123-XPTO"`.
`alb.ingress.kubernetes.io/cors-expose-headers`	The headers that can be exposed. The headers can contain letters, digits, underscores (_), hyphens (-), and asterisks (). Separate multiple headers with commas (,). Default value: `empty`. Example: `alb.ingress.kubernetes.io/cors-expose-headers: ", "X-CustomResponseHeader"`.
`alb.ingress.kubernetes.io/cors-allow-credentials`	Specifies whether to include credentials in CORS requests. Default value: `true`. Example: `alb.ingress.kubernetes.io/cors-allow-credentials: "false"`.
`alb.ingress.kubernetes.io/cors-max-age`	The maximum period of time for which a preflight request that uses the OPTIONS method can be cached. Configure this parameter for complex requests. Valid values: -1 to 172800. Unit: seconds. Default value: `172800`.

Backend persistent connections

Traditional load balancers use short-lived connections to access backend server groups. Each request requires a new TCP connection to be established and then terminated. This can create a network connectivity bottleneck in high-performance systems. Server Load Balancer supports persistent connections to backend servers. This feature reduces the resource consumption of the connection layer and significantly improves processing performance. You can use the alb.ingress.kubernetes.io/backend-keepalive annotation to enable persistent connections for an ALB Ingress. The following example shows a sample configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-keepalive: "true"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

Configure QPS throttling

ALB supports queries per second (QPS) throttling for forwarding rules. The throttling value must be an integer from 1 to 100,000. For an ALB Ingress, you only need to set the alb.ingress.kubernetes.io/traffic-limit-qps annotation. The following example shows a sample configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/traffic-limit-qps: "50"
spec:
  ingressClassName: alb
  rules:
   - host: demo.alb.ingress.top
     http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80