kubectl get pods shows broken 0/1 ImagePullBackOff. You run kubectl logs broken and get nothing back at all. What is your next move, and why was logs empty?

Run kubectl describe pod broken and read the Events, since no container started to print anything. The Warning lines name the reason, here a failed pull of nginx:doesnotexist because the registry says it is not found. Empty logs are exactly what you expect when the image never came down.

hello is 1/1 Running. You want to see what is actually sitting on the container's filesystem before you trust it. Which command gets you there?

kubectl exec -it hello -- sh, then run ls at the prompt. Exec runs a command inside the running container, and -it with sh hands you a prompt you can keep typing at. Type exit when you are done.

You started hello with kubectl run hello --image=nginx:1.27 --restart=Never and it has been Running on worker-1 for an hour. That node dies. Once the dust settles, what does kubectl get pods show?

No resources found. Nothing was watching that pod, so nothing rebuilds it. A pod you create directly has no controller behind it. Run it through a Deployment and a replacement turns up the moment one is lost.

Your first pod

Run something, then look at it.

Beginner10 min · lesson 5 of 24

In plain terms

kubectl run creates a pod; get / describe / logs tell you if it scheduled and started.

A pod is the smallest thing you can run on Kubernetes. This lesson is one cycle: start a pod, watch it come up, look inside, then delete it. Run, check, look, delete. That is most of the daily job, whether you have one web server or a thousand. The scale changes; the four moves do not.

Start one and watch it come up

A few words first. A container is your app plus what it needs to run. A pod is the wrapper Kubernetes puts around that container, and most pods hold exactly one. A cluster is the group of machines; each worker is a node. You talk to the cluster with kubectl (Kubernetes control): type kubectl, then what you want done. The quickest start is kubectl run. Hand it an image (the packaged app in a registry) and it asks the cluster to start one copy. Then kubectl get pods lists what is running. You are waiting for Running.

terminal: start it and check

$ kubectl run hello --image=nginx
pod/hello created
 
$ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
hello   1/1     Running   0          12s

READY 1/1 means you asked for one container and one is up. Seeing Pending instead? Pending means no container is running yet, and in the first few seconds that is usually because the cluster hasn't picked a machine for the pod. For the full story, run kubectl describe. It tells you which node the pod landed on, the image it's using, and at the bottom a list of events that reads like parcel tracking: scheduled, image pulled, container started. Read that list from the top down and you can follow exactly what happened, in the order it happened.

terminal: the full story

$ kubectl describe pod hello
Name:         hello
Namespace:    default
Node:         worker-1/10.0.0.5
Status:       Running
IP:           10.244.1.7
Containers:
  hello:
    Image:   nginx
    State:   Running
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  30s   default-scheduler  Successfully assigned default/hello to worker-1
  Normal  Pulling    29s   kubelet            Pulling image "nginx"
  Normal  Pulled     25s   kubelet            Successfully pulled image "nginx"
  Normal  Created    25s   kubelet            Created container: hello
  Normal  Started    24s   kubelet            Started container hello

The kubelet in that list is a small program on every node. It is what actually starts your containers. When something will not start, Events are the first place to look. They usually name the problem in plain English, so you can often fix it without opening anything else.

When it won't start, read the failure

Not every pod starts cleanly, and the fastest way to trust these tools is to break something on purpose. The most common first stumble is a wrong image name or tag. Point a pod at a tag nobody ever published, then see what kubectl get pods says about it.

terminal: a pod that can't start

$ kubectl run broken --image=nginx:doesnotexist
pod/broken created
 
$ kubectl get pods
NAME     READY   STATUS             RESTARTS   AGE
broken   0/1     ImagePullBackOff   0          40s
hello    1/1     Running            0          3m

READY 0/1 means none of your one container is up. ImagePullBackOff means it tried to download the image, failed, and is waiting longer between retries. kubectl logs will not help: no container started, so nothing printed. This is a describe job. Run it, then read Events at the bottom.

terminal: describe the broken pod

$ kubectl describe pod broken
Name:         broken
Namespace:    default
Node:         worker-1/10.0.0.5
Status:       Pending
Containers:
  broken:
    Image:   nginx:doesnotexist
    State:   Waiting
      Reason:   ImagePullBackOff
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  60s                 default-scheduler  Successfully assigned default/broken to worker-1
  Normal   Pulling    44s (x3 over 59s)   kubelet            Pulling image "nginx:doesnotexist"
  Warning  Failed     43s (x3 over 58s)   kubelet            Failed to pull image "nginx:doesnotexist": not found
  Warning  Failed     43s (x3 over 58s)   kubelet            Error: ErrImagePull
  Normal   BackOff    16s (x4 over 58s)   kubelet            Back-off pulling image "nginx:doesnotexist"
  Warning  Failed     16s (x4 over 58s)   kubelet            Error: ImagePullBackOff

The Warning lines tell the whole story. Notice that Status near the top still reads Pending even though the Scheduled event says this pod already landed on worker-1. Pending covers everything before a container runs, the image pull included, while the STATUS column in kubectl get pods reports the container's own reason instead, which is why that column said ImagePullBackOff. The kubelet asked the registry (the online store where container images are kept) for nginx:doesnotexist, was told there is no such image, and backed off. Nearly every pull failure is spelled out right there on the Image line: a typo in the name, or a tag that doesn't exist. Point it at a real tag like nginx:1.27 and the pod starts. Clean up the broken one with kubectl delete pod broken and you're back to a tidy slate. That's the pattern for most early failures. One more thing worth reading in that output: the (x3 over 59s) beside a reason is a retry count, so a number that keeps climbing means the node is still trying and still failing.

