When something goes wrong in your Kubernetes cluster — a pod isn’t responding, or a service is acting strangely — the first step to troubleshooting is to check the container status. Kubernetes provides several built-in tools and commands to help you inspect what’s happening under the hood.
In this guide, you’ll learn how to check container status in Kubernetes, what different statuses mean, and how to interpret them when diagnosing issues.
Table of Contents
1. Understanding How Kubernetes Runs Containers
Before diving into commands, let’s clarify what’s happening behind the scenes.
When you deploy a pod, Kubernetes schedules it on a node, and a container runtime (like containerd or CRI-O) actually runs the containers. Kubernetes continuously monitors these containers and reports their current state.
The status you see in kubectl output reflects real-time information gathered by the kubelet and reported back to the API server.
2. Checking Pod and Container Status with kubectl get pods
The most common command to check container status is:
kubectl get pods
This lists all pods in the current namespace, showing their status, ready containers, and age:
NAME READY STATUS RESTARTS AGE
web-app-7b9b4f568d-2dkr4 1/1 Running 0 10m
api-server-5b88c5c5b5-mgk7d 1/1 CrashLoopBackOff 5 2m
Let’s break it down:
- READY → Number of containers that are up and responding (e.g.,
1/1means one container expected, one running). - STATUS → The overall pod phase (e.g.,
Running,Pending,Succeeded,Failed, orCrashLoopBackOff). - RESTARTS → Number of times containers have restarted due to failure.
- AGE → How long the pod has been running.
If you see something like CrashLoopBackOff or ImagePullBackOff, that means the container failed to start properly — we’ll cover what to do next below.
3. Inspecting Pod Details with kubectl describe pod
To get more detailed information, including why a container is failing or stuck, use:
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
kubectl describe pod <pod-name>
Example:
kubectl describe pod web-app-7b9b4f568d-2dkr4
You’ll see an output like this (trimmed for clarity):
Containers:
web-container:
Container ID: containerd://a1b2c3d4e5
Image: nginx:latest
State: Running
Started: Sat, 11 Oct 2025 14:15:00 +0900
Ready: True
Restart Count: 0
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulled 10m kubelet, node1 Container image pulled
Normal Created 10m kubelet, node1 Created container web-container
Normal Started 10m kubelet, node1 Started container web-container
👉 What to look for:
- Under Containers, check the
State— it might beRunning,Waiting, orTerminated. - Under Events, look for errors like
Failed,Back-off, orImagePullBackOff. These messages tell you exactly what went wrong.
4. Viewing Container Logs
Sometimes, the pod looks fine from the outside, but the application inside is failing.
To check logs from a specific container:
kubectl logs <pod-name>
If your pod has multiple containers, specify which one:
kubectl logs <pod-name> -c <container-name>
For example:
kubectl logs web-app-7b9b4f568d-2dkr4 -c web-container
Use --previous if the container has crashed and restarted — this shows logs from the previous instance:
kubectl logs <pod-name> --previous
5. Watching Pod Status in Real Time
You can continuously monitor the status of your pods using the -w (watch) flag:
kubectl get pods -w
This live-updates the output whenever something changes, which is helpful when debugging restarts or deployment rollouts.
6. Checking Pod Status Across All Namespaces
By default, kubectl commands only show the current namespace.
To see all pods across all namespaces, run:
kubectl get pods --all-namespaces
This gives you a cluster-wide view, which is particularly useful when debugging system pods like CoreDNS or metrics-server.
7. Common Container States (and What They Mean)
Here are some container states you’ll encounter:
| Status | Meaning | Common Cause |
|---|---|---|
| Running | Container is up and healthy | Everything is fine |
| Pending | Container hasn’t started yet | Image is pulling, or node scheduling delayed |
| CrashLoopBackOff | Container repeatedly crashes | Application crash, misconfiguration |
| ImagePullBackOff | Image can’t be pulled | Wrong image name or missing registry credentials |
| Terminating | Pod is being shut down | Manual deletion or deployment update |
| Completed | Job or init container finished successfully | Normal for batch jobs |
8. Bonus: Using kubectl get pod -o wide
For more context, including which node a pod runs on and its IP:
kubectl get pod -o wide
Example output:
NAME READY STATUS NODE IP AGE
web-app-7b9b4f568d-2dkr4 1/1 Running node1 10.244.1.5 12m
This is handy for cross-checking if the node itself might be the problem.
9. Summary
| Command | Purpose |
|---|---|
kubectl get pods | View pod summary and basic status |
kubectl describe pod <pod> | Inspect container details and events |
kubectl logs <pod> | View container logs |
kubectl get pods -w | Watch pod status in real time |
kubectl get pods --all-namespaces | List pods across namespaces |
10. Final Thoughts
When troubleshooting Kubernetes workloads, container status is your first clue.
Using a combination of kubectl get, describe, and logs, you can quickly understand whether the problem lies in the container image, the application, or the node itself.
Once you master these commands, debugging Kubernetes becomes far less intimidating — it’s just a matter of knowing where to look.




