Viewing Resources

You have Pods running in the simulator. You want to know their current status, which node they landed on, how long they have been up, and what happened since they were created. Two commands cover almost everything you need: kubectl get for the broad view, and kubectl describe for the detailed view. Knowing when to use each one will save you a lot of time when debugging.

Start by creating a Pod you can observe throughout this lesson:

nano demo-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  labels:
    app: demo
spec:
  containers:
    - name: web
      image: nginx:1.28

kubectl apply -f demo-pod.yaml

kubectl get: the wide-angle lens

kubectl get lists resources in a tabular format. It is your first stop for any question that starts with “what is the current state of…”.

kubectl get pods

The output shows each Pod’s name, the number of ready containers over total containers, the status, the restart count, and the age. This fits on one line per Pod, which makes it easy to scan dozens of resources at once.

Add -o wide to get the node name and the Pod IP address:

kubectl get pods -o wide

If you want to watch resources update in real time without re-running the command, use --watch. Kubernetes streams changes as they happen. Press Ctrl+C to stop.

kubectl get pods --watch

You already know about labels from the previous module. You can filter the list by label to focus on a subset:

kubectl get pods -l app=demo

Try listing more than just Pods. kubectl get all shows Pods, Services, Deployments, and ReplicaSets in one pass:

kubectl get all

kubectl describe: the magnifying glass

kubectl get tells you something is wrong. kubectl describe tells you why.

kubectl describe pod returns a full breakdown of the object: its labels and annotations, the node it was scheduled on, the container specs, the current conditions, and most importantly, the Events section at the bottom.

kubectl describe pod demo-pod

Spend a moment reading the output. The Events section is a chronological timeline of everything that happened to this Pod: when the scheduler assigned it to a node, when the kubelet pulled the image, when the container was created and started. If anything went wrong during startup, that failure appears here, often before the STATUS column in kubectl get even reflects the problem.

Choosing between get and describe

The two commands complement each other. Use kubectl get when you want a snapshot of many resources at once and need to find which one needs attention. Once you have identified the problematic resource, switch to kubectl describe to dig into its full history and conditions.

A typical debugging session starts with kubectl get pods to find a Pod in an unexpected state, then kubectl describe pod <name> to read the Events and understand what Kubernetes tried to do and where it stopped.

Clean up before the next lesson:

kubectl delete pod demo-pod

Now that you can observe the state of your resources, the next step is to look inside them. The next lesson covers kubectl logs and kubectl exec, the two tools for reading what is actually happening inside a running container.