Container Service for Kubernetes:ALB Ingress FAQ

Does ALB Ingress support both public and internal network access?

How can I ensure that ALB Ingress uses a fixed ALB domain name?

After you create an ALB instance using an AlbConfig, the ALB Ingress references the AlbConfig through an IngressClass to use the domain name of the corresponding ALB instance. The domain name remains unchanged as long as the IngressClass and AlbConfig associated with the ALB Ingress are not modified.

Symptom

When you search for the ALB Ingress Controller pod in your cluster, you cannot find any related pods in the kube-system namespace.

Solution

You can find the ALB Ingress Controller pod in the kube-system namespace only in ACK dedicated clusters. For ACK standard clusters, ACK Pro clusters, and ACK Serverless clusters, the ALB Ingress Controller component is managed by Alibaba Cloud. Therefore, you cannot find the pod in the cluster. For more information about how to upgrade an ACK dedicated cluster to an ACK Pro cluster, see Hot migrate an ACK dedicated cluster to an ACK Pro cluster.

How do I mount IP-based servers?

apiVersion: v1
kind: Service
metadata:
  annotations:
    alb.ingress.kubernetes.io/server-group-type: Ip
  name: tea-svc
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: tea
  type: ClusterIP

Symptom

After you create an ALB Ingress rule, the routing rule does not take effect as expected. Requests are not forwarded to the corresponding backend service.

Cause

An ALB instance maintains routing rules in a serial manner. This means that if multiple ALB Ingresses use the same ALB instance, a configuration error in one ALB Ingress prevents changes to other ALB Ingresses from taking effect.

Solution

If an ALB Ingress that you create does not take effect, a previously created ALB Ingress may have an error. You must correct the faulty ALB Ingress before the new ALB Ingress can take effect.

Symptom

After you change the configuration of an ALB Ingress or associate it with an AlbConfig, the changes do not take effect, but no anomalous activity is reported.

Solution

If reconciliation events related to the AlbConfig are not executed or change events are not processed, the binding between the IngressClass and the AlbConfig may be incorrect. Check whether the parameters parameter specified in the IngressClass is correct. For more information, see Use an IngressClass to associate an AlbConfig with an Ingress.

Symptom

An ALB Ingress forwarding rule is deleted immediately after it is created. As a result, requests to the service return a 503 status code and traffic is not distributed.

Solution

Check whether the canary:true annotation is added to all Ingresses that correspond to the forwarding rule. A canary release requires a primary version to route traffic. Therefore, you do not need to add the canary:true annotation to the Ingress for the primary version. For more information about how to implement a phased release for a service using ALB Ingress, see Implement a phased release using ALB Ingress.

The canary release method supports only two Ingresses and has limitations. You can use custom forwarding rules for more flexible traffic routing solutions. For more information, see Customize forwarding rules for an ALB Ingress.

Symptom

When you try to access ports other than port 80, the requests fail to connect. The AlbConfig resource reports the "listener is not exist in alb, port: xxx" error. This error indicates that the relevant ports are not being listened on and traffic is not being forwarded.

Solution

By default, an AlbConfig contains a listener only for port 80. To listen on other ports, you must add listener configurations for those ports to the AlbConfig. For more information, see Create a listener.

Symptom

You have configured HTTP and HTTPS listener ports in the AlbConfig. However, when you try to access the service, neither the HTTP nor the HTTPS port is listening for or forwarding traffic. The service is inaccessible through these ports.

Solution

Confirm that you have added the alb.ingress.kubernetes.io/listen-ports annotation to the Ingress resource's annotations. This annotation specifies that the ALB Ingress listens on both the HTTP (80) and HTTPS (443) ports. For example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: https-ingress
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]' # Add this annotation to ensure that the ALB Ingress works correctly when multiple listeners are used.
spec:
  #...

Why are manual configuration changes made in the ALB console lost, added rules deleted, and access logs disabled?

Why do I receive the "Specified parameter array contains too many items, up to 15 items, Certificates is not valid" error during reconciliation?

After I configure an ALB instance in the console, why are some listeners deleted when I run the kubectl apply command to update the access control list (ACL) configuration of the AlbConfig?

Problem

In a Kubernetes environment, when pods associated with a service scale in or out, the server reconciliation process can take a long time. This delay affects the real-time performance of elastic scaling. The reconciliation time increases significantly as the number of associated Ingresses grows.

Solution

To improve server reconciliation efficiency, you can apply the following optimizations:

• Limit the number of Ingresses: Do not attach more than 30 Ingresses to a single service.

• Merge Ingress rules: If you have many Ingresses, you can attach multiple services to a single Ingress. Then, you can define multiple forwarding rules within that Ingress resource to improve server reconciliation performance.

Problem

When you use the Flannel network plugin and configure a service in Local mode, traffic is not distributed evenly across nodes. This imbalance causes high loads on some nodes and prevents balanced traffic distribution. The goal is to automatically assign weights to nodes based on the number of pods on each node for more effective traffic distribution.

Solution

In a cluster that uses the Flannel plugin, node weights are calculated as follows when a service is set to Local mode. The following figure shows an example where application pods (app=nginx) are deployed on three ECS instances and exposed through Service A.