You need to enable JavaScript to run this app.
Volcengine Kubernetes Engine

Volcengine Kubernetes Engine

Copy page
Download PDF
Fault diagnosis
Ingress diagnosis
Copy page
Download PDF
Ingress diagnosis
Ingress diagnosis helps you identify risks in Ingress resources, such as ALB Ingresses and CLB Ingresses, within VKE clusters. This topic describes how to configure the Ingress diagnosis feature.​
Prerequisites​
The Ingress feature has been configured. For details, see Ingresses.​
Configuring diagnosis​
  1. Log in to the VKE console.​
  1. In the left navigation pane, click Cluster. Click the target cluster name to go to the management page of this cluster.​
  1. In the left navigation pane, click Diagnosis. On the page that appears, click Create diagnosis task to configure an Ingress diagnostic task.​
  • ​
    Parameter​
    Description​
    Diagnosis type​
    Specify the type of resource to be diagnosed. For this example, select Ingress.​
    URL address​
    Specify the URL address to be diagnosed.​
    ​
  1. Click Confirm to complete the configuration. The system will start the diagnosis and generate a diagnostic report.​
Viewing diagnostic results​
After the diagnostic task is complete, if it is in the Anomaly state, it indicates that risks exist. You can click View details in the Actions column that corresponds to the target diagnostic task to view the diagnostic report.​
The diagnostic result will display all diagnostic items, including successful, failed, and warning ones. You need to view these items on the Pending tab and resolve the issues.​
Downloading diagnostic reports​
After the diagnostic task is complete, you can download the diagnostic report in PDF format.​
  1. After the diagnostic task is complete, click View details in the Actions column that corresponds to the target diagnostic task to view the diagnostic result.​
  1. Click Download the report in the upper-right corner to download the diagnostic report in PDF format.​
Diagnostic item descriptions and fix suggestions​
Ingress diagnosis​
Ingress diagnosis mainly checks the availability of Ingress resources in the cluster and the compliance of annotation usage with specifications. The following table describes the main check items.​
​
Diagnostic item​
Check content​
Fix suggestions​
Reference​
Whether the Ingress exists​
Check whether the corresponding Ingress resources exist.​
  • Check whether the provided URL has a corresponding Ingress rule.​
  • If the URL is correct, the issue may lie with the Ingress rule. For example, a regular expression is used as the path instead of the use-regex annotation.​
warning​
The provided URL must contain a complete domain name and path. For example, example.com/demo. Otherwise, the diagnosis will fail and indicate that the Ingress does not exist.​
-​
Whether an address exists on the Ingress​
Check whether the address of the Ingress has been updated by the Ingress controller.​
Check whether the corresponding Ingress controller exists for the IngressClass, and whether the controller is working as expected. For details, refer to the check results of other items.​
-​
Whether the nginx.com/nginx.org annotation is used​
Check whether a commercial Ingress annotation that starts with nginx.com/nginx.org is used. This configuration cannot be used on the community edition NGINX Ingress controller.​
Check the current Ingress controller version. Remove this annotation or use another annotation.​
-​
Whether mirror-uri is used​
Check whether the nginx.ingress.kubernetes.io/mirror-uri annotation is used. This annotation was deprecated in v0.24.0.​
Check the current Ingress controller version. Remove this annotation or use another annotation.​
-​
Whether grpc-backend is used​
Check whether the nginx.ingress.kubernetes.io/grpc-backend annotation is used. This annotation was deprecated in v0.21.0.​
Check the current Ingress controller version. Remove this annotation or use another annotation.​
-​
Whether base-url-scheme is used​
Check whether the nginx.ingress.kubernetes.io/base-url-scheme annotation is used. This annotation was deprecated in v0.22.0.​
Check the current Ingress controller version. Remove this annotation or use another annotation.​
-​
Whether session-cookie-hash is used​
Check whether the nginx.ingress.kubernetes.io/session-cookie-hash annotation is used. This annotation was deprecated in v0.24.0.​
Check the current Ingress controller version. Remove this annotation or use another annotation.​
-​
Whether secure-backends are used​
Check whether the nginx.ingress.kubernetes.io/secure-backends annotation is used. This annotation was deprecated in v0.21.0.​
Check the current Ingress controller version. Remove this annotation or use another annotation.​
-​
​
Add-on diagnosis​
Add-on diagnosis mainly checks the startup parameters of the Ingress add-on, the Ingress service, and whether pods work as expected. The following table describes the main check items.​
​
Diagnostic item​
Check content​
Fix suggestions​
Reference​
Proportion of ready pods for the Ingress​
Check whether the proportion of ready pods in the Ingress Deployment is 100%. If the proportion is less than 100%, it indicates that an issue exists with the Ingress pod, such as a start failure or health check failure.​
View the readiness status of ingress-nginx-controller for the Deployment in the kube-system namespace. If necessary, view the events and process the fault based on the event prompts.​
-​
Whether the Ingress service exists​
Check whether the service exists in the Ingress startup parameters. After this service is deleted, the Ingress may fail to start.​
Check whether the service is mistakenly deleted, and fix the issue.​
Whether the Ingress service has events​
Check whether warning or error events exist on the Ingress service. This may be caused by invalid CLB instance configurations.​
View the warning or error events of the service and process the fault based on the event prompts.​
-​
Whether the Ingress service has endpoints​
Check whether the Ingress service has valid endpoints. If endpoints do not exist, the CLB instance will be unable to forward traffic to the Ingress controller.​
  • Check whether the configurations of the label selector for the service are correct.​
  • Check whether the back-end pods of the service are mistakenly deleted, and fix the issue.​
