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

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

Before you begin

An ACS cluster is created. For more information, see Create an ACS cluster.
Two vSwitches are created in different zones of the virtual private cloud (VPC) where your cluster resides. For more information, see Create and manage vSwitches.

Notes

We recommend that you use the kubectl edit command to directly modify and update resource configurations. If you must use the kubectl apply command to modify and update resources, before you run the kubectl apply command, first run the kubectl diff command to preview the changes. Ensure 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 cannot recognize the spec.ingressClassName field in Ingress resources. If both Nginx Ingress and ALB Ingress exist in a cluster, the earlier version of the Nginx Ingress Controller may conflict with the ALB Ingress or overwrite its configuration. To avoid this issue, upgrade 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 Ingress.

Create an AlbConfig

An AlbConfig corresponds to a single ALB instance but can be associated with multiple Ingresses, creating a one-to-many relationship. To use multiple ALB instances, you must create multiple AlbConfigs. Follow these steps to create an AlbConfig.

Create a file named alb-test.yaml and copy the following content into it. This file is used to create an AlbConfig.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb-demo
spec:
  config:
    name: alb-test
    addressAllocatedMode: Dynamic          # The value can be Dynamic or Fixed. This parameter specifies the IP mode of the ALB instance.
    addressType: Internet
    zoneMappings:                          # To ensure high availability, select at least two vSwitches in different zones.
    - vSwitchId: vsw-uf6ccg2a9g71hx8go**** # Replace with the actual vSwitch ID (in Zone 1). 
    - vSwitchId: vsw-uf6nun9tql5t8nh15**** # Replace with the actual vSwitch ID (in Zone 2, which must be different from the first one).  
  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 domain name is resolved to the public IP address. The load balancer can be accessed over the Internet. Intranet: The load balancer has only a private IP address. The domain name is resolved to the private IP address. The load balancer can be accessed only within the VPC where it resides.
spec.config.zoneMappings	(Required) The vSwitch IDs for the ALB Ingress. In a region with multiple zones, specify the IDs of at least two vSwitches in different zones. For a single-zone region, specify one vSwitch ID. The specified vSwitches must be in zones that support ALB and in the same VPC as the cluster. For more information about regions and zones that support ALB, see Regions and zones that support ALB. Important You cannot update the address type and zones of an ALB instance. The `addressType` and `zoneMappings` parameters in an AlbConfig take effect only when you create the AlbConfig. They cannot be updated.
`spec.config.addressAllocatedMode`	(Optional) In ALBConfig, you can use the addressAllocatedMode parameter to specify the IP mode of the ALB instance. Valid values: Dynamic: dynamic IP mode. Fixed: static IP mode.

When you install the ALB Ingress Controller component for a cluster, an AlbConfig is created by default. Except for vSwitchId, other parameters use the default configurations shown below.

Click to view the default configurations of an AlbConfig

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 mode of the ALB instance. Valid values are Dynamic (dynamic IP mode) and Fixed (static IP mode).
    addressType: Internet
    billingConfig:
      internetBandwidth: 0
      internetChargeType: ""
      payType: PostPay
    deletionProtectionEnabled: true
    edition: Standard
    forceOverride: false
    zoneMappings:                                 # To ensure high availability, select at least two vSwitches in different zones.
    - vSwitchId: vsw-wz92lvykqj1siwvif****        # Replace with the actual vSwitch ID (in Zone 1).
    - vSwitchId: vsw-wz9mnucx78c7i6iog****        # Replace with the actual vSwitch ID (in Zone 2, which must be different from the first one).
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 retrieve the AlbConfig name.

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, while the kubectl edit command performs an incremental update on an existing object. To change the configuration of an Application Load Balancer (ALB) instance created from an AlbConfig, use the kubectl edit command to perform an incremental update. Follow these steps to update an AlbConfig.

Run the following command to view the AlbConfig name.

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 that you use the kubectl edit command to update resource configurations directly. If you must use the kubectl apply command to update a resource, first run the kubectl diff command to preview the changes. Verify that the changes are as expected. 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, existing listeners are not affected if the AlbConfig YAML file does not contain a listeners configuration. If this configuration is present, the listeners are reconciled based on the new configuration. Therefore, you must specify all required listeners, such as the common listeners on ports 80 and 443.
```
kubectl -n kube-system edit AlbConfig alb-demo
```
In the AlbConfig configuration file, update the content as needed. For example, change the name of the AlbConfig to test.
```
...
 spec:
   config:
     name: test # Enter the updated name.
...
```

Use an IngressClass to associate an AlbConfig with an Ingress

You can associate an AlbConfig with an Ingress using a standard Kubernetes IngressClass resource. First, create an IngressClass, and then use it to associate the AlbConfig.

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 is used to associate the AlbConfig with the IngressClass named alb.

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 the IngressClass.

Modify the name of an ALB instance

Run the following command to modify the ALB instance name.

kubectl -n kube-system edit AlbConfig alb-demo

In the configuration file, modify the value of config.name. The new name takes effect automatically after you save the file.

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

Use an IPv6 address

When you create an Application Load Balancer (ALB) instance, you can enable IPv6 support by setting the addressIpVersion field to DualStack in the AlbConfig.

Important

The addressIpVersion field is set 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

When you configure an HTTPS listener in an AlbConfig, you can specify a TLS security policy. You can choose from custom policies and default 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 in Simple Log Service

To enable ALB Ingress to collect access logs, you can specify logProject and logStore in the AlbConfig.

Note

You must manually create the logProject because it cannot be created automatically. 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 created automatically.

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 go to the Simple Log Service console and click the specified LogStore to view the collected access logs.

Reuse an existing ALB instance

If you want to reuse an existing ALB instance, you must specify the ALB instance ID when you create the AlbConfig. The instance must be a Standard Edition or WAF-enabled Edition instance created in the Application Load Balancer (ALB) console. You cannot reuse Basic Edition ALB instances. An ALB instance can be used by only one cluster.

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: reuse-alb
spec:
  config:
    id: **** # The ID of the Standard Edition 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 is not specified or the `id` field is empty, the ALB instance is in a non-reuse scenario. In this case, the `forceOverride` and `listenerForceOverride` fields do not take effect. If the `id` field has a valid value, the ALB instance is reused. Important In reuse mode, do not manually modify the listener name. This prevents the listener from being incorrectly managed or unmanaged by ACS. Listeners created or updated by an AlbConfig are managed by ACS, and their names are in the format of `ingress-auto-listener-{port}` by default. Listeners with names in other formats are managed in the ALB console.
forceOverride	Specifies whether to forcibly overwrite the properties of the ALB instance in reuse mode. `true`: The configuration of the submitted AlbConfig completely replaces the original configuration and listener configuration of the ALB instance. `false`: The properties of the ALB instance are not forcibly overwritten. Whether to forcibly overwrite the listener properties is determined by the `listenerForceOverride` field.
listenerForceOverride	Specifies whether to forcibly overwrite the listener properties in reuse mode. `true`: The ALB Ingress Controller manages all listeners of the ALB instance. The existence and specific configurations of the listeners are subject to the AlbConfig. `false`: The ALB Ingress Controller manages only the listeners created by the AlbConfig in the cluster. The listener names are in the format of `ingress-auto-listener-{port}` by default, and their specific configurations are subject to the AlbConfig in the cluster. The existence and specific configurations of other listeners are not managed by the AlbConfig.

Create a listener

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

Note

The HTTP protocol is automatically compatible with WebSocket. No special settings are required.

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

Create and use multiple ALB instances

To use multiple ALB instances, specify different IngressClasses in the Ingress 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:                          # To ensure high availability, select at least two vSwitches in different zones.
    - vSwitchId: vsw-uf6ccg2a9g71hx8go**** # Replace with the actual vSwitch ID (in Zone 1).
    - vSwitchId: vsw-uf6nun9tql5t8nh15**** # Replace with the actual vSwitch ID (in Zone 2, which must be different from the first one).

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 an 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. The file uses 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 connection request timeout period

In an AlbConfig, you can set the connection request timeout for a listener. The timeout can be set from 1 to 180 seconds. If a backend server does not respond within the timeout period, the load balancer stops waiting and returns an HTTP 504 error code to the client. If you do not specify a timeout, the default value of 60 seconds is used. The following YAML file provides an example.

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

Use the data compression feature

In an AlbConfig, you can specify a listener and enable or disable data compression. The valid values for gzipEnabled are:

true: Compresses specific file types.
false: Does not compress any file types.

Note

Brotli supports compressing all file types. Gzip supports compressing file types such as 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 of how to disable data compression:

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

Obtain the originating IP address of a client

In an AlbConfig, you can use the X-Forwarded-For header field to obtain the originating IP address of a client. The valid values for the XForwardedForEnabled parameter are:

true: The originating IP address of the client is obtained.
false: The originating IP address of the client is not obtained.

Note

This parameter is supported only by HTTP and HTTPS listeners.

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

Obtain the listener protocol of an instance

In an AlbConfig, you can use the XForwardedForProtoEnabled field to obtain the listener protocol for the instance. The valid values are:

true: Obtains the listener protocol for the instance.
false: Does not obtain the listener protocol for the instance.

Note

Only HTTP and HTTPS listeners support this parameter.

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

Obtain the ID of the load balancer instance

In an AlbConfig, you can obtain the ID of the load balancer instance from the SLB-ID header field. The valid values for the XForwardedForSLBIdEnabled parameter are:

true: The ID of the load balancer instance is obtained.
false: The ID of the load balancer instance is not obtained.

Note

Only HTTP and HTTPS listeners support this parameter.

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

Obtain the listener port of an instance

In an AlbConfig, you can configure the XForwardedForSLBPortEnabled parameter to specify whether to use the X-Forwarded-Port header field to obtain the listener port of an instance. Valid values are:

true: The listener port of the instance is obtained.
false: The listener port of the instance is not obtained.

Note

Only HTTP and HTTPS listeners support this parameter.

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

Obtain the client port of the load balancer instance

In an AlbConfig, you can use the X-Forwarded-Client-srcport header field to obtain the client port of a load balancer instance. The valid values for XForwardedForClientSrcPortEnabled are:

true: The client port of the load balancer instance is obtained.
false: The client port of the load balancer instance is not obtained.

Note

Only HTTP and HTTPS listeners support this parameter.

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

Configure ACL-based access control

You can use an AlbConfig to enable access control for an ALB listener. By setting allow or deny rules for inbound traffic, you can precisely control client requests and manage request forwarding. For more information about access control lists (ACLs), see Access control.

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

The following list describes some of the parameters:

aclType: Specifies the ACL type. Valid values are Black for a blacklist and White for a whitelist.
aclEntries: Specifies the IP address or CIDR block for an access control entry, such as 127.0.0.1/32.

Delete an ALB instance

An ALB instance corresponds to an AlbConfig. Therefore, you can delete an ALB instance by deleting its AlbConfig. Before you delete the AlbConfig, you must first delete all Ingresses associated with it.

kubectl delete -n kube-system AlbConfig alb-demo

Replace alb-demo with the name of the AlbConfig that you want to delete.

Delete the AlbConfig of a reused ALB instance

To delete the AlbConfig of a reused ALB instance, follow these steps.

Delete all Ingresses associated with the AlbConfig.

kubectl delete -n <NAMESPACE> ingress <INGRESS_NAME>  # Replace <INGRESS_NAME> and <NAMESPACE> with the name and namespace of the Ingress that you want to delete.

Run the kubectl edit command to modify the AlbConfig and delete all its listeners. This means deleting all entries under the spec.listeners field.
Important
Perform this step only if the version of the ALB Ingress Controller component installed in the cluster is v2.10.0-aliyun.1 or earlier. Otherwise, skip this step.

Delete the AlbConfig.

kubectl -n kube-system delete AlbConfig alb-demo # Replace alb-demo with the name of the AlbConfig that you want to delete.