Around Go: Kubernetes · 3 MIN READ

Debug Pods: get, describe, logs, events and top

Find the concrete reason behind Pending, CrashLoopBackOff or an unready container.

Read the workload state before changing it. A Deployment, a Pod and a container can each have a different status, so diagnose the layer that is failing. These commands refer to the earlier go-api Deployment in the explicit go-lab development namespace.

Find the Pod and read its events

get -o wide includes node and Pod addresses. describe exposes scheduling decisions, container state and recent events. Copy the exact Pod name from get rather than inventing an identifier; the placeholder below must be replaced.

bash

kubectl --context dev-cluster -n go-lab get pods -l app=go-api -o wide
pod_name=REPLACE_WITH_ACTUAL_POD
kubectl --context dev-cluster -n go-lab describe pod "$pod_name"
kubectl --context dev-cluster -n go-lab get events --sort-by=.metadata.creationTimestamp

Read the code

Pending often needs scheduling/volume evidence; ImagePullBackOff needs the image or registry failure. CrashLoopBackOff describes retry backoff after container failure, not a root cause. Check the reported reason and exit code first.

Read the right container and the previous attempt

logs reads application stdout/stderr. -c selects the container name api from the earlier manifest. --previous requests the last terminated instance when one exists, which is valuable when the current container restarted before you could follow it.

bash

kubectl --context dev-cluster -n go-lab logs "$pod_name" -c api --tail=100
kubectl --context dev-cluster -n go-lab logs "$pod_name" -c api --previous --tail=100
kubectl --context dev-cluster -n go-lab logs "$pod_name" -c api -f --since=5m

Read the code

No previous container is a valid reason for --previous to fail. Ctrl-C only stops following logs. Redact sensitive application data before sharing output and correlate timestamps with restarts and rollout events.

Inspect resources and choose an available debug path

top requires the cluster metrics API, commonly provided by Metrics Server. exec starts a command that already exists in the image; the earlier scratch Go image has no shell. For richer diagnosis, use an approved ephemeral debug image and the required cluster permissions.

bash

kubectl --context dev-cluster -n go-lab top pods -l app=go-api
kubectl --context dev-cluster top nodes
# Only for an image that actually contains /bin/sh:
kubectl --context dev-cluster -n go-lab exec -it "$pod_name" -c api -- /bin/sh

Read the code

A missing metrics API does not mean resource usage is zero. The exec line will fail for scratch images by design; use logs, profiles or a deliberate debug-container workflow instead of assuming every production image includes utilities.

TAKE THIS WITH YOU

Read exact state, events, container logs and resource evidence before restarting. Previous logs can explain a crash loop; missing metrics or a missing shell is a tooling boundary, not an application diagnosis.

Check your understanding

Which logs can --previous retrieve for a restarted container?

Go to the source

Progress stays in this browser. No account needed.