Around Go · 6 MIN READ
Debug a Kubernetes workload in a useful order
Context, rollout, events, logs and probes: a small diagnostic sequence with a reason for each command.
First verify where you are
Before changing a workload, inspect the current context and namespace. A correct command against the wrong cluster is still an operational mistake. Prefer explicit namespace flags while investigating. These examples run in your own development environment; the iOS project console is not a Kubernetes shell.
kubectl config current-context
kubectl config get-contexts
kubectl get namespaces
kubectl -n demo get deployments,pods,servicesInspect desired state and rollout
A Deployment can exist while its newest ReplicaSet cannot become available. Read the rollout status and the workload description. Look for unavailable replicas, scheduling constraints, image pull failures and failed health checks. Avoid repeatedly deleting Pods without understanding which controller will recreate them and why.
kubectl -n demo rollout status deployment/api --timeout=60s
kubectl -n demo describe deployment api
kubectl -n demo get events --sort-by=.metadata.creationTimestampRead the right process logs
Choose a particular Pod and container. If it is restarting, the previous container’s logs may explain what happened before the restart. A bounded time range and tail keep the investigation manageable. Treat logs as potentially sensitive: tokens, credentials and personal payloads should not be printed or pasted into a public issue.
kubectl -n demo get pods -l app=api
# Replace POD_NAME with a Pod from the command above.
kubectl -n demo logs POD_NAME -c api --since=10m --tail=200
kubectl -n demo logs POD_NAME -c api --previous --tail=200Distinguish readiness from liveness
Readiness determines whether traffic should be sent to a Pod. Liveness can trigger a restart. A slow or unavailable dependency should not automatically make every process restart in a loop. Use a startup probe when initialization legitimately takes time.
Check resource requests, limits and termination events before assuming every failure is an application bug. Metrics such as kubectl top require the cluster’s metrics service; absence of those metrics is not evidence that resource usage is zero.
Make the smallest reviewed change
Inspect a manifest with client dry-run and diff before applying it to the intended namespace. Review rollout behavior and keep an undo plan. Scale, rollback and delete are mutations; do not run them just to see whether the command works.
The course’s Kubernetes unit expands these steps into workload manifests, Services, configuration, Secrets, probes and rollout. Reading a command is not proof it has been exercised against your cluster, so verify names, versions and permissions in your own environment.