：Common pod errors

Common pod errors

• ImagePullBackOff
• CrashLoopBackOff
• RunContainerError
• Pods in the Pending state
• Pods in the Not Ready state

ImagePullBackOff

This error occurs when an ACK cluster fails to pull the image of a container in a pod.

Possible causes:

• The specified image name is invalid. For example, the image name is misspelled or the image does not exist.
• The tag that you specify for the image does not exist.
• The image is in a private repository. The ACK cluster has no credentials to access the repository.

Solutions:

• For the first two causes, you can modify the image name and the tag.
• For the third cause, you must add the access credentials of the private repository to the ACK cluster by using a secret and refer to this secret in the corresponding pod.

CrashLoopBackOff

The corresponding ACK cluster returns this error when a container fails to start.

Possible causes:

• The application in the container fails to start due to an application error.
• The container is incorrectly configured.
• The number of liveness probe failures exceeds the maximum limit.

Solutions:

You can retrieve logs from the container to locate the failure cause. If the container restarts so fast that you cannot view the logs, you can run the following command:

$ kubectl logs <pod-name> --previous

RunContainerError

This error occurs when a container cannot be started.

Possible causes:

• A volume that does not exist is mounted, such as ConfigMap or Secrets.
• A read-only volume is installed as a read/write volume.

Solutions:

Run the following command to collect information and analyze the error:

kubectl describe pod

Pods in the Pending state

A pod remains in the Pending state when an application is created.

Possible causes:

• The corresponding cluster does not have sufficient resources, such as CPU and memory, to run the pod.
• A value of the ResourceQuota object is specified for the current namespace. After you create a pod, the resources in the namespace will exceed the resource quota.
• The pod is bound to a persistent volume claim in the Pending state.

Solutions:

• Run the following command and check the "event" section in the output, or check relevant application events in the console. For more information, see View application events.

  $ kubectl describe pod <pod name>

• If the error is caused by ResourceQuota, run the following command to check the cluster logs:

  $ kubectl get events --sort-by=.metadata.creationTimestamp

Pods in the Not Ready state

If a pod is running but is in the Not Ready state, the readiness probe fails.

Possible causes:

When the readiness probe fails, the pod is not connected to the service and no traffic is forwarded to the corresponding instance.

Solutions:

This error is application-specific. Run the following command and check the "event" section in the output, or check relevant application events in the console. For more information, see View application events.

$ kubectl describe pod <pod name>