You created a Pod. Now learn to read one, because most of Kubernetes troubleshooting is reading before touching.
The four phases
Every Pod carries a status.phase:
| Phase | Meaning |
|---|---|
Pending | Accepted, but not all containers are running yet. Still scheduling, or still pulling an image. |
Running | Bound to a node, at least one container is up. |
Succeeded | All containers exited with code 0 and will not restart. |
Failed | All containers stopped, at least one with a non-zero code. |
kubectl get pods shows a STATUS column that is more specific than the phase. ContainerCreating, ImagePullBackOff and CrashLoopBackOff are not phases; they are reasons, and they are the ones you will chase.
kubectl get podsWatch RESTARTS too. A Pod that is Running with 14 restarts is a Pod that keeps dying.
describe: the story so far
kubectl describe pod podling
describe prints the Pod's node, IP, each container's image and state, and at the bottom, Events: a timeline of scheduling, pulling, starting and failing. When something is wrong, Events usually say exactly what, in plain English.
logs: what the container said
kubectl logs podlinglogs shows the container's stdout and stderr. If a container has restarted, --previous shows the output of the one that died, which is often the only clue that survives a crash.
The -o yaml tour
Every object is stored as structured data. Ask for it raw:
kubectl get pod podling -o yamlThree sections matter:
metadata: name, namespace, labels — who it is
spec: containers, image, restartPolicy — what you asked for
status: phase, podIP, containerStatuses — what actually happenedspec is yours; status is written by Kubernetes. Comparing the two is the whole job.
explain: the docs are in the cluster
Forget what a field means? Ask the API itself:
kubectl explain pod.spec.containersexplain walks the schema of any object, path by path, with the official description inline. It works offline and it is faster than a search engine.