Debugging the pods on Kubernetes
Debugging is very important to identify the issue in Pod. sometimes your application may behave differently /wrong. Your Pod has stopped or some other issues happening inside your Pod. You can always debug that to identify the issue and fix it.
So the most basic thing we do to debug the issue is to start with checking the logs. Logs are very crucial part and play very important role in any application. If anything goes wrong we can always check the logs and analyse it. Similar to above we are going to check the logs, events and definition of Pod to identify the issues.
To start with it, we first need to run the pod. You can follow below command to run the pod.
kubectl run mypod --image=nginx
Here mypod is name of the pod and nginx image will be used.
Check if the pod is running.
Result below:
NAME READY STATUS RESTARTS AGE
mypod 0/1 ContainerCreating 0 5s
It says container creating state. We may wait and see if it is completed and running state.
NAME READY STATUS RESTARTS AGE
mypod 1/1 Running 0 21s
So it's in running state. We can also use yaml file to create the pod.
Let's break something and see what we issues and status we get. I'll delete the pod and recreate it with the wrong image name.
To delete the Pod use below command:
Now since the pod has been delete let's recreate it with wrong image.
kubectl run mypod --image=nginx-myimage-123
Run it and pod will be created successfully. But wait did we check the status if the pod is running.
Check it using Kubectl get pods command.
kubectl get pods
NAME READY STATUS RESTARTS AGE
mypod 0/1 ErrImagePull 0 9s
You can identify under the status column that there is an error. It says ErrImagePull. We can guess that there is an error during image pull. We know that because we put that wrong image name. But in real life scenario we don't know about if our image is wrong. So we can check the events.
To check the events we can use describe command:
kubectl describe pod mypod
Once we run this command it will give us result in key/value pair format. Just scroll to the bottom and look for the events.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 34s default-scheduler Successfully assigned default/mypod to docker-desktop
Normal BackOff 26s kubelet Back-off pulling image "nginx-myimage-123"
Warning Failed 26s kubelet Error: ImagePullBackOff
Normal Pulling 12s (x2 over 33s) kubelet Pulling image "nginx-myimage-123"
Warning Failed 6s (x2 over 27s) kubelet Failed to pull image "nginx-myimage-123": rpc error: code = Unknown desc = Error response from daemon: pull access denied for nginx-myimage-123, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
Warning Failed 6s (x2 over 27s) kubelet Error: ErrImagePull
Here we can see it says either repository does not exist or we don't have access to it.
So checking the events is very important step. This can tell us what happened when we ran our kubectl run command. There is one more way by which we can check and that is logs. By checking logs can give us some insights. Sometimes we don't get much information from the events and in those scenarios checking logs can be very helpful if we can find something. We can check the log in this case as well but since the issue is only with image. We used wrong image name and this issue was very much understandable from the events. But let's check the logs anyway by running below command.
Result:
Error from server (BadRequest): container "mypod" in pod "mypod" is waiting to start: trying and failing to pull image
In logs also we can check that its saying "trying and failing to pull image" step.
If we have specific container failing inside the pod then you can run below command.
kubectl logs mypod container_name
If our container has ever crashed previously then we can use --previous flag in command.
kubectl logs --previous mypod container_name
Conclusion
These are the basic ways by which we can check and fix the issues in Pod. Events can be very helpful but sometimes logs can be more helpful. So it depends on what is the issue. It's always better to check for events and then go for logs.
Hope this can be helpful!
Note: If you think this helped you and you want to learn more stuff on devops, then I would recommend joining the Kodecloud devops course and go for the complete certification path by clicking this link