-​
Whether the Ingress service is of the Load Balancer type​
Check whether the service specified in the Ingress startup parameters is of the LoadBalancer type. If it is not of this type, the Ingress controller may not be accessed over the public network.​
Check whether a service of the Load Balancer type is required.​
  • Not required: This warning can be ignored.​
  • Required: Change the type of service to Load Balancer.​
Whether the Ingress service has external IP addresses​
Check whether an IP address is allocated to the service. If it does not exist, the Ingress cannot be accessed over the public network.​
View service events and check whether the service status and the CLB quota are normal.​
-​
Whether the leader pod exists​
Check whether the leader election is successful and whether a leader pod exists. If it does not exist, this may be because the pod may start for a short period, or some issues exist with the Ingress controller permissions configuration.​
-​
-​
External traffic policy of the Ingress service​
Check the external traffic policy of the service, which is used to distribute external traffic after being routed to the cluster.​
The default external traffic policy is Local, which can be changed to Cluster. We recommend that you use Local mode. Otherwise, the client source IP may not be retained, which will result in inaccurate CLB instance health checks.​
​
CLB instance diagnosis​
CLB instance diagnosis mainly checks the status, maximum number of connections, QPS, and health check for the Ingress controller CLB instance. The following table describes the main check items.​
​
Diagnostic item​
Check content​
Fix suggestions​
Reference​
Health check failure of the Ingress controller CLB instance​
Check whether the CLB instance has health check failures in the last 3 days. This may be caused by excessive add-on load or configuration errors.​
Check whether exceptions occur on the Ingress controller service, and whether the add-on load is high. Process the fault based on the event prompts.​
-​
Whether the CLB instance of the Ingress controller exists​
Check whether the CLB instance of the Ingress controller exists.​
In the CLB console , check whether the corresponding CLB instance exists. If the CLB instance was mistakenly deleted, you can restore it by recreating the service.​
-​
CLB instance ID​
Check whether the CLB instance ID of the Ingress controller exists.​
-​
-​
Health check status of the Ingress controller CLB instance​
Check whether the health check status of the CLB instance back-end servers that correspond to the Ingress is normal.​
Check whether exceptions occur on the Ingress controller service, and whether the add-on load is high.​
-​
New connection rate of the Ingress controller CLB instance​
Check whether the maximum rate of new connections for the CLB instance in the last 3 days exceeds 80% of the upper limit. After the rate of new connections reaches the upper limit, new connections cannot be established for a short period of time, which will cause client access failures.​
The new CLB connections are excessive. To prevent your business from being affected, upgrade the instance type.​
Maximum number of connections for the Ingress controller CLB instance​
Check whether the maximum number of CLB connections in the last 3 days exceeds 80% of the upper limit. After the number of connections reaches the upper limit, new connections cannot be established, which may cause clients to be unable to access the service.​
The maximum CLB connections are excessive. To prevent your business from being affected, upgrade the instance type.​
Whether Host and SecretName are configured during TLS configuration​
Check whether both the Host and SecretName fields are configured when the Ingress TLS rule is configured.​
Specify both the Host and SecretName fields, and make sure that the Host field matches the certificate information.​
​
​
Last updated: 2026.07.23 17:53:05