How to configure an AlbConfig and enable Log Service - Container Compute Service

An AlbConfig is a Custom Resource Definition (CRD) provided by the ALB Ingress Controller. The ALB Ingress Controller uses an AlbConfig to configure ALB instances and listeners. This topic describes how to create, modify, and update an AlbConfig, and how to enable Log Service.

Prerequisites

You have installed the ALB Ingress Controller.
You have created two VSwitches in different availability zones within your cluster's VPC. Create and manage VSwitches.

Usage notes

We recommend that you use the kubectl edit command to directly modify or update resource configurations. If you must use the kubectl apply command to modify or update resources, run the kubectl diff command to preview the changes before you run the kubectl apply command. Make sure that the changes are as expected, and then run the kubectl apply command to apply the changes to the Kubernetes cluster.
Earlier versions of the Nginx Ingress Controller do not recognize the spec.ingressClassName field in Ingress resources. If both Nginx Ingress and ALB Ingress controllers are running in the same cluster, an older Nginx Ingress Controller may interfere with or overwrite the ALB Ingress configuration. To prevent this issue, update the Nginx Ingress Controller to the latest version, or use an annotation to specify the ingressClass for the ALB Ingress. For more information, see Advanced features of ALB Ingresses.

Create an AlbConfig

An AlbConfig corresponds to a single ALB instance but can be associated with multiple Ingresses. To use multiple ALB instances, you can create multiple AlbConfigs. The following steps describe how to create an AlbConfig.

Create a file named alb-test.yaml and copy the following content into it.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb-demo
spec:
  config:
    name: alb-test
    addressAllocatedMode: Dynamic          # Dynamic or Fixed. Specifies the IP address mode for the ALB instance.
    addressType: Internet
    zoneMappings:                          # For high availability, select vSwitches in at least two different zones.
    - vSwitchId: vsw-uf6ccg2a9g71hx8go**** # Replace with the actual vSwitch ID (Zone 1).
    - vSwitchId: vsw-uf6nun9tql5t8nh15**** # Replace with the actual vSwitch ID (Zone 2, must be different from Zone 1).
  listeners:
    - port: 80
      protocol: HTTP

Parameter	Description
spec.config.name	(Optional) The name of the ALB instance.
spec.config.addressType	(Required) The address type of the load balancer. Valid values: Internet (default): The load balancer has a public IP address. The DNS record is resolved to the public IP address, making the load balancer accessible over the internet. Intranet: The load balancer has only a private IP address. The DNS record is resolved to the private IP address, making the load balancer accessible only from within the VPC where it is deployed.
spec.config.zoneMappings	(Required) Specifies the vSwitch IDs for the ALB Ingress. In multi-zone regions, you must specify the IDs of vSwitches in at least two different zones. In single-zone regions, one vSwitch ID is sufficient. The vSwitches must be in the same VPC as the cluster and in zones that support ALB. For more information about the regions and zones supported by ALB Ingress, see Regions and zones supported by ALB. Important You cannot update the address type or zones of an ALB instance. The `addressType` and `zoneMappings` parameters take effect only when you create an AlbConfig and cannot be updated afterward.
`spec.config.addressAllocatedMode`	(Optional) In AlbConfig, you can specify the IP mode for the ALB instance by setting the addressAllocatedMode parameter. The valid values are: Dynamic: the dynamic IP mode. Fixed: the fixed IP mode.

When you install the ALB Ingress Controller add-on for a cluster, the system creates an AlbConfig by default. All configuration parameters except for vSwitchId will be created with the default settings.

Default configuration

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb-demo                      # The name of the AlbConfig.
spec:
  config:
    accessLogConfig:
      logProject: ""
      logStore: ""
    addressAllocatedMode: Dynamic # In an AlbConfig, you can use the addressAllocatedMode parameter to specify the IP address mode of the ALB instance. Valid values: Dynamic (dynamic IP mode) and Fixed (fixed IP mode).
    addressType: Internet
    billingConfig:
      internetBandwidth: 0
      internetChargeType: ""
      payType: PostPay
    deletionProtectionEnabled: true
    edition: Standard
    forceOverride: false
    zoneMappings:                                 # For high availability, select vSwitches in at least two different zones.
    - vSwitchId: vsw-wz92lvykqj1siwvif****        # Replace with the actual vSwitch ID (Zone 1).
    - vSwitchId: vsw-wz9mnucx78c7i6iog****        # Replace with the actual vSwitch ID (Zone 2, must be different from Zone 1).
status:
  loadBalancer:
    dnsname: alb-s2em8fr9debkg5****.cn-shenzhen.alb.aliyuncs.com
    id: alb-s2em8fr9debkg5****

