Advanced ALB Ingress usage-Container Compute Service(ACS)-阿里云帮助中心

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

You have created 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.

Create an Ingress with a domain name

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 by using the specified domain name.

Replace ADDRESS with the domain name of the ALB instance, which you can obtain by running kubectl get ing.
```
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
            pathType: ImplementationSpecific

Run the following command to access the application by using the domain name.

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

Forward requests based on URL paths

ALB Ingress routes requests based on URL paths. You can set the pathType field to specify a match rule. The pathType field supports three match rules: Exact, ImplementationSpecific (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 more specific `/aaa` rule path.
Prefix	Configure two rules at the same time: /aaa /	/aaa/ccc	Yes, the request path matches the more specific `/aaa` rule path.
Prefix	Configure two rules at the same time: /aaa /	/ccc	Yes, the request path matches 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

You can perform the following steps to configure different URL match policies.

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, which you can obtain by running kubectl get ing.
```
curl <ADDRESS>/hello
```
Expected output:
```
{"hello":"coffee"}
```

ImplementationSpecific: the default match policy

In ALB Ingress, this is handled the same as 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: 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 kubectl get ing.
```
curl <ADDRESS>/hello
```
Expected output:
```
{"hello":"coffee"}
```

Prefix

Prefix matching is performed on URL paths that are separated by /. The match is case-sensitive, and the elements in the path are matched one by one.

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 kubectl get ing.
```
curl <ADDRESS>/hello
```
Expected output:
```
{"hello":"coffee"}
```

Configure health checks

You can configure health checks for ALB Ingresses by 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 the context path.
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      # Configure the context path.
      - path: /coffee
        pathType: ImplementationSpecific
        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. Default value: 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

Redirect HTTP requests to HTTPS on port 443 by adding the alb.ingress.kubernetes.io/ssl-redirect: "true" annotation.

Important

You cannot create listeners by 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 specify the protocol for an ALB Ingress, add the alb.ingress.kubernetes.io/backend-protocol: "https" or alb.ingress.kubernetes.io/backend-protocol: "grpc" annotation. To use an Ingress to route gRPC traffic, the corresponding domain name must have an SSL certificate and use TLS for communication. The following example configures the gRPC protocol:

Note

You cannot modify the backend protocol. If you need 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 define custom forwarding conditions, you can write regular expressions in the path field. The following is an example 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 URL rewriting. To enable 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 of the ${number} format require the path type to be set to Prefix.
By default, the path field does not support regular expression characters, such as the asterisk (*) and question mark (?). To use regular expression characters in the path, you must also add the alb.ingress.kubernetes.io/use-regex: "true" annotation.
The path value must start with a forward slash (/).

Note

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

You can specify one or more regular expressions with capture groups (()) in the Ingress path. The rewrite-target annotation can then reference up to three captured variables: ${1}, ${2}, and ${3}.
Variables that match the regular expressions are concatenated to form the path that overwrites the original path.
Rewrite logic with regular expression substitution works as follows: A client's request path is matched against a regular expression that contains one or more capture groups (()). The rewrite-target annotation contains one or more variables, such as ${1}, ${2}, or ${3}, that are replaced with the captured values.

For example, if the Ingress path 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 request path matches /sys/(.*)/(.*)/aaa. The rewrite-target annotation then replaces ${1} with ccc and ${2} with bbb. As a result, the 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 allows you to 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:

Rules across different Ingresses are prioritized based on the lexicographical order of their namespace/name. A smaller value in the lexicographical order indicates a higher priority.
Rules within the same Ingress are prioritized based on their order in the rules field. Rules that appear earlier have a higher priority.

If you prefer not to modify the namespace/name of an Ingress, you can add an annotation to define the priority of its forwarding rules:

Note

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

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 advanced routing capabilities, including support for canary releases based on headers, cookies, and weights. To enable the canary release feature, add the alb.ingress.kubernetes.io/canary: "true" annotation. You can then use different annotations to implement various canary release strategies:

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: Matches the value of a request header. This rule allows you to specify a custom request header value, but it must be used together with alb.ingress.kubernetes.io/canary-by-header.
- If the header and header-value in a request match the specified values, traffic is routed to the canary service.
- For requests with other header values, the header rule is ignored, and traffic is routed to other canary services based on rule priority.
When the request header is location: hz, the request is routed to the canary service. Otherwise, traffic is routed based on weight. The following is an example 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 a cookie.

If the value of the specified cookie is always, traffic is routed to the canary service.
If the value of the specified cookie is never, traffic is not routed to the canary service.

Note

Cookie-based canary release does not support custom values. The value must be either always or never.

If a request's cookie is demo=always, the request is routed to the canary service. The following is an example 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: Sets the percentage of requests (as an integer from 0 to 100) to be sent to a specified service.

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 by using annotations

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

alb.ingress.kubernetes.io/sticky-session: Specifies whether to enable sticky sessions. Valid values: true or false. Default value: false.
alb.ingress.kubernetes.io/sticky-session-type: Specifies how to handle cookies for sticky sessions. Valid values: Insert or Server. Default value: Insert.
- Insert: The load balancer inserts a cookie (SERVERID) into the response when a client first visits. Subsequent requests with this cookie are routed to the same backend server.
- Server: The load balancer rewrites a user-defined cookie. Subsequent requests with the new cookie are routed to the same backend server.
Note
This parameter takes effect only when alb.ingress.kubernetes.io/sticky-session is set to true.
alb.ingress.kubernetes.io/cookie-timeout: The cookie timeout period. Valid values: 1 to 86,400. Unit: seconds. Default value: 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 the context path.
      - path: /tea2
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port: 
              number: 80
      # Configure the context path.
      - path: /coffee2
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port: 
              number: 80

Specify a load balancing algorithm for backend server groups

Specify a load balancing algorithm for a server group by adding the alb.ingress.kubernetes.io/backend-scheduler annotation. The following is an example configuration:

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 based on your business requirements. 
    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 are the valid values for the alb.ingress.kubernetes.io/backend-scheduler load balancing algorithm:

wrr: Weighted round-robin (default). Backend servers with higher weights receive more requests.
wlc: Weighted least connections. Distributes requests based on server weight and the number of active connections. Among servers with the same weight, the one with the fewest connections is chosen.
sch: Uses a consistent hash based on the source IP.
uch: Consistent hashing based on a URL parameter. When using uch, you must also 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 by 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`.

Configure persistent connections

Traditional load balancers use short-lived connections, which can cause bottlenecks in high-performance systems. Persistent connections reduce this overhead and improve performance. You can enable persistent connections in an ALB Ingress by adding the alb.ingress.kubernetes.io/backend-keepalive: "true" annotation. The following is an example:

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 QPS throttling for forwarding rules. The throttling value must be an integer from 1 to 100,000. To configure QPS throttling for an ALB Ingress, add the alb.ingress.kubernetes.io/traffic-limit-qps annotation. The following is an example:

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