All Products
Search
Document Center

Container Service for Kubernetes:Use AlbConfigs to configure ALB instances

Last Updated:Jan 21, 2025

An AlbConfig is a CustomResourceDefinition (CRD) that Container Service for Kubernetes (ACK) provides for the Application Load Balancer (ALB) Ingress controller. The ALB Ingress controller uses AlbConfigs to configure ALB instances and listeners. This topic describes how to create, modify, and update an AlbConfig, and how to enable Simple Log Service (SLS).

Table of contents

Category

Feature

Reference

ALB instance configurations

ALB management

Reused ALB instance management

Advanced configurations

ALB listener configurations

Listener management

Advanced configurations

Security settings

Prerequisites

Annotation usage notes

  • To modify or update resource configurations, we recommend that you use the kubectl edit command. If you need to use the kubectl apply command to modify or update resources, you must first run the kubectl diff command to preview the changes and make sure that the changes are as expected before you run the kubectl apply command. Then, run the kubectl apply command to apply the changes to the resources in your cluster.

  • If you use the Flannel network plug-in, the backend Services of the ALB Ingress gateway must be of the NodePort or LoadBalancer type.

Create an AlbConfig

An AlbConfig is used to configure an ALB instance. If you want to configure multiple ALB instances, you must create multiple AlbConfigs. To create an AlbConfig, perform the following steps:

Important

When you install the ALB Ingress controller, if you select Create or Select Existing for the Gateway Source parameter, the controller automatically creates an AlbConfig named alb and an IngressClass named alb.

  1. Create a file named alb.yaml and copy the following content to the file. The file is used to create an AlbConfig.

    apiVersion: alibabacloud.com/v1
    kind: AlbConfig
    metadata:
      name: alb
    spec:
      config:
        name: alb
        addressType: Internet
        zoneMappings:               
        - vSwitchId: vsw-uf6ccg2a9g71hx8go****  # Replace the value with the ID of the vSwitch that you want to use. 
          allocationId: eip-asdfas****          # Replace the value with your elastic IP address (EIP) ID. The default option is to automatically assign a public IP address. 
        - vSwitchId: vsw-uf6nun9tql5t8nh15****
          allocationId: eip-dpfmss****          # Replace the value with the EIP ID. 
      listeners:
        - port: 80
          protocol: HTTP

    Parameter

    Description

    spec.config.name

    The name of the ALB instance.

    spec.config.addressType

    The type of IP address that the ALB instance uses to provide services. Valid values:

    • Internet: The ALB instance uses a public IP address. The domain name of the Ingress is resolved to the public IP address. Therefore, the ALB instance can be accessed over the Internet. This is the default value.

    • Intranet: The ALB instance uses a private IP address. The domain name of the Ingress is resolved to the private IP address. Therefore, the ALB instance is accessible only within the virtual private cloud (VPC) where the ALB instance is deployed.

    Important

    The addressType parameter in an AlbConfig takes effect only when you create the AlbConfig. This parameter does not take effect when you update the AlbConfig.

    spec.config.zoneMappings

    • The IDs of the vSwitches used by the ALB Ingress.

      • You must specify at least two vSwitch IDs and the vSwitches must be deployed in different zones. The zones of the vSwitches must be supported by ALB. For more information about the supported zones, see Regions and zones in which ALB is available.

      • The vSwitch is in the same VPC as the cluster.

      Important
      • If you want to specify vSwitches in a region that contains only one zone, you can specify one vSwitch ID.

      • The zoneMappings parameter in an AlbConfig takes effect only when you create the AlbConfig. This parameter does not take effect when you update the AlbConfig.

    • You can specify the ID of the EIP that the Internet-facing ALB instance depends on in the zoneMappings parameter.

      • If no EIP is specified, use the default option Automatically assign EIP. Then, a pay-as-you-go EIP that uses BGP multi-line bandwidth and the default security protection mode is automatically created and associated with the ALB instance. For more information, see ALB billing.

      • Alternatively, you can associate an existing EIP with the ALB instance.

      Important
      • You can associate only pay-as-you-go (pay-by-data-transfer) EIPs that are not added to Internet Shared Bandwidth instances with an ALB instance.

      • The EIPs that you specify for different zones of the same ALB instance must be of the same type.

    When you install the ALB Ingress controller for a cluster, you can create a default AlbConfig. The parameters of the default AlbConfig use the following settings, except for the vSwitchID parameter.

    Default AlbConfig configurations

    apiVersion: alibabacloud.com/v1
    kind: AlbConfig
    metadata:
      name: alb # The name of the AlbConfig. 
    spec:
      config:
        accessLogConfig:
          logProject: ""
          logStore: ""
        addressAllocatedMode: Dynamic # You can use this parameter to specify how an IP address is assigned to the ALB instance. Valid values are Dynamic and Fixed. A value of Dynamic specifies a dynamic IP address. A value of Fixed specifies a static IP address. 
        addressType: Internet
        billingConfig:
          internetBandwidth: 0
          internetChargeType: ""
          payType: PostPay
        deletionProtectionEnabled: true
        edition: Standard
        forceOverride: false
        zoneMappings:
        - vSwitchId: #...
        - vSwitchId: #...
    status:
      loadBalancer:
        dnsname: alb-s2em8fr9debkg5****.cn-shenzhen.alb.aliyuncs.com
        id: alb-s2em8fr9debkg5****
  2. Run the following command to create an AlbConfig:

    kubectl apply -f alb.yaml

    Expected output:

    AlbConfig.alibabacloud.com/alb created
  3. Run the following command to query the AlbConfig:

    kubectl get AlbConfig

    Expected output:

    NAME   ALBID        DNSNAME                                  PORT&PROTOCOL   CERTID   AGE
    alb    alb-******   alb-******.<regionID>.alb.aliyuncs.com                            28m
    Note

    If you configure HTTP listeners and certificates, the PORT&PROTOCOL and CERTID parameters are not empty. Otherwise, the parameters are empty in the output.

