Container Service for Kubernetes:ALB Ingress FAQ

How does ALB Ingress differ from Nginx Ingress?

ALB Ingress is built on Alibaba Cloud Application Load Balancer (ALB) and is fully managed—no infrastructure to operate or maintain. For a detailed comparison of Nginx Ingress, ALB Ingress, and MSE Ingress, see Comparison of Nginx Ingress, ALB Ingress, and MSE Ingress.

Does ALB Ingress support both public and private network access?

Yes. Create a public ALB instance. It allocates an elastic IP address (EIP) in each zone for public traffic and also provides a private virtual IP address (VIP) for private network access. For private-only access, create a private ALB instance instead.

How do I ensure ALB Ingress uses a fixed ALB domain name?

The domain name is tied to the ALB instance referenced by your AlbConfig. As long as the IngressClass and AlbConfig associated with your Ingress remain unchanged, the domain name stays the same.

Why can't I find the ALB Ingress Controller pod in my cluster?

The ALB Ingress Controller pod is visible in the kube-system namespace only in ACK dedicated clusters. ACK Basic Edition, ACK Pro Edition, and ACK Serverless fully manage the controller, so no pod is visible in those clusters. To migrate, see Hot migrate an ACK dedicated cluster to an ACK managed cluster Pro Edition.

How do I attach backend pods to ALB by IP address?

Add the annotation alb.ingress.kubernetes.io/server-group-type: Ip to the Service. This creates an IP-based server group so ALB can register backend pods by IP address.

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

Keep the following constraints in mind:

• Server group type is immutable. You cannot change it after creation. In Flannel network mode, switching the Service type (for example, between ClusterIP and NodePort) changes the attachment type between IP and ECS, which breaks existing server group membership. To change the type, create a new Service with the annotation set to Ip.

• Create the Service before the Ingress. If the referenced Service does not exist when the Ingress is created, the ALB Ingress Controller creates the server group before reading Service annotations and defaults to instance type. This causes IP-based attachment to fail.

• Do not delete the annotation. Removing alb.ingress.kubernetes.io/server-group-type: Ip after creation causes a mismatch between the server group type and the Service, leading to reconciliation failures.

What is the kube-system-fake-svc-80 server group used for?

Every ALB listener requires a default forwarding rule pointing to a server group. The kube-system-fake-svc-80 server group fulfills this requirement so listeners can be created. It does not handle any business traffic, but do not delete it.

How do I configure domain name resolution for Ingress?

1. Register a domain name.

2. Add a CNAME record. > Set the record type to CNAME, the host record to @ (resolves the root domain, such as ingress-demo.com, directly), and the record value to your Ingress endpoint address.

3. In a browser, go to http://ingress-demo.com/coffee to verify that resolution works. > Replace ingress-demo.com with your actual registered domain name. If resolution fails, see Quickly troubleshoot DNS resolution failures.

   

How do I configure HTTPS encryption for Ingress?

1. Purchase an official certificate, complete the certificate request, and confirm the certificate status is Issued.

2. Download the SSL certificate. > Download the PEM-formatted file for your domain (for example, ingress-demo.com). Set the server type to Other.

3. Create a secret to store the certificate.

   1. On the Clusters page, click your cluster name. In the left navigation pane, choose Configurations > Secrets.

   2. On the Secrets page, select the default namespace and click Create. Enter the following values and click OK.

      • Name: ingress-tls

      • Type: TLS Certificate

      • Certificate: Contents of the downloaded .pem file.

      • Key: Contents of the downloaded .key file.

4. Add an HTTPS:443 listener to AlbConfig.

   1. In the left navigation pane, choose Workloads > Custom Resources. On the Resource Objects tab, search for and click AlbConfig.

   2. Find the alb resource and click Edit YAML in the Actions column.

   3. Add spec.listeners.port: 443 and spec.listeners.protocol: HTTPS, then click OK.

5. Update the Ingress to add TLS settings.

   1. In the left navigation pane, choose Network > Ingresses. In the Actions column of the target Ingress, click Update.

   2. Add the following and click OK.

      • TLS Settings: Enabled

      • Domain Name: ingress-demo.com

      • Secret: ingress-tls

      • Annotation: alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]

6. In a browser, go to https://ingress-demo.com/coffee to verify HTTPS access. > Replace ingress-demo.com with your actual registered domain name.

   

For more details, see Configure HTTPS certificates for encrypted communication.

Why does my ALB instance downgrade from WAF Enhanced Edition to Standard Edition?

When the ALB Ingress Controller reconciles, it compares the actual ALB instance edition with the edition field in AlbConfig. If AlbConfig does not explicitly specify edition: StandardWithWaf, the controller resets the instance to the default Standard Edition, which downgrades WAF.

To keep WAF Enhanced Edition, explicitly set edition: StandardWithWaf in AlbConfig when you create a new ALB instance or upgrade or downgrade an existing one.

Why do I get HTTP 503, 502, or 404 errors when accessing my Ingress domain?

Start by running kubectl describe ingress <ingress-name> -n <namespace> and checking the Events section for error messages. The following table maps common errors to their most likely causes.

For the full list of ALB status codes, see ALB status codes.

If you see a listener does not exist in alb event, create the required listener in AlbConfig:

