Diagnose and resolve common ALB Ingress events - Container Service for Kubernetes

ALB Ingress Controller manages and routes external traffic to services within a Kubernetes cluster. When you expose a service through an ALB Ingress, the controller monitors changes to associated Endpoint resources, synchronizes backend node status to the backend server group, and applies those changes to the ALB instance. Synchronization can fail due to configuration errors or quota limits.

Important

Before troubleshooting, upgrade the ALB Ingress Controller to the latest version. See Upgrade the ALB Ingress Controller for instructions. Running an older version may trigger issues that have already been fixed.

How it works

When you access a service through an ALB Ingress, ALB Ingress Controller monitors changes to various resources and synchronizes them to the associated ALB instance. The following figure shows the logical relationships between resources and the synchronization process.

Step 1: Check Ingress events

Ingress events show what the controller is doing and where it fails. Check events first to identify the specific error before looking up a solution.

Using the console: Go to Network > Ingresses. Select the namespace, click the Ingress name, and then click the Events tab.

Using kubectl:

kubectl describe ingress <ingress-name> -n <namespace>

Expected output:

...
Events:
  Type     Reason                  Age                     From     Message
  ----     ------                  ----                    ----     -------
  Warning  FailedBuildModel        2m28s (x10 over 6m43s)  ingress  listener is not exist in alb, port: 443, protocol: HTTPS
  Normal   Sync                    19s (x32 over 11d)      ingress  Scheduled for sync
  Normal   SuccessfullyReconciled  4s (x20 over 11d)       ingress  Successfully reconciled

The Description column (console) or Message field (kubectl) shows the event details.

Scheduled for sync: The controller has started processing the event.
Successfully reconciled: The reconciliation completed without errors.
Warning events: The controller encountered a problem. See Step 2 for solutions.

If no events appear or only Normal events appear but changes are not taking effect, go to Step 3.

Step 2: Resolve anomalous events

Find the error message from Step 1 in the table below and follow the solution.

Error message	Cause	Solution
listener does not exist in alb, port: 80, protocol: HTTP	In ALB Ingress Controller V2.11.0 and later, listeners are only associated with an Ingress, not automatically created. This error means the listener does not exist in the `AlbConfig`.	Create the required listener for the Ingress resource in the AlbConfig.
listener not found for (80/HTTP), with ingresses 1	In ALB Ingress Controller V2.11.0 and later, this error occurs when a listener is removed from an `AlbConfig` that is still associated with an Ingress. The error message includes the missing listener and the number of associated Ingresses.	Remove all Ingresses associated with the listener before removing the listener from the `AlbConfig`. If the listener was removed by mistake, add it back.
no certificate found for host	TLS is enabled with certificate auto-discovery, but no matching certificate for the domain was found in Certificate Management Service.	- Configure certificate auto-discovery: Create a certificate in the Certificate Management Service console. The controller automatically matches the certificate to the domain configured for TLS in the ALB Ingress. <br>- Specify a certificate directly: Configure a certificate using an AlbConfig.
The param Rules.1.RuleConditions.2.PathConfig.Values.1 is illegal	The forwarding rule contains an invalid path value.	- If the Ingress uses the `rewrite` annotation, set `pathType` to `Prefix`. <br>- Otherwise, check the `path` field for invalid characters. For non-regex paths, the value must start with `/` and can only contain letters, numbers, and these special characters: `$`, `+`, `/`, `&`, `~`, `@`, `_`, `-`, `.`, `:`. Wildcard characters `*` and `?` are also supported.
The param ServerGroupName is illegal	The ALB backend server group name is in an invalid format.	Check the server group name. The name is generated in `namespace+ServiceName+port` format. It must be 2–128 characters, start with a letter, and contain only numbers, `.`, `_`, and `-`.
The specified resource sgp-vz2fb219vv792flx3u is in use	The ACK-managed ALB backend server group is referenced by another ALB instance.	Log on to the ALB console. Go to ALB > Server Groups, find the backend server group, and dissociate the ALB instance.
Message: Invalid parameter. Check the parameter input.	The certificate ID in the `AlbConfig` is incorrectly configured — likely a numeric ID instead of a resource ID.	Use the resource ID specified by `CertIdentifier`, not the numeric ID.
Message: Failed to create SSL Certificate with name default-https-secret-1-b585e6 ({namespace}-{name}-{identity}). Error: The certificate has expired.	The Secret certificate has expired. The certificate name in the error message follows the `{namespace}-{name}-{identity}` format: `{namespace}` is the namespace where the Secret is located (for example, `default`), `{name}` is the Secret resource name (for example, `https-secret-1`), and `{identity}` is the hash of the Secret content (for example, `b585e6`).	1. Update the expired certificate in the `secretName` field of the Ingress. The new certificate must be valid for at least one day from the current date. <br>2. Alternatively, remove the `secretName` configuration and switch to certificate auto-discovery. <br><br>For details, see Configure certificates for encrypted communication over HTTPS.
failed to createSSLCertificateWithName: XXX <br>ErrorCode: NameRepeat <br>Message: The name is already used. Please enter another name.	The Ingress uses a Secret certificate. After the certificate expired, uploading a new certificate through an `AlbConfig` reused the expired certificate's name, causing a duplicate SSL certificate name.
invalid server group Cookie:	- Empty cookie value: Session persistence is configured to rewrite a cookie (`sticky-session-type: "Server"`), but the `cookie` annotation is empty. <br>- Unsupported controller version: ALB Ingress Controller versions earlier than V2.15.0-aliyun.1 do not support custom cookies for server group session persistence.	- Empty cookie value: Set a non-empty cookie value. For example: <br>  `alb.ingress.kubernetes.io/cookie: "test"` <br>  For annotation details, see Use annotations to implement session persistence. <br>- Unsupported version: Upgrade the ALB Ingress Controller.
The quota of alb_quota_server_added_num is exceeded for resource eni-xxxx, usage 202/200	The `alb_quota_server_added_num` quota is reached. This quota limits how many times a backend server IP address can be added to ALB backend server groups.	Go to Quota Center to increase the server group quota.

Step 3: Diagnose silent failures

If changes are not taking effect but no Warning events appear, the IngressClass and AlbConfig binding is likely misconfigured. When the IngressClass points to the wrong AlbConfig, the controller does not process change events for that Ingress.

To diagnose:

Verify that spec.parameters in the IngressClass references the correct AlbConfig resource name.
Check whether reconciliation events for the AlbConfig are triggered at all.

For details on the IngressClass-to-AlbConfig binding, see Use an IngressClass to associate an AlbConfig with an Ingress.