Reuse an existing ALB instance

If you want to reuse an existing ALB instance, specify the ID of the ALB instance in the AlbConfig. You can reuse a standard ALB instance or a Web Application Firewall (WAF)-enabled ALB instance that is created in the ALB console. You cannot reuse a basic ALB instance.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: reuse-alb
spec:
  config:
    id: **** # The ID of the standard ALB instance or WAF-enabled ALB instance that is created in the SLB console. 
    forceOverride: false
    listenerForceOverride: false

The following table describes the preceding parameters.

Parameter

Description

id

  • If the id parameter does not exist or the id parameter is not specified, the ALB instance is not reused. In this case, the forceOverride and listenerForceOverride parameters do not take effect.

  • If the id parameter is set to a valid value, the ALB instance is reused.

    • If the forceOverride parameter is set to true, the ALB instance attributes and listener attributes are forcibly overwritten.

    • If the forceOverride parameter is set to false, the ALB instance attributes are not forcibly overwritten. In this case, the listenerForceOverride parameter is available to specify whether to forcibly overwrite the listener attributes.

      • If the listenerForceOverride parameter is set to false, the ALB instance attributes are not forcibly overwritten.

      • If the listenerForceOverride parameter is set to true, the controller manages the listeners of all ALB instances. If the name of the listener you create matches the format generated by the controller, the listener will be considered a controller-managed listener and will be overridden during tuning.

Important

If an ALB instance is reused, we recommend that you do not modify the listener names. Otherwise, the listeners cannot be managed by ACK. The listeners created or updated by using AlbConfigs are managed by ACK, and their names are in the ingress-auto-listener-{port} format by default. The listeners whose names are not in the preceding format are managed in the SLB console.

forceOverride

Specifies whether to forcibly overwrite ALB instance attributes when the ALB instance is reused. Valid values:

  • true: forcibly overwrites ALB instance attributes.

  • false: does not overwrite ALB instance attributes. If you set this parameter to false, the ALB instance attributes are not modified when you modify the AlbConfig.

listenerForceOverride

Specifies whether to forcibly overwrite listener attributes when the ALB instance is reused. Valid values:

  • true: forcibly overwrites listener attributes.

  • false: does not overwrite ALB instance attributes.

EIP bandwidth plan configurations

After this feature is enabled, you can use AlbConfigs to bind an elastic IP address (EIP) bandwidth plan to an ALB instance.

Note

This parameter is available only if Network Type is set to Internet-facing. For more information about how to purchase an Internet Shared Bandwidth instance, see Create an Internet Shared Bandwidth.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    name: alb
    addressType: Internet
    edition: Standard
    zoneMappings:
    - vSwitchId: vsw-2vcqeyvwsnd***
    - vSwitchId: vsw-2vcbhjlqu7y***
    billingConfig:
      bandWidthPackageId: cbwp-2vcjucp49otd8qolhm***  # The ID of the EIP bandwidth plan.

