Most errors that occur to running applications deployed in Container Service for Kubernetes (ACK) clusters in Enterprise Distributed Application Service (EDAS) are pod errors. This topic describes common pod errors and their solutions.

Common pod errors

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>