How to Check Kubernetes Container Status

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.


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/1 means one container expected, one running).
  • STATUS → The overall pod phase (e.g., Running, Pending, Succeeded, Failed, or CrashLoopBackOff).
  • 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 be Running, Waiting, or Terminated.
  • Under Events, look for errors like Failed, Back-off, or ImagePullBackOff. 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:

StatusMeaningCommon Cause
RunningContainer is up and healthyEverything is fine
PendingContainer hasn’t started yetImage is pulling, or node scheduling delayed
CrashLoopBackOffContainer repeatedly crashesApplication crash, misconfiguration
ImagePullBackOffImage can’t be pulledWrong image name or missing registry credentials
TerminatingPod is being shut downManual deletion or deployment update
CompletedJob or init container finished successfullyNormal 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

CommandPurpose
kubectl get podsView pod summary and basic status
kubectl describe pod <pod>Inspect container details and events
kubectl logs <pod>View container logs
kubectl get pods -wWatch pod status in real time
kubectl get pods --all-namespacesList 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.

David Cao
David Cao

David is a Cloud & DevOps Enthusiast. He has years of experience as a Linux engineer. He had working experience in AMD, EMC. He likes Linux, Python, bash, and more. He is a technical blogger and a Software Engineer. He enjoys sharing his learning and contributing to open-source.

Articles: 546

Leave a Reply

Your email address will not be published. Required fields are marked *