Update an AlbConfig

To update an ALB instance created by using an AlbConfig, we recommend that you use the kubectl edit command. To update an AlbConfig, perform the following steps:

  1. Run the following command to query the name of the AlbConfig that you want to update:

    kubectl get AlbConfig

    Expected output:

    NAME       ALBID        DNSNAME                                  PORT&PROTOCOL   CERTID   AGE
    alb        alb-******   alb-******.<regionID>.alb.aliyuncs.com                            28m
  2. Run the following command to modify the AlbConfig:

    kubectl edit albconfig <ALBCONFIG_NAME> # Replace <ALBCONFIG_NAME> with the name of the AlbConfig.

    Update the AlbConfig configuration file based on your business requirements. For example, you can update the spec.config.name parameter to change the name of the ALB instance to new_alb.

    ...
     spec:
       config:
         name: new_alb # The new name of the ALB instance. 
    ...

Use an IngressClass to associate an AlbConfig with an Ingress

You can associate an AlbConfig with an ALB Ingress by using an IngressClass. To do this, specify the AlbConfig in the IngressClass configurations.

  1. Create a file named ingress_class.yaml and copy the following content to the file:

    Clusters that run Kubernetes 1.19 or later

    apiVersion: networking.k8s.io/v1
    kind: IngressClass
    metadata:
      name: alb
    spec:
      controller: ingress.k8s.alibabacloud/alb
      parameters:
        apiGroup: alibabacloud.com
        kind: AlbConfig
        name: alb # The name of the AlbConfig that you want to associate.

    Clusters that run Kubernetes versions earlier than 1.19

    apiVersion: networking.k8s.io/v1beta1
    kind: IngressClass
    metadata:
      name: alb
    spec:
      controller: ingress.k8s.alibabacloud/alb
      parameters:
        apiGroup: alibabacloud.com
        kind: AlbConfig
        name: alb
  2. Run the following command to create an IngressClass:

    kubectl apply -f ingress_class.yaml

    Expected output:

    ingressclass.networking.k8s.io/alb created
  3. Create a file named ingress.yaml and copy the following content to the file: Set the ingressClassName parameter to the alb IngressClass.

    Clusters that run Kubernetes 1.19 or later

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: cafe-ingress 
    spec:
      ingressClassName: alb # Specify the name of the IngressClass that is used to associate the Ingress.
      rules:
      - http:
          paths:
          # Configure a context path. 
          - path: /tea
            pathType: ImplementationSpecific
            backend:
              service:
                name: tea-svc
                port:
                  number: 80
          # Configure a context path. 
          - path: /coffee
            pathType: ImplementationSpecific
            backend:
              service:
                name: coffee-svc
                port: 
                  number: 80

    Clusters that run Kubernetes versions earlier than 1.19

    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    metadata:
      name: cafe-ingress
    spec:
      ingressClassName: alb
      rules:
      - http:
          paths:
          # Configure a context path. 
          - path: /tea
            backend:
              serviceName: tea-svc
              servicePort: 80
          # Configure a context path. 
          - path: /coffee
            backend:
              serviceName: coffee-svc
              servicePort: 80
  4. Run the following command to create an Ingress:

    kubectl apply -f ingress.yaml

    Expected output:

    ingress.networking.k8s.io/cafe-ingress created

After you complete the preceding steps, you can use the IngressClass to associate the AlbConfig with the Ingress.

Create and use multiple ALB instances

