The ACK console includes an Ingress diagnostics feature that checks common Ingress configuration problems and surfaces actionable fix guidance. This page lists every diagnostic item, what it checks, and how to fix it.
When you run diagnostics, ACK deploys a data collection program to each node in the cluster. It collects system version, load status, Docker and kubelet status, and key error messages from system logs. It does not collect business data or sensitive information.
Diagnostic items vary by cluster configuration. The items shown on the diagnostics page reflect the actual checks available for your cluster.
How Ingress diagnostics works
Diagnostics run across three layers in order:
Ingress — validates Ingress resource definitions and annotations.
Add-on — checks the Ingress controller's startup parameters, associated Service, and pod health.
SLB — inspects the Server Load Balancer (SLB) instance used by the Ingress controller.
Start from the Ingress layer and work down. Most issues are caught in the first two layers. SLB checks apply when traffic fails to reach the cluster at all.
Diagnostic items
Ingress
| Diagnostic item | What it checks | How to fix |
|---|---|---|
| Ingress check | Whether the specified Ingress exists. | Verify that an Ingress rule exists for the URL. Check whether the path uses a regular expression and whether the use-regex annotation is set correctly. |
base-url-scheme check | Whether the deprecated nginx.ingress.kubernetes.io/base-url-scheme annotation is present. This annotation is deprecated in Ingress Controller 0.22.0. | Check your Ingress controller version. Remove the annotation or replace it with a supported alternative. |
grpc-backend check | Whether the deprecated nginx.ingress.kubernetes.io/grpc-backend annotation is present. Deprecated in Ingress Controller 0.21.0. | Check your Ingress controller version. Remove the annotation or replace it with a supported alternative. |
mirror-uri check | Whether the deprecated nginx.ingress.kubernetes.io/mirror-uri annotation is present. Deprecated in Ingress Controller 0.24.0. | Check your Ingress controller version. Remove the annotation or replace it with a supported alternative. |
secure-backends check | Whether the deprecated nginx.ingress.kubernetes.io/secure-backends annotation is present. Deprecated in Ingress Controller 0.21.0. | Check your Ingress controller version. Remove the annotation or replace it with a supported alternative. |
session-cookie-hash check | Whether the deprecated nginx.ingress.kubernetes.io/session-cookie-hash annotation is present. Deprecated in Ingress Controller 0.24.0. | Check your Ingress controller version. Remove the annotation or replace it with a supported alternative. |
nginx.com/nginx.org check | Whether the Ingress uses annotations that start with nginx.com or nginx.org. These annotations are for the commercial NGINX Ingress controller and are not recognized by the open source version. | Switch to annotations supported by the open source NGINX Ingress controller. See NGINX Ingress management or the NGINX Ingress Controller documentation. |
| Canary status | Whether nginx.ingress.kubernetes.io/canary: "true" is set. Without this annotation, canary routing rules have no effect. | Add the annotation to the Ingress: nginx.ingress.kubernetes.io/canary: "true". |
Add-on
| Diagnostic item | What it checks | How to fix |
|---|---|---|
| Ingress pod readiness percentage | The percentage of Ingress pods in the Ready state relative to the replicas defined in the Deployment. A value below 100% means some pods failed to start or failed their health check. | Check pod error logs to identify the failing pods, then fix the underlying issue. See NGINX Ingress controller troubleshooting. |
| Ingress IP address check | Whether the Ingress controller has assigned an IP address to the Ingress. | If no IP address is assigned, verify that the correct IngressClass is referenced and that the Ingress controller is running normally. |
| Leader pod check | Whether a leader pod has been elected. No leader pod means the controller is not processing Ingress rules — this can happen if the pod startup time is too short or if the permissions of the Ingress controller are not properly configured. | Check Ingress pod error logs and fix any errors shown. See NGINX Ingress controller troubleshooting. |
| NGINX Ingress annotations | Whether any annotations starting with nginx.com or nginx.org are in use. The open source NGINX Ingress controller only recognizes nginx.ingress.kubernetes.io annotations. Unrecognized annotations are silently ignored, so configurations may not take effect. | Replace nginx.com/nginx.org annotations with the equivalent nginx.ingress.kubernetes.io annotations. See the Annotations reference. |
rewrite-target and capture groups | Whether rewrite-target is used with capture groups. In Ingress Controller 0.22.0 and later, capture groups must be explicitly defined when using rewrite-target; omitting them causes traffic forwarding errors. | Update your Ingress to use capture groups with rewrite-target. See Advanced NGINX Ingress configurations. Example: set nginx.ingress.kubernetes.io/rewrite-target: /$1 with a path like /api/(.*). |
| Canary service count | Whether service-match or service-weight specifies more than two Services. These annotations support traffic splitting between exactly two Services. Extra Services are silently ignored. | Reduce the number of Services in service-match or service-weight to two. See NGINX Ingress canary releases and blue-green deployments. |
| Ingress name | The names of matching Ingress rules. | Informational only. No action required. |
| Pod error logs | Whether Ingress controller pods are generating error logs. Error logs indicate the controller may not be processing rules correctly. | Identify the error cause from the logs and fix it. See NGINX Ingress controller troubleshooting. |
rewrite-target path capture groups | Whether paths using nginx.ingress.kubernetes.io/rewrite-target define the required capture groups. In Ingress Controller 0.22.0 and later, missing capture groups cause path routing errors. | Add capture groups to affected paths. See Configure routing rules to redirect traffic from specific URLs. |
Multiple targets in service-* | Whether service-match or service-weight specifies more than two Services. | Set exactly two Services in service-weight or service-match. See NGINX Ingress canary releases and blue-green deployments. |
| Ingress Service check | Whether the Service referenced in the Ingress controller startup parameters exists. A missing Service prevents the controller from starting. | Check the Deployment startup parameters for the deleted Service name and restore it. See High-risk operations related to networks and SLB instances. |
| Ingress Service endpoint check | Whether the Service associated with the Ingress has at least one endpoint. Without an endpoint, the SLB instance cannot route traffic to the Ingress controller. | Verify that the Service's label selector matches the labels on the Ingress controller pods. |
| Ingress Service events | Whether the Service associated with the Ingress has Warning or Error events. These typically indicate SLB configuration errors. | Review the Service events to identify the root cause, then fix the issue. See Service errors and solutions. |
| Ingress Service external traffic policy | The external traffic policy for the Ingress Service. The default is Local. In Cluster mode, client IP addresses are not preserved, which can cause health check results to be inaccurate. | Keep the policy as Local unless your workload requires Cluster mode, or you need to reach the Ingress controller from within the cluster via its SLB IP address. |
| Ingress Service external IP address | Whether the cloud controller manager has assigned an external IP address to the Ingress Service. Without an IP address, the Ingress is not reachable from the internet. | Check the Service status, cloud controller manager status, and SLB quotas. Most issues are exposed as Service events. |
| Ingress Service type | Whether the Service referenced in the Ingress controller startup parameters is of type LoadBalancer. A non-LoadBalancer Service type makes the Ingress controller inaccessible from the internet. | Change the Service type to LoadBalancer if external access is required. This check does not apply if your setup intentionally uses a different Service type. |
--force-namespace-isolation check | Whether the deprecated --force-namespace-isolation startup parameter is in use. This parameter is deprecated in Ingress Controller 0.24.0. | Check your Ingress controller version and remove the startup parameter from the Deployment. |
--sort-backends check | Whether the deprecated --sort-backends startup parameter is in use. This parameter is deprecated in Ingress Controller 0.22.0. | Check your Ingress controller version and remove the startup parameter from the Deployment. |
SLB
| Diagnostic item | What it checks | How to fix |
|---|---|---|
| SLB instance | Whether the SLB instance used by the Ingress controller exists. | Check whether the Ingress controller Service has anomaly events and whether the SLB instance appears in the SLB console. If the instance was accidentally deleted, recreate the Service. See What do I do if I accidentally delete an SLB instance? |
| SLB backend server health | Whether all backend servers of the SLB instance are healthy. | If backend servers are unhealthy, check for anomaly events on the Ingress controller Service and verify that controller pods are not overloaded. See NGINX Ingress controller troubleshooting. |
| SLB ID | The ID of the SLB instance. | Informational only. No action required. |
| SLB connection count | Whether the number of active connections on the SLB instance has exceeded 80% of its limit over the past three days. Reaching the limit blocks new client connections. | Upgrade the SLB instance to a higher specification. See Use an existing SLB instance. |
| SLB new connection rate | Whether the rate of new connections on the SLB instance has exceeded 80% of its limit over the past three days. Reaching the limit prevents clients from establishing new connections for a period of time. | Upgrade the SLB instance to a higher specification. See Use an existing SLB instance. |
| SLB QPS | Whether the queries per second (QPS) on the SLB instance has exceeded 80% of its limit over the past three days. Reaching the QPS limit blocks client connections. | Upgrade the SLB instance to a higher specification. See Use an existing SLB instance. |
| TLS host and SecretName | Whether both the host and secretName fields are set for TLS configuration. Both are required; omitting either breaks TLS termination. | Set both host and secretName in the Ingress TLS section, and make sure the host is the same as that in the certificate. |
| SLB health check status | Whether the SLB instance has failed health checks in the past three days. Failures indicate that controller pods may be overloaded or that SLB configuration has errors. | Check for anomaly events on the Ingress controller Service and verify that pods are not overloaded. See NGINX Ingress controller troubleshooting. |