Kubernetes Command Cheat Sheet

A good Kubernetes command cheatsheet is less about memorising kubectl verbs and more about understanding the operator loop: confirm the target cluster, inspect actual state, compare it with desired state, change something carefully, and verify what the controllers did next.

Start with context hygiene

Before touching workloads, make sure you are in the right cluster and namespace. kubectl config get-contexts, kubectl config current-context, and kubectl config use-context prevent accidental changes in the wrong environment. kubectl cluster-info confirms basic control plane reachability.

This sounds trivial, but many production mistakes start here.

Inventory resources first

kubectl get pods,deploy,svc -A gives a fast view of workloads and services across namespaces. Use narrower queries once you know where to look. kubectl get events can also reveal scheduling failures, image pull problems, or restart loops quickly.

The goal at this stage is not to guess. It is to establish what the cluster believes exists.

Describe before you exec

kubectl describe pod <name> is often more useful than jumping straight into a shell. It shows scheduling decisions, image configuration, probe failures, mounts, environment variables, and recent events. If the issue is declarative or infrastructural, describe exposes it faster than interactive debugging.

Logs reveal the application path

kubectl logs <pod> and kubectl logs -f <pod> are the fastest route from symptom to evidence. For multi-container pods, specify the container name explicitly. If a pod keeps restarting, logs from the previous container instance can be critical.

Exec is for last-mile inspection

kubectl exec -it <pod> -- sh is useful when you need to inspect runtime files, DNS resolution, or process state inside a container. Treat it as diagnosis, not configuration management. If the fix depends on manual shell changes, the deployment model is already off course.

Apply and rollout commands manage desired state

kubectl apply -f <file> updates resource definitions declaratively. kubectl rollout status deployment/<name> tells you whether the controller is converging successfully. kubectl rollout undo deployment/<name> is the fast escape hatch for a bad rollout.

Scale and patch with intent

kubectl scale deployment/<name> --replicas=<n> changes capacity, but scaling does not fix CPU starvation, broken probes, or database bottlenecks by itself. kubectl edit and ad hoc patches can be helpful in emergencies, but they should be reconciled back into source-controlled manifests quickly.

The mindset that matters

Kubernetes is a reconciliation system. kubectl is your lens into that control loop. The most useful commands are the ones that tell you whether the cluster is missing resources, failing to schedule them, restarting them, or rejecting traffic to them.

Memorising commands helps. Understanding what controller state they expose is what makes you effective.