If you want to share an Ingress among multiple ALB instances, specify different IngressClasses in the spec.ingressClassName parameter in the Ingress configuration file.

  1. Create a file named alb-2.yaml and copy the following content to the file:

    apiVersion: alibabacloud.com/v1
    kind: AlbConfig
    metadata:
      name: alb-2
    spec:
      config:
        name: alb-2        # The name of an ALB instance. 
        addressType: Internet  # The ALB instance has a public IP address. 
        zoneMappings:
        - vSwitchId: vsw-uf6ccg2a9g71hx8go**** # The ID of the vSwitch that you want to use.
        - vSwitchId: vsw-uf6nun9tql5t8nh15****
  2. Run the following command to create an AlbConfig:

    kubectl apply -f alb-2.yaml

    Expected output:

    AlbConfig.alibabacloud.com/alb-2 created
  3. Create a file named ingress_class2.yaml and copy the following content to the file. The file is used to create an IngressClass.

    Clusters that run Kubernetes 1.19 or later

    apiVersion: networking.k8s.io/v1
    kind: IngressClass
    metadata:
      name: alb-2
    spec:
      controller: ingress.k8s.alibabacloud/alb
      parameters:
        apiGroup: alibabacloud.com
        kind: AlbConfig
        name: alb-2 # The name of the AlbConfig that you want to associate.

    Clusters that run Kubernetes versions earlier than 1.19

    apiVersion: networking.k8s.io/v1beta1
    kind: IngressClass
    metadata:
      name: alb-2
    spec:
      controller: ingress.k8s.alibabacloud/alb
      parameters:
        apiGroup: alibabacloud.com
        kind: AlbConfig
        name: alb-2 # The name of the AlbConfig that you want to associate.
  4. Run the following command to create an IngressClass:

    kubectl apply -f ingress_class2.yaml

    Expected output:

    ingressclass.networking.k8s.io/alb-2 created
  5. Create a file named ingress2.yaml and copy the following content to the file. You can use the ingressClassName parameter to specify different ALB instances that you want to associate with the Ingress. In the following example, the ingressClassName parameter is set to alb-2. This associates the Ingress with the alb-2 IngressClass, which is associated with the alb-2 ALB instance.

    Clusters that run Kubernetes 1.19 or later

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: cafe-ingress2
    spec:
      ingressClassName: alb-2
      rules:
      - http:
          paths:
          # Configure a context path. 
          - path: /tea
            pathType: ImplementationSpecific
            backend:
              service:
                name: tea-svc
                port:
                  number: 80
          # Configure a context path. 
          - path: /coffee
            pathType: ImplementationSpecific
            backend:
              service:
                name: coffee-svc
                port: 
                  number: 80

    Clusters that run Kubernetes versions earlier than 1.19

    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    metadata:
      name: cafe-ingress2
    spec:
      ingressClassName: alb-2
      rules:
      - http:
          paths:
          # Configure a context path. 
          - path: /tea
            backend:
              serviceName: tea-svc
              servicePort: 80
          # Configure a context path. 
          - path: /coffee
            backend:
              serviceName: coffee-svc
              servicePort: 80
  6. Run the following command to create an Ingress:

    kubectl apply -f ingress2.yaml

    Expected output:

    ingress.networking.k8s.io/cafe-ingress2 created

Enable IPv6

When you use an AlbConfig to create an ALB instance, you can set the addressIpVersion parameter to DualStack to enable IPv4/IPv6 dual stack.

Important

The addressIpVersion parameter in an AlbConfig takes effect only when you create the AlbConfig. This parameter does not take effect when you update the AlbConfig.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    addressIpVersion: DualStack # Enable IPv4/IPv6 dual stack.
    ...

Specify a custom TLS security policy

When you use an AlbConfig to configure HTTPS listeners, you can specify a TLS security policy. Custom TLS security policies and default TLS security policies are supported. For more information, see TLS security policies.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    #...
  listeners:
  - port: 443
    protocol: HTTPS
    securityPolicyId: tls_cipher_policy_1_1 # Specify the ID of the security group.
  #...

Enable SLS to collect access logs

If you want to collect the access logs of ALB Ingresses, set the logProject and logStore parameters in the AlbConfig configuration.

Note
  • If you configure a new or existing SLS project for your cluster when you create the cluster, you can perform the following steps to view the project. Log on to the ACK console. In the left-side navigation pane, click Clusters. On the Clusters page, click the name of your cluster. In the left-side navigation pane of the cluster details page, click Cluster Information. On the Basic Information tab, you can view the Log Service Project that is associated with the cluster.

  • The value of the logStore parameter must start with alb_. If the specified Logstore does not exist, a new Logstore with the specified name is created.

  • When you reuse an existing ALB instance and enable SLS by using AlbConfig, you must set the forceOverride parameter to true to forcibly overwrite the attributes of the ALB instance. For more information, see Reuse an existing ALB instance.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    accessLogConfig:
      logProject: "k8s-log-xz92lvykqj1siwvif****"
      logStore: "alb_****"
    #...