Run the following command to create the AlbConfig.

kubectl apply -f alb-test.yaml

Expected output:

albconfig.alibabacloud.com/alb-demo created

Run the following command to view the AlbConfig.

kubectl -n kube-system get AlbConfig

Expected output:

NAME       ALBID        DNSNAME                                  PORT&PROTOCOL   CERTID                 AGE
alb-demo   alb-******   alb-******.<regionID>.alb.aliyuncs.com   443/HTTPS       11055487-cn-<regionID>  2d

Update an AlbConfig

In Kubernetes, the kubectl apply command performs an overwrite update, whereas the kubectl edit command performs an incremental update based on the existing object. For an ALB instance already created through an AlbConfig, use the kubectl edit command to incrementally update the instance configuration. The following steps describe how to update an AlbConfig.

Run the following command to view the AlbConfig.

kubectl -n kube-system get AlbConfig

Expected output:

NAME       ALBID        DNSNAME                                  PORT&PROTOCOL   CERTID                 AGE
alb-demo   alb-******   alb-******.<regionID>.alb.aliyuncs.com   443/HTTPS       11055487-cn-<regionID>  2d

Run the following command to update the AlbConfig.
Important
- We recommend using the kubectl edit command to directly update resource configurations. If you must use the kubectl apply command to update a resource, run the kubectl diff command to preview the changes before you run the kubectl apply command. Ensure that the changes are as expected, and then use the kubectl apply command to apply the changes to the Kubernetes cluster.
- When you use the kubectl apply command to overwrite an AlbConfig, the behavior depends on whether the YAML file includes the listeners field. If the field is not included, existing listeners are not affected. If the field is included, listeners are reconciled to match the current configuration. Therefore, you must specify the full list of required listeners, such as the common listeners for ports 80 and 443.
```
kubectl -n kube-system edit AlbConfig alb-demo
```
In the AlbConfig configuration file, update the content. For example, update the name of the AlbConfig to test.
```
...
 spec:
   config:
     name: test # Enter the updated name.
...
```

Associate an AlbConfig with an Ingress

You can associate an Ingress with an AlbConfig by using a standard Kubernetes IngressClass. First, create an IngressClass that references the AlbConfig, then specify that IngressClass in your Ingress resource.

Create a file named alb.yaml and copy the following content into it to create an IngressClass.

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
spec:
  controller: ingress.k8s.alibabacloud/alb
  parameters:
    apiGroup: alibabacloud.com
    kind: AlbConfig
    name: alb-demo

Run the following command to create the IngressClass.
```
kubectl apply -f alb.yaml
```
Expected output:
```
ingressclass.networking.k8s.io/alb created
```

Create a file named ingress.yaml and copy the following content into it. The ingressClassName parameter specifies the IngressClass named alb to associate with the AlbConfig.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress 
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

Run the following command to create the Ingress.

kubectl apply -f ingress.yaml

Expected output:

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

After you complete these steps, the AlbConfig is associated with the Ingress by using the IngressClass.

Modify the name of an ALB instance

Run the following command to modify the name of an ALB instance:

kubectl -n kube-system edit AlbConfig alb-demo

Modify the value of config.name in the configuration file. The new name takes effect automatically after you save the file.

...
  spec:
    config:
      name: test   # Enter the updated name.
...

Use an IPv6 address

To enable IPv6 support when you create an ALB instance, set the addressIpVersion field to DualStack in the AlbConfig.

Important

The addressIpVersion field takes effect only during instance creation and cannot be modified afterward.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb-demo
spec:
  config:
    addressIpVersion: DualStack
    ...

Specify a TLS security policy

You can specify a TLS security policy for an HTTPS listener in an AlbConfig. TLS security policies include custom policies and system policies. For more information, see TLS security policies.

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

Enable access logs

To enable access logging for the ALB Ingress, specify a logProject and logStore in your AlbConfig.

Note

You must create the logProject manually. For more information about how to create a logProject, see Manage a Project.
The name of the logStore must start with alb_. If the specified logStore does not exist, it is automatically created.

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

After you save the configuration, you can navigate to the Log Service console and select the destination LogStore to view the collected access logs.

Reuse an existing ALB instance

To reuse an existing ALB instance, specify the ALB instance ID when you create the AlbConfig. The existing ALB instance must be a Standard or WAF-enabled edition instance created in the Application Load Balancer (ALB) console. Basic edition ALB instances cannot be reused. An ALB instance can be reused only by a single AlbConfig within the same cluster. Reusing one ALB instance across multiple clusters is not supported, nor is reusing one ALB instance by multiple AlbConfigs within the same cluster.

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

The following table describes the parameters.

Parameter	Description
id	If the `id` field does not exist or the `id` field is empty, this indicates that the ALB instance is not being reused. In this case, the `forceOverride` and `listenerForceOverride` fields have no effect. If the `id` field is set to a valid value, the ALB instance is reused. Important When reusing an instance, do not manually modify listener names. Doing so can cause ACS to mismanage the listeners. Listeners created or updated by an AlbConfig are managed by ACS, and the listener names are in the `ingress-auto-listener-{port}` format by default. Listeners whose names are in other formats are managed in the ALB console.
forceOverride	Specifies whether to forcibly overwrite the attributes of the ALB instance in reuse mode. `true`: The AlbConfig completely overwrites the existing configuration of the ALB instance and all its listeners. `false`: Does not overwrite attributes. The attributes of the ALB instance are not forcibly overwritten. The `listenerForceOverride` field determines whether to forcibly overwrite the listener attributes.
listenerForceOverride	Specifies whether to forcibly overwrite listener attributes in reuse mode. `true`: Forcibly overwrites listener attributes. The ALB Ingress Controller manages all listeners of the ALB instance. The existence and configurations of the listeners are determined by the AlbConfig. `false`: Does not forcibly overwrite listener attributes. The ALB Ingress Controller manages only the listeners created by the AlbConfig in the cluster. Listener names use the default format `ingress-auto-listener-{port}`, and their configurations are determined by the AlbConfig in the cluster. Other listeners are not managed by the AlbConfig.

Create a listener

In a reuse scenario, you can add a new listener or edit the settings of an existing listener by modifying the AlbConfig. Run the command kubectl edit albconfig <Albconfig_Name>. Set the port and protocol in the AlbConfig to create the corresponding listener. The port and protocol are the unique properties of a listener. If you modify the port, protocol, or other properties of the listener, the system deletes the original listener and creates a new one to replace it.

Note

The HTTP protocol is automatically compatible with WebSocket and does not require special settings.

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

Create and use multiple ALB instances

To use multiple ALB instances, specify a different IngressClass for each Ingress resource by using the spec.ingressClassName parameter.

Create a file named alb-demo2.yaml and copy the following content into it to create an AlbConfig.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: demo
spec:
  config:
    name: alb-demo2                        # The name of the ALB instance.
    addressType: Internet                  # The load balancer has a public IP address.
    zoneMappings:                          # For high availability, select vSwitches in at least two different zones.
    - vSwitchId: vsw-uf6ccg2a9g71hx8go**** # Replace with the actual vSwitch ID (Zone 1).
    - vSwitchId: vsw-uf6nun9tql5t8nh15**** # Replace with the actual vSwitch ID (Zone 2, must be different from Zone 1).

Run the following command to create the AlbConfig.

kubectl apply -f alb-demo2.yaml

Expected output:

AlbConfig.alibabacloud.com/demo created

Create a file named alb.yaml and copy the following content into it to create an IngressClass.

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb-demo2
spec:
  controller: ingress.k8s.alibabacloud/alb
  parameters:
    apiGroup: alibabacloud.com
    kind: AlbConfig
    name: demo

Run the following command to create the IngressClass.

kubectl apply -f alb.yaml

Expected output:

ingressclass.networking.k8s.io/alb-demo2 created

Create a file named ingress.yaml and copy the following content into it. Use the ingressClassName parameter to specify different ALB instances.

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

Set the listener request timeout

In an AlbConfig, you can specify a listener and set the connection request timeout in seconds. The value must be in the range of 1 to 180. If a backend server does not respond within the timeout period, the load balancer returns an HTTP 504 error to the client. The default timeout is 60 seconds.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: default
spec:
  config:
    ...
  listeners:
  - port: 80
    protocol: HTTP
    requestTimeout: 60
  ...

Use data compression

In an AlbConfig, you can specify a listener and enable or disable data compression. The following list describes the valid values of gzipEnabled.

true: Compresses specific types of files.
false: Does not compress any types of files.

Note

Brotli supports the compression of all file types. Gzip supports the compression of the following file types: text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, application/atom+xml, application/xml, and application/json.

The following code provides a YAML sample for disabling data compression:

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

Retrieve client IP addresses

You can configure the listener to include the X-Forwarded-For header field, which allows backend servers to retrieve the client's real IP address. The following list describes the valid values of XForwardedForEnabled.

true: Retrieves the real IP addresses of clients.
false: Does not retrieve the real IP addresses of clients.

Note