About Kubernetes architecture 3; Debugging

I have done some work on describing Kubernetes architecture do check the link to get both of them aleqxan.medium.com In this article I would be doing some brief explanation on troubleshooting pods in Kubernetes; why Pods fail or containers don’t start and while they crash when running, and what to do to solve this several challenges.

Pod failure

Pods fail basically within two-phase in a cluster, during start-up and runtime failure.

→ During start-up: this is a situation where the containers refuse to start, there are some reasons for this, I would be analyzing the reasons with regards to the kind of errors.

Some start-up container errors and rectifying them

1) ImagePullBackOffmeans the image for one of your containers cannot be retrieved. Some of the following can lead to this;

• The image might not be existing
• The image tag might be wrongly placed
• The image might be in a private repository.

ImagePullBackOff

To debug this error, you would have to view your pods kubectl get pods when you have identified the pod with this error you kubectl describe pod (pod name) , this gives you the description of your pods and their structure, you’ll read through and make corrections, assuming the error was due to a wrong image name, you edit your pod and run the apply command, kubectl apply -f , then your pod should be fine.

2) Pendingthis error could be a result of your cluster not having enough CPU memory to run the pods and in this scenario, the pods are not scheduled to a node.

To fix this, you would need to edit your deployment folder in your YAML file, and reduce the resources allocated to the pods to match the specification for your deployment, then run kubectl apply -f (edited file name) , after doing this your container should be running.

3) RunContainerError this error usually happens when you have a missing config map or secret in your cluster, you run your kubectl get pod (pod name having error) to confirm the error, then create the missing file or configuration either its config map or secret.

RunContainerError

These are some of the basic errors that could affect the start-up of your containers.

→ Runtime failure: these are failures that occur within the cluster after your container is started.

CrashLoopBackOff a status message that indicates one of your pods is in a constant state of flux — one or more containers are failing and restarting repeatedly.

CrashLoopBackOff

Some reasons for this could be any of the following;

• When the liveness probe(Kubelet uses liveness probe to know when to start a container) keeps failing severally, the container is ready to keep trying for as long as possible.
• When you misconfigured your container, probably image is built but the wrong configuration is hindering it from starting.

You can use the following command to examine and address the situation;

• You can check for the logs using kubectl logs pod(pod name)
• If the logs seem much, you can check the tail(the latest details regarding the pod) doing kubectl logs(pod name) --tail=10
• You could get into the pod to check the configuration using kubectl exec -it pod(pod name)bash

These are just some basic debugging steps in the Kubernetes cluster, if you have read through you should be able to solve some bug issues in your cluster when they arise.