On the Basic Information tab, you can click the project name on the right side of Log Service Project to view the collected logs in the SLS console.

Delete an AlbConfig

An AlbConfig is used to configure an ALB instance. Therefore, you can delete an ALB instance by deleting the corresponding AlbConfig.

Important

Before you can delete an AlbConfig, you must delete all Ingresses that are associated with the AlbConfig.

Run the following command to delete the AlbConfig:

kubectl delete AlbConfig <AlbConfig_NAME> # Replace <AlbConfig_NAME> with the name of the AlbConfig that you want to delete.

Delete the AlbConfig of a reused ALB instance

If you delete the AlbConfig of a reused ALB instance, the ALB instance is not deleted. To delete the AlbConfig of a reused ALB instance, perform the following steps:

  1. Run the kubectl edit command to modify the AlbConfig to delete all entries of the spec.listeners parameter. This way, all the listeners specified in the AlbConfig are deleted.

    Important

    If the version of the ALB Ingress controller installed in your cluster is later than 2.10.0-aliyun.1, skip this step.

  2. Run the following command to delete the AlbConfig:

    Important

    Before you can delete an AlbConfig, you must delete all Ingresses that are associated with the AlbConfig.

    kubectl delete AlbConfig <AlbConfig_NAME> # Replace <AlbConfig_NAME> with the name of the AlbConfig that you want to delete.

Description of the Listeners parameter

Terms

  • Object configuration file: a file that defines the configuration of a Kubernetes object.

  • Live object configuration file: an object configuration file that has been applied in a Kubernetes cluster.

  • last-applied-configuration: an annotation of a Kubernetes object. The annotation records the content of the most recent configuration of the object. The annotation is not updated in real-time when the configuration of the object is updated.

Update methods for the Listeners parameter

The Listeners parameter is of the array type. In most cases, you can update the Listeners parameter by replacing the fields in the array. When you update the Listeners parameter, the fields are replaced by the new fields you specify. The following table describes the rules.

Step

Condition

Result

The listener is in the object configuration file

The listener is in the live object configuration file

The listener is in the last-applied-configuration annotation

(1)

Yes

Yes

- (Irrelevant)

The listener is retained in the live object configuration file.

(2)

Yes

No

- (Irrelevant)

The listener is added to the live object configuration file.

(3)

No

- (Irrelevant)

Yes

The listener is deleted from the live object configuration file. However, the fields of the listener may be reset to the default settings.

(4)

No

Yes

No

The listener is deleted from the live object configuration file.

Examples

The following example shows the content of an object configuration file, a live object configuration file, and a last-applied-configuration annotation:

# The content of the object configuration file. 
  listeners:
  - port: 8001
    protocol: HTTP
  - port: 8003
    protocol: HTTP
  - port: 8005 # Add port 8005.
    protocol: HTTP

# The content of the live object configuration file. 
  listeners:
  - port: 8001
    protocol: HTTP
  - port: 8002  # Delete port 8002.
    protocol: HTTP
  - port: 8003
    protocol: HTTP
  - port: 8004  # Delete port 8004.
    protocol: HTTP
    
# The content of the last-applied-configuration annotation. 
  listeners:
  - port: 8001 
    protocol: HTTP
  - port: 8002  # Delete port 8002.
    protocol: HTTP
  - port: 8003
    protocol: HTTP

The following code block shows the configuration of the Listeners parameter after it is updated:

# The configuration of the Listeners parameter.
  listeners:
  - port: 8001
    protocol: HTTP
  - port: 8003
    protocol: HTTP
  - port: 8005
    protocol: HTTP
  • Port 8001 and port 8003 match Rule 1. Therefore, they are retained.

  • Port 8005 matches Rule 2. Therefore, it is added.

  • Port 8002 matches Rule 3. Therefore, it is deleted.

  • Port 8004 matches Rule 4. Therefore, it is deleted.

Create an HTTPS listener

ALB instances use listeners to receive and forward external requests based on the application-layer information of the requests. An ALB instance listens for requests from clients only after you create a listener for the ALB instance.

To create a listener, set the port and protocol parameters in the AlbConfig. If you modify the port, protocol, or other parameters of a listener, the original listener is deleted and a new listener is created based on the modified parameters.

A listener supports the following protocols at the application layer: HTTP, HTTPS, and Quick UDP Internet Connections (QUIC).

Important