Look inside the running pod

Two commands show what the app is doing. kubectl logs prints what the container wrote, the same messages you would see on a laptop. Read that first when something misbehaves. kubectl exec runs a command inside the container. Add -it, put sh on the end, and you get an interactive shell inside the container. Type exit to leave.

terminal: read the logs, then step inside

$ kubectl logs hello
/docker-entrypoint.sh: Configuration complete; ready for start up
2026/07/16 10:22:31 [notice] 1#1: nginx/1.27.3
2026/07/16 10:22:31 [notice] 1#1: start worker processes
 
$ kubectl exec -it hello -- sh
# ls
bin  boot  dev  docker-entrypoint.sh  etc  home  lib
# exit
$

Finished poking around? Clear it away. kubectl delete pod removes the pod and gives the node back the room it was taking up. Build the habit of deleting your test pods the moment you're done with them, so the cluster stays tidy and you aren't holding on to things you've forgotten about.

terminal: clean up

$ kubectl delete pod hello
pod "hello" deleted
 
$ kubectl get pods
No resources found in default namespace.

The reproducible way: a file you can re-run

kubectl run is great for a quick test, but it vanishes the moment you forget what you typed. What people actually do is write the pod down in a file and apply that file. The file is YAML, a plain-text format built to be easy for a person to read and edit. Three parts sit at the top of every Kubernetes file: apiVersion (which set of rules to read it by), kind (what you're making, a Pod here), and metadata (its name and labels, the name tag on the box). Under those comes the part that describes the thing itself, and what it is called depends on the kind. A Pod uses spec (what actually goes inside), a ConfigMap uses data, a Role uses rules. Save the file in git and anyone on your team can recreate the exact same pod next month.

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: hello
  labels:
    app: hello
spec:
  containers:
    - name: hello
      image: nginx:1.27
      ports:
        - containerPort: 80

terminal: apply the file

$ kubectl apply -f pod.yaml
pod/hello created
 
$ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
hello   1/1     Running   0          9s

The basic working loop

Run it, look at it, inspect it, clear it away. The same rhythm covers one nginx pod and a thousand real ones. Bare pods are for learning. Real apps run through Deployments so something keeps them alive.

Your first pod is a trust exercise with two parts of the cluster: the scheduler, which decides where the pod goes, and the kubelet, which starts it once it lands. Four statuses cover nearly everything you'll meet early on. Pending means no container is running yet, whether the pod is still waiting for a node or already on one and pulling its image. ContainerCreating means the node is pulling or starting the image. CrashLoopBackOff means the process starts and keeps dying. ImagePullBackOff means the node can't fetch the image at all. Learn those four before you go near the exotic fields.

kubectl run is the fastest way to get a pod under your hands. A YAML file is the way to get the same pod twice. Switch to YAML as soon as you care about labels, probes (the small health checks Kubernetes runs against your container), or resource requests, and for anything you'll re-apply tomorrow.

An nginx pod with no Service in front of it cannot be reached from outside the cluster, but it is still a real process on a real node: it holds memory, it runs as whatever user the image picked, and anything else inside the cluster can reach it on its pod IP. That is enough to matter the moment you forget it is there. Treat even first pods as real workloads. Delete what you create, and never leave a debug image sitting there Running in a production namespace.

Try this

Start a Pod, watch the status flip to Running, force a bad image and read what describe tells you, then delete both cleanly. The --restart=Never below sets the pod's restart policy: if the container exits, Kubernetes leaves it stopped instead of starting it again. The earlier examples used the default, Always, which is what turns a container that keeps dying into CrashLoopBackOff.

terminal

$ kubectl run hello --image=nginx:1.27 --restart=Never
pod/hello created
 
$ kubectl get pods -w
NAME    READY   STATUS              RESTARTS   AGE
hello   0/1     ContainerCreating   0          1s
hello   1/1     Running             0          4s
# Ctrl+C
 
$ kubectl run broken --image=nginx:doesnotexist --restart=Never
pod/broken created
 
$ kubectl get pod broken
NAME     READY   STATUS             RESTARTS   AGE
broken   0/1     ImagePullBackOff   0          35s
 
$ kubectl describe pod broken | grep -A 6 'Events:'
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  35s                 default-scheduler  Successfully assigned default/broken to worker-1
  Normal   Pulling    20s (x3 over 34s)   kubelet            Pulling image "nginx:doesnotexist"
  Warning  Failed     19s (x3 over 33s)   kubelet            Failed to pull image "nginx:doesnotexist": not found
  Warning  Failed     19s (x3 over 33s)   kubelet            Error: ErrImagePull
 
$ kubectl delete pod hello broken
pod "hello" deleted
pod "broken" deleted

Takeaway

A pod walks from Pending to ContainerCreating to Running, or it stops at a status that names the trouble. When it stops, the Events at the bottom of kubectl describe pod tell you why. Reach for kubectl run when you're poking around, write a YAML file for anything you'll want again, and delete every lab pod you started before you shut the laptop.

A bare pod won't come back on its own

The pod you started here has nothing watching over it. If it crashes, or the node it runs on dies, it's gone and nothing brings it back. Fine for learning and quick tests. For anything you'd actually miss, you run pods through a Deployment, which you'll meet next. A Deployment keeps the right number of pods alive and starts a replacement the moment one fails.

Meet kubectlPods, a little deeper

Cluster architectureKubernetes administration Security domains & threat modelKubernetes security & hardening The cluster attack surfaceKubernetes attack & defense kubectl cheat sheetCheat sheet Kubernetes interview questionsInterview prep