Events:
  Type     Reason             Age   From     Message
  ----     ------             ---   ----     -------
  Warning  FailedBuildModel   ***   ingress  listener is not exist in alb, port: 443, protocol: HTTPS
  Warning  FailedBuildModel   ***   ingress  listener not found for (443/HTTPS), with ingresses 1

To diagnose further, work through these checks in order:

1. Check backend endpoints. Run kubectl get endpoints <service-name> -n <namespace> and confirm the ENDPOINTS field contains at least one healthy pod IP and port. If the field is empty, verify that the Service selector matches the pod labels and that the pods are in Running state.

2. Check pod status and logs. Run kubectl get pod -l <app=your-app> -n <namespace> to check pod state. Then run kubectl logs <pod-name> -n <namespace> to inspect a specific pod for startup failures or request errors.

3. Test network connectivity. From within another pod or directly on a node, use curl against the Service ClusterIP or a pod IP to confirm the service is reachable inside the cluster.

After configuring Ingress TLS, why is HTTPS still inaccessible?

Check these three things in order:

1. Listener port. Run kubectl describe albconfig <alb-name> -n <namespace> and confirm that spec.listeners.port: 443 and spec.listeners.protocol: HTTPS are present.

2. Ingress annotation. Confirm the Ingress has the annotation alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]. Without it, ALB does not associate the Ingress with the HTTPS listener.

3. Secret configuration. Check the secretName in spec.tls of the Ingress. Run kubectl get secret <secret-name> -n <namespace> -o yaml to confirm the secret type is kubernetes.io/tls and that tls.crt and tls.key are correctly populated.

If you updated a certificate in Certificate Management Service but HTTPS is still failing, confirm that the certificate ID in AlbConfig has been updated to reference the new certificate. Also verify whether automatic certificate discovery reconciliation has been triggered, as the ALB instance may still reference the old certificate if reconciliation has not run.

Why are my new ALB Ingress rules not taking effect?

ALB instances apply routing rules in serial order. If any Ingress resource sharing the same ALB instance is misconfigured, the controller blocks all pending rule changes until the error is fixed. Identify and fix the misconfigured Ingress first, then your new rules will apply.

ALB Ingress shows no errors, but configuration changes are not taking effect. What should I do?

Check the parameters field in your IngressClass. If the binding between IngressClass and AlbConfig is incorrect, Ingress changes are silently ignored. For step-by-step instructions, see Associate AlbConfig with Ingress using IngressClass.

ALB Ingress forwarding rules are deleted immediately after creation, causing 503 errors. What should I do?

Canary releases require a baseline Ingress without the canary: true annotation—ALB routes traffic to the baseline and sends a portion to the canary. Without a baseline Ingress, there is no valid forwarding target, and the rules are removed immediately.

Check whether all Ingress resources associated with the forwarding rules have canary: true. If so, remove canary: true from one Ingress to make it the baseline. For instructions, see Implement phased releases with ALB Ingress.

Canary releases support only two Ingress resources and have limited routing conditions. For richer traffic routing, use custom forwarding rules. See Customize ALB Ingress forwarding rules.

AlbConfig reports "listener is not exist in alb, port: xxx"

The default AlbConfig includes only a listener for port 80. To listen on other ports, add the corresponding listener configurations to AlbConfig. See Create listeners.

After configuring HTTP and HTTPS listeners in AlbConfig, why can't I access either port?

Add the alb.ingress.kubernetes.io/listen-ports annotation to the Ingress resource. Without it, ALB Ingress does not associate the Ingress with the configured listeners.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: https-ingress
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
spec:
  # ...

Why do manual changes in the ALB console get overwritten?

ALB Ingress stores its configuration in the cluster API server as Ingress and AlbConfig resources. Manual changes made in the ALB console are not written back to the API server. When reconciliation runs, the controller overwrites console state with the values from the cluster. Make all configuration changes through Ingress or AlbConfig resources, not through the ALB console.

Why do I get "Specified parameter array contains too many items, up to 15 items, Certificates is not valid"?

Certificate pagination was introduced in ALB Ingress Controller v2.11.0-aliyun.1. If your controller version is older, it cannot handle more than 15 certificates in a single reconciliation. Upgrade to the latest version to resolve this. See ALB Ingress Controller version information and Manage ALB Ingress Controller components.

After running kubectl apply to update AlbConfig ACL settings, some listeners are deleted. What should I do?

kubectl apply performs a full overwrite of AlbConfig. Any listener not listed in your YAML file is deleted.

If listeners were already deleted, restore them:

1. Check whether your YAML file lists all listeners. If any are missing, proceed to the next step.

2. Run the following command to edit AlbConfig and add back the missing listeners.

   kubectl -n <namespace> edit albconfig <albconfig-name>

How do I reduce server reconciliation time during pod scaling?

Reconciliation time increases with the number of Ingress resources attached to a Service. To reduce it:

• Attach no more than 30 Ingress resources to a single Service.

• If you have many Ingress resources, consolidate: attach multiple Services to a single Ingress and define multiple forwarding rules within it.

How do I auto-assign node weights based on pod count when using Flannel with Local-mode Services?

Node weight auto-assignment is supported starting from ALB Ingress Controller v2.13.1-aliyun.1. Upgrade to the latest version first. See Upgrade ALB Ingress Controller components.

In Flannel clusters with Local-mode Services, the controller sets node weights as follows. The example below uses three ECS instances running pods (app=nginx), exposed by Service A.