You can configure multiple listeners that use different protocols at the same time. In this case, you must add the required annotations to the Ingress configurations to specify multiple listening ports. For more information, see Configure custom listening ports.

Create an HTTP listener

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
  ...
  listeners:
    - port: 80
      protocol: HTTP # Valid values: HTTP, HTTPS, and QUIC. 
  ...
Note

HTTP is compatible with WebSocket. No additional configuration is required.

Create an HTTPS listener

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
  ...
  listeners:
    - port: 443
      protocol: HTTPS
  ...
Important

You need to configure certificates for an HTTPS listener. For more information, see Configure certificates to encrypt communication on HTTPS ports.

Create a QUIC listener

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
  ...
  listeners:
    - port: 443
      protocol: QUIC
  ...
Important

QUIC listeners can receive requests from clients that use the HTTP/3 protocol. For more information, see Use QUIC listeners to support HTTP/3.

Specify a certificate

If you want to enable encryption and authentication for an HTTPS listener when you create an ALB instance, run the kubectl edit albconfig <Albconfig_Name> command to modify the AlbConfig that is used to configure the ALB instance. Then, specify a certificate ID in the certificates parameter of the AlbConfig.

If you do not specify a certificate in the parameter, no HTTPS listener is created when the system creates the ALB instance. The system waits until an Ingress is associated with the listener and the Ingress automatically discovers a certificate based on the domain name specified in the Ingress configuration. This means that the creation of the listener is delayed due to the automatic discovery of the certificate based on the domain name.

For more information about how to configure certificates, see Configure HTTPS certificates for encrypted communication.

Important

ALB uses the first certificate that you specify as the default certificate. ALB uses the default certificate to encrypt requests until the certificate expires or no longer meets the requirements. In this case, ALB uses other certificates to encrypt requests.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb-demo
spec:
  config:
  ...
  listeners:
  - caEnabled: false
    certificates:
    - CertificateId: 756****-cn-hangzhou # The certificate ID. 
      IsDefault: true
    port: 443
    protocol: HTTPS
  ...

Set the connection timeout period for listeners

You can set the connection timeout period for listeners in the configurations of an AlbConfig. Valid values: 1 to 180. Unit: seconds. If no response is received from the backend server within the specified timeout period, ALB returns an HTTP 504 error code to the client. If you do not specify the connection timeout period, the default timeout period (60 seconds) is used. The following YAML file is an example:

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    ...
  listeners:
  - port: 80
    protocol: HTTP
    requestTimeout: 40 # The default timeout period is 60 seconds.
  ...

Configure data compression

After you enable this feature, the ALB instance compresses specific types of files. Valid values of the gzipEnabled parameter:

  • true: compresses specific types of files.

  • false: does not compress files.

Note

All file types support Brotli compression. The following file types support Gzip compression: text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, application/atom+xml, application/xml, and application/json.

The following YAML file is an example:

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    ...
  listeners:
  - port: 80
    protocol: HTTP
    gzipEnabled: true
  ...

Preserve client IP addresses

After you enable this feature, the ALB instance adds a parameter that specifies the client IP address to the HTTP request header when forwarding the request to the backend application. Valid values of the XForwardedForEnabled parameter:

  • true: enables client IP address preservation.

  • false: disables client IP address preservation.

Important

This parameter is available for HTTP listeners and HTTPS listeners.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    #...
  listeners:
  - port: 80
    protocol: HTTP
    xForwardedForConfig:
      XForwardedForEnabled: true # This parameter cannot be set to false. 
  #...

Retrieve the port that a client uses to connect to an ALB instance

After you enable this feature, the ALB instance adds a parameter that specifies the client port to the HTTP request header when forwarding the request to the backend application. Valid values of the XForwardedForClientSrcPortEnabled parameter:

  • true: retrieves the port that a client uses to connect to the ALB instance.

  • false: does not retrieve the port that a client uses to connect to the ALB instance.

Important

This parameter is available for HTTP listeners and HTTPS listeners.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    ...
  listeners:
  - port: 80
    protocol: HTTP
    xForwardedForConfig:
      XForwardedForClientSrcPortEnabled: true
  ...

Retrieve the listener protocols used by an ALB instance

