Docs

Volcengine Kubernetes Engine

ALB Ingress

Considerations for using ALB Ingresses

When you configure an ALB Ingress, the system will create or reuse an Application Load Balancer (ALB) instance for the Ingress through add-ons. This topic introduces the key considerations when you configure ALB Ingresses.

Create or reuse instances

You can choose to create or reuse an ALB instance when configuring an ALBInstance for a VKE cluster. The following table shows the differences between creating and reusing instances.

Resource objects	Create ALB	Reuse ALB
Instance and listener	The controller will automatically create an ALB instance and a listener based on the configurations of the ALBInstance. When you delete the ALBInstance, the controller will delete the ALB instance and the listener that were automatically created.	Use instanceID: "alb-2dgns526uiv41fi5***" in ALBInstance to specify the ID of the reused ALB instance. The controller will create or reuse a listener based on the listener configuration in ALBInstance. When you delete the ALBInstance, the controller will delete the newly created listener and backend server group, but will not delete the reused ALB instance and listener. tip Only the ALB instances created through the ALB console can be reused. The ALB instances automatically created through ALBInstances cannot be reused. ALB instances need to be in the same VPC as the cluster to provide load-balancing services.
Backend server group	The controller will automatically create a backend server group based on the configurations of the ALB Ingress. When you delete the ALB Ingress, the controller will delete the backend server group that was automatically created.	The controller will automatically create a backend server group based on the configurations of the ALB Ingress. When you delete the ALB Ingress, the controller will delete the backend server group that was automatically created.

Configuration considerations

Resource reuse and configuration changes

Do not create multiple ALBInstances that reuse the same ALB instance, including within the same cluster or across clusters. Otherwise, listeners or forwarding rules may overwrite or delete each other.

Do not configure listeners created through the console, OpenAPI, or the ALB SDK in an ALBInstance. Otherwise, the existing forwarding rules of those listeners may be modified, overwritten, or deleted, causing abnormal service traffic.

Before specifying a listener in an ALB Ingress, you must first declare that listener in the corresponding ALBInstance. For details, see Creating ALB Ingresses by using kubectl.

Do not use the console or OpenAPI to manually modify, replace, or delete ALB instances, listeners, backend server groups, or forwarding rules managed by an ALB Ingress.

Do not modify the names of listeners and backend server groups or any content prefixed with k8s_ in forwarding rule descriptions. Otherwise, manual changes may be overwritten, and the related resources may be reconfigured or deleted, causing service anomalies.

Certificate management

If multiple ALB Ingresses specify different certificates for the same domain name and a certificate already exists for that domain name, the system will decide whether to overwrite the existing certificate according to the status of the certificate specified by the respective ALB Ingress:

If the certificate specified by the ALB Ingress does not exist, the existing certificate will not be overwritten.

If the certificate specified by the ALB Ingress has expired, the existing certificate will not be overwritten.

If the certificate specified by the ALB Ingress exists and has not expired, the existing certificate will be overwritten.

Resource billing

Using ALB incurs fees for cloud infrastructure resources. For details, see ALB billing.

Last updated: 2026.09.02 10:33:07