Most kubectl cheat sheets are alphabetical dumps you will never read twice. This one is grouped by what you are actually trying to do — look at something, change something, debug something, or generate a manifest. Every command here comes from the official kubectl reference. Set an alias to k and learn the resource shortnames first; they save more keystrokes than anything else.
How do you switch kubectl context and namespace?
Use kubectl config to change which cluster you talk to, and set-context --current --namespace to change the default namespace so you stop typing -n on every command. Check where you are pointed before you run anything destructive.
kubectl config get-contexts # list configured clusters
kubectl config current-context # which cluster am I on
kubectl config use-context my-cluster # switch clusters
kubectl config set-context --current --namespace=payments # set default namespace
kubectl config view --minify | grep namespace # show current namespaceIf you switch contexts often, the kubectx and kubens tools wrap these exact commands with tab completion. The kubectx and kubens guide covers the setup.
Verdict: set the namespace on your context on day one. Every accidental delete in the wrong namespace traces back to skipping this.
What are the kubectl resource shortnames?
kubectl accepts abbreviations for most resource types, so kubectl get po works the same as kubectl get pods. Run kubectl api-resources to see every shortname your cluster supports, including ones added by CRDs.
| Shortname | Resource |
|---|---|
| po | Pods |
| deploy | Deployments |
| rs | ReplicaSets |
| svc | Services |
| ns | Namespaces |
| cm | ConfigMaps |
| ing | Ingresses |
| sts | StatefulSets |
| ds | DaemonSets |
| pvc | PersistentVolumeClaims |
| pv | PersistentVolumes |
| sa | ServiceAccounts |
| cj | CronJobs |
| no | Nodes |
kubectl api-resources # every resource type + shortname + API group
kubectl api-resources --namespaced=true
kubectl api-versions # every API version the cluster servesHow do you inspect resources with kubectl?
get lists resources, describe shows the full state including recent events, and the -o flag controls the output format. -o wide adds columns like node and pod IP; -o yaml gives you the complete object; -o jsonpath and -o custom-columns pull specific fields.
kubectl get pods -o wide # add node, IP, readiness
kubectl get pods -A # all namespaces (--all-namespaces)
kubectl get pod my-pod -o yaml # full object as YAML
kubectl describe pod my-pod # state + events for one pod
kubectl get svc --sort-by=.metadata.name # sort output
# pull specific fields
kubectl get pods -o jsonpath='{.items[*].metadata.name}'
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
kubectl get pods -o custom-columns=NAME:.metadata.name,STATUS:.status.phasejsonpath is worth learning for automation — it is the difference between parsing YAML with grep and asking for exactly the value you want.
How do you apply and delete resources with kubectl?
apply -f creates or updates resources from a file, a directory, or a URL, and it is the command you should use for anything you keep in version control. delete removes resources.
⚠ Note: kubectl delete pods --all deletes every pod in the current namespace, and --all-namespaces extends that to the whole cluster. Confirm your namespace first.
kubectl apply -f deployment.yaml
kubectl apply -f ./manifests/ # every file in the directory
kubectl apply -f https://example.com/app.yaml
kubectl diff -f deployment.yaml # preview what apply would change
kubectl delete -f deployment.yaml # delete what the file defines
kubectl delete pod my-pod
kubectl edit deployment my-deployment # open the live object in $EDITORHow do you read logs and exec into pods?
logs prints a container’s stdout. Add -f to follow, --previous to see the last crashed instance, and -l to aggregate across a label. exec runs a command inside a running container.
kubectl logs my-pod
kubectl logs my-pod -f # stream
kubectl logs my-pod --previous # logs from the container that crashed
kubectl logs my-pod -c sidecar # a specific container
kubectl logs -l app=nginx --all-containers=true # every pod with that label
kubectl exec my-pod -- ls /app # one command
kubectl exec my-pod -it -- /bin/sh # interactive shell
kubectl port-forward svc/my-service 8080:80 # tunnel a local port to the service--previous is the first thing to reach for on a CrashLoopBackOff — the current container has no logs yet, but the one that just died does.
How do you roll out and scale a deployment?
rollout manages updates to a Deployment: check status, view history, roll back, or force a restart. scale changes the replica count directly.
kubectl rollout status deployment/my-app # wait for the update to finish
kubectl rollout history deployment/my-app # list revisions
kubectl rollout undo deployment/my-app # roll back one revision
kubectl rollout restart deployment/my-app # recreate every pod (config/secret reload)
kubectl scale deployment my-app --replicas=5
kubectl autoscale deployment my-app --min=2 --max=10 --cpu-percent=80rollout restart is the clean way to pick up a changed ConfigMap or Secret without editing the Deployment. The deployment strategies guide covers wiring this into CI.
How do you generate a manifest with kubectl?
Add --dry-run=client -o yaml to create or run and kubectl prints the object instead of sending it to the cluster. It is the fastest way to get a valid starting manifest. kubectl explain documents any field.
kubectl create deployment web --image=nginx --dry-run=client -o yaml > web.yaml
kubectl run tmp --image=busybox --dry-run=client -o yaml -- sleep 3600
kubectl create configmap app-config --from-literal=LOG_LEVEL=debug --dry-run=client -o yaml
kubectl explain pod.spec.containers # field docs, no browser needed
kubectl explain deployment.spec.strategy --recursiveWhat are the most useful kubectl debugging one-liners?
When something is wrong, these four cover most of it: sorted events, resource usage, filtered pod lists, and node readiness.
kubectl get events --sort-by=.lastTimestamp # newest cluster events last
kubectl top pod # CPU/memory per pod
kubectl top node
kubectl get pods --field-selector=status.phase!=Running # anything not healthy
kubectl get pods -o wide --field-selector=spec.nodeName=node-3
kubectl get node --selector='!node-role.kubernetes.io/control-plane' # worker nodesPair these with the network policies guide when the symptom is “the pod is running but nothing can reach it,” and the Kubernetes guide for the bigger picture.
Frequently Asked Questions
create makes a resource once and fails if it already exists. apply creates it if missing and updates it if present, tracking the change so future applies only send the diff. Use apply for anything in version control.
Run kubectl logs my-pod –previous. The current container has restarted and has no logs yet, but the flag shows output from the instance that just died, which is where the error is.
Add –dry-run=client -o yaml to kubectl create or kubectl run. kubectl prints a valid manifest to stdout instead of creating anything, so you can redirect it to a file and edit from there.
It recreates every pod in a Deployment, ReplicaSet, StatefulSet, or DaemonSet without changing the spec. It is the standard way to make pods pick up a new ConfigMap or Secret value.
Quick Summary
- Set the namespace on your context with kubectl config set-context –current –namespace so you stop typing -n.
- Learn the shortnames (po, deploy, svc, ns, cm) and run kubectl api-resources to see the rest.
- -o wide, -o yaml, -o jsonpath, and -o custom-columns cover almost every output need.
- kubectl logs –previous is the CrashLoopBackOff command; kubectl rollout restart reloads config.
- –dry-run=client -o yaml generates a valid manifest without touching the cluster.
Keep this open in a tab while you work through the Kubernetes guide — the commands stick faster when you run them against a real cluster.