After you enable this feature, the ALB instance adds a parameter that specifies the listener protocols used by the ALB instance to the HTTP request header when forwarding the request to the backend application. Valid values of the XForwardedForProtoEnabled parameter:

  • true: retrieves the listener protocol used by the ALB instance.

  • false: does not retrieve the listener protocol used by the ALB instance.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    ...
  listeners:
  - port: 80
    protocol: HTTP
    xForwardedForConfig:
      XForwardedForProtoEnabled: true
  ...

Retrieve the ID of an ALB instance

After you enable this feature, the ALB instance adds a parameter that specifies the ID of the ALB instance to the HTTP request header when forwarding the request to the backend application. Valid values of the XForwardedForSLBIdEnabled parameter:

  • true: retrieves the ID of the ALB instance.

  • false: does not retrieve the ID of the ALB instance.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    ...
  listeners:
  - port: 80
    protocol: HTTP
    xForwardedForConfig:
      XForwardedForSLBIdEnabled: true
  ...

Retrieve the listening ports of an ALB instance

After you enable this feature, the ALB instance adds a parameter that specifies the listening ports of the ALB instance to the HTTP request header when forwarding the request to the backend application. Valid values of the XForwardedForSLBPortEnabled parameter:

  • true: retrieves the listening ports of the ALB instance.

  • false: does not retrieve the listening ports of the ALB instance.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
    ...
  listeners:
  - port: 80
    protocol: HTTP
    xForwardedForConfig:
      XForwardedForSLBPortEnabled: true
  ...

Specify the IP address of a trusted proxy server

You can specify the XForwardedForClientSourceIpsEnabled parameter in the configurations of an AlbConfig to enable the ALB instance to retrieve client IP addresses from the X-Forwarded-For header field. You can use the XForwardedForClientSourceIpsTrusted parameter to specify a list of trusted proxy server IP addresses. This way, the ALB instance traverses the IP addresses in the X-Forwarded-For header field from the rightmost IP address to the leftmost IP address. The first IP address that is not on the trusted IP address list is considered the client IP address.

For example, if the value of X-Forwarded-For is <client IP, proxy server IP-1, proxy server IP-2>, you can specify proxy server IP-1 and proxy server IP-2 in the XForwardedForClientSourceIpsTrusted parameter. This way, the ALB instance can retrieve client IP addresses.

Important

This parameter is available for HTTP listeners and HTTPS listeners.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata: 
  name: alb
spec:
  config:
    ...
  listeners:
  - port: 80
    protocol: HTTP
    xForwardedForConfig:
      XForwardedForClientSourceIpsEnabled: true # A value of true allows the ALB instance to retrieve client IP addresses from the X-Forwarded-For header. If you set the value to true, you must configure the XForwardedForClientSourceIpsTrusted parameter in a valid format. A value of false forbids the ALB instance from retrieving client IP addresses from the X-Forwarded-For header. 
      XForwardedForClientSourceIpsTrusted: 192.168.x.x;192.168.x.x/16  # Enter a valid IP address or CIDR block. This parameter takes effect only when XForwardedForClientSourceIpsEnabled is set to true. 
  ...

Configure network ACLs

You can configure an AlbConfig to enable network access control lists (ACLs) for the listeners of an ALB instance. You can configure network ACLs to allow or deny access from specific IP addresses or CIDR blocks. This allows you to implement fine-grained access control on client requests. For more information, see Configure ACLs.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb
spec:
  config:
   #...
  listeners:
  - port: 80
    protocol: HTTP
    aclConfig:
      aclEntries:
      - 127.0.0.1/32
      aclType: White
  #...

Parameters:

  • aclType: the type of network ACLs. Valid values: Black and White. A value of Black specifies blacklists. A value of White specifies whitelists.

  • aclEntries: the CIDR block that you want to add to the ACL rule for access control. Example: 127.0.0.1/32.

Delete a listener

An ALB instance may have multiple listeners. To delete a listener of an ALB instance, run the kubectl edit albconfig <Albconfig_Name> command to modify the AlbConfig used to configure the ALB instance. Then, delete the listener from the albconfig.spec.listeners parameter.

Important

Before you delete the listener, you must disassociate all Ingresses from the listener. Otherwise, you fail to delete the listener and the system prompts errors.

# The configurations before the deletion. 
  listeners:
  - port: 8001
    protocol: HTTP
  - port: 8002  # Delete listening port 8002. 
    protocol: HTTP

# The configurations after the deletion. 
  listeners:
  - port: 8001
    protocol: HTTP