This topic provides answers to some frequently asked questions about Application Load Balancer (ALB) Ingresses.
Table of contents
What is the difference between ALB Ingresses and NGINX Ingresses?
Can I enable internal access and external access for ALB Ingresses at the same time?
Why am I unable to view the ALB Ingress controller pod in the cluster?
How do I ensure that the ALB domain name used by an ALB Ingress does not change?
What do I do if an ALB Ingress does not encounter an error but changes do not take effect?
How do I reduce the server reconciliation time when one or more Services perform pod scaling?
Why do ALB Ingress rules fail to take effect?
ALB Ingresses maintain routing rules in inline mode. If multiple ALB Ingresses use the same ALB instance and the configuration of any ALB Ingress contains errors, the other ALB Ingresses do not take effect.
If the ALB Ingresses that you create do not take effect, an ALB Ingress that you created before you create the current ALB Ingresses may encounter an error. In this scenario, you need to find the ALB Ingress and fix the error so that the newly created ALB Ingresses can take effect.
What is the difference between ALB Ingresses and NGINX Ingresses?
We recommend that you use ALB Ingresses. You need to manually maintain NGINX Ingresses. Unlike NGINX Ingresses, ALB Ingresses are developed based on ALB, a fully managed maintenance-free cloud service. ALB Ingresses can serve as high-performance gateways and provide powerful Ingress traffic management capabilities. For more information about the comparison between NGINX Ingresses and ALB Ingresses, see Comparison among NGINX Ingresses, ALB Ingresses, and MSE Ingresses.
ALB Ingresses listen for requests sent to the kube-system-fake-svc-80 server group by default. What is the purpose of the server group?
You must create a default forwarding rule before you can create a listener. Each forwarding rule can be associated with only one server group. The kube-system-fake-svc-80 server group is fake and used by the default forwarding rule. The fake server group does not process requests and cannot be deleted.
Can I enable internal access and external access for ALB Ingresses at the same time?
Yes, you can enable internal access and external access for ALB Ingresses at the same time. If you want to enable internal access and external access for an ALB Ingress at the same time, you need to create an Internet-facing ALB instance. The ALB instance automatically creates an elastic IP address (EIP) in each zone and uses the EIPs to communicate with the Internet. The ALB instance is also assigned a private virtual IP address (VIP). You can use the VIP to access the ALB instance over an internal network. If you want to enable only internal access for an ALB Ingress, you can create an internal-facing ALB instance.
Why am I unable to view the ALB Ingress controller pod in the cluster?
You can view the ALB Ingress controller pod in the kube-system namespace only if your cluster is a Container Service for Kubernetes (ACK) dedicated cluster. You cannot view the ALB Ingress controller pod in ACK Basic, ACK Pro, and ACK Serverless clusters because the ALB Ingress controller is a fully-managed component in these clusters. For more information about how to update an ACK dedicated cluster to an ACK Pro cluster, see Hot migration from ACK dedicated clusters to ACK Pro clusters.
How do I ensure that the ALB domain name used by an ALB Ingress does not change?
After you use an AlbConfig object to create an ALB instance, the ALB Ingress uses an IngressClass to reference the AlbConfig object. This allows the ALB Ingress to use the domain name of the ALB instance. If you do not modify the IngressClass associated with the ALB Ingress or the AlbConfig object, the domain name remains unchanged.
Is an ALB instance automatically created if I choose to use an ALB Ingress when I create an ACK managed cluster?
No, no ALB instance is created. If you choose to use an ALB Ingress when you create an ACK managed cluster, the system automatically installs the ALB Ingress controller but does not create an ALB instance.
Why are the ALB configuration changes that I made in the ALB console lost, the rules that I added deleted, and access logs disabled?
To modify the configuration of an ALB Ingress, you need to modify the configuration saved in the ALB Ingress or AlbConfig object on the API server of the cluster. If you modify the ALB configuration in the ALB console, the changes are not synchronized to the API server. As a result, the changes do not take effect. In addition, an internal call or a cluster operation will trigger ACK to overwrite the ALB configuration in the ALB console with the configuration saved in the ALB Ingress or AlbConfig object. Therefore, we recommend that you modify the configuration saved in the ALB Ingress or AlbConfig object.
What do I do if the HTTP 503 status code is returned when I delete a forwarding rule of an ALB Ingress immediately after I create the forwarding rule?
Check whether the ALB Ingresses that correspond to the forwarding rule contain the canary:true annotation. To perform canary releases, you need to redirect traffic from the old Service version to the canary version. Therefore, you do not need to add the canary:true annotation to the ALB Ingress of the old Service version. For more information about how to use ALB Ingresses to implement canary releases, see Use ALB Ingresses to perform canary releases.
Canary releases support only two Ingresses and a limited number of forwarding conditions. We recommend that you use custom forwarding rules to route traffic in a more flexible manner. For more information, see Configure custom forwarding rules for ALB Ingresses.
What do I do if an ALB Ingress does not encounter an error but changes do not take effect?
If reconciliations related to an AlbConfig object are not performed or configuration change events are not processed, the IngressClass of the ALB Ingress may be associated with the wrong AlbConfig object. Follow the user guide to check whether the parameters setting of the IngressClass is properly configured. For more information, see Use an IngressClass to associate an AlbConfig object with an Ingress.
Why are some listeners deleted after I create an ALB instance in the console and run the kubectl apply command to update the network ACL configuration in the AlbConfig?
We recommend that you run the kubectl edit command to update resources. To use the kubectl apply command to update resources, run the kubectl diff command to preview the changes and make sure that the changes meet your requirements before running the kubectl apply command. Then, you can run the kubectl apply command to apply the changes to the resources in your cluster.
The kubectl apply command updates an AlbConfig by overwriting it. Therefore, when you run the kubectl apply command to update the network ACL configuration in an AlbConfig, make sure that the YAML file contains the configuration of all listeners specified in the AlbConfig. Otherwise, some listeners will be deleted.
If listeners are deleted after you run the kubectl apply command, we recommend that you use the following method to restore the listeners.
Check whether the YAML file contains the configuration of all listeners.
If some listeners are missing, proceed to the next step. If all listeners are included, no operation is required.
Run the following command to add the configuration of the missing listeners to the AlbConfig:
kubectl -n <namespace> edit AlbConfig <albconfig-name> # Replace <namespace> and <albconfig-name> with the namespace of the AlbConfig object and the name of the AlbConfig object.
How do I reduce the server reconciliation time when one or more Services perform pod scaling?
When Services in an ACK cluster perform pod scaling, the server reconciliation time varies based on the number of Ingresses that are associated with the Services. You can use the following methods to reduce the server reconciliation time:
Limit the number of Ingresses: Make sure that no more than 30 Ingresses are associated with each Service.
Merge Ingress rules: If an excessive number of Ingresses are used, you can associate multiple Services with the same Ingress and then create Ingress rules in the Ingress to improve the server reconciliation efficiency.