Skip to main content

kubectl Cheatsheet: Essential Kubernetes Commands for Managing Pods, Deployments, and Services

A practical kubectl cheatsheet for developers who manage pods, deployments, and services every day — with real command output, rollout patterns, and time-saving flags.

Published By Li Lei
#kubectl #kubernetes #devops #cheatsheet #pods #deployments #services

kubectl Cheatsheet: Essential Kubernetes Commands for Developers Managing Pods, Deployments, and Services

Most Kubernetes tutorials start with theory — control planes, etcd, scheduler internals. By the time they get to actual commands, you've forgotten what you needed to type. This guide skips the preamble and focuses on the kubectl commands you run repeatedly when shipping and maintaining real applications: deploying workloads, exposing them via services, scaling, rolling out updates, and diagnosing what went wrong.

According to the CNCF 2023 Annual Survey, 66% of respondents run Kubernetes in production — and for most of them, kubectl is the daily interface to that cluster. Knowing the right flags makes the difference between a 30-second fix and a 20-minute fumble.

Keep the kubectl cheat sheet open in a second tab as you read — it has search, copy buttons, and inline pitfall notes for every command below.

The deploy → expose → verify loop

The first thing most developers need to do is get an image running and reachable.

# Deploy from a manifest
kubectl apply -f deployment.yaml

# Or create an inline deployment
kubectl create deployment api-gateway \
  --image=myregistry/api-gateway:v1.4.2 \
  --replicas=3 \
  -n production

# Expose it as a ClusterIP service
kubectl expose deployment api-gateway \
  --port=80 \
  --target-port=8080 \
  -n production

# Verify the service endpoint exists
kubectl get svc api-gateway -n production
kubectl get endpoints api-gateway -n production

I learned this the hard way early on: I ran kubectl apply -f deployment.yaml, watched all three pods reach Running state, and assumed the service was live — only to realize I'd never applied the Service manifest. Nothing could reach my pods. Now I always run kubectl get endpoints after exposing a deployment. If the Endpoints line reads <none>, the selector labels in your Service don't match the labels on your pods, and traffic will never arrive.

Once the service is running, port-forward is the fastest way to reach it without exposing it externally:

kubectl port-forward svc/api-gateway 8080:80 -n production
# Now curl localhost:8080 hits the pod directly

This works even if the service type is ClusterIP. No LoadBalancer or NodePort needed.

Scaling and updating without downtime

The single most common operation after initial deployment is changing the replica count or pushing a new image version.

# Scale up immediately
kubectl scale deployment api-gateway --replicas=6 -n production

# Update the container image (triggers a rolling update)
kubectl set image deployment/api-gateway \
  api-gateway=myregistry/api-gateway:v1.5.0 \
  -n production

# Watch the rollout happen in real time
kubectl rollout status deployment/api-gateway -n production

A real kubectl rollout status output looks like this:

Waiting for deployment "api-gateway" rollout to finish: 1 out of 6 new replicas have been updated...
Waiting for deployment "api-gateway" rollout to finish: 2 out of 6 new replicas have been updated...
Waiting for deployment "api-gateway" rollout to finish: 3 out of 6 new replicas have been updated...
Waiting for deployment "api-gateway" rollout to finish: 3 old replicas are pending termination...
deployment "api-gateway" successfully rolled out

Kubernetes defaults to a rolling update strategy with maxSurge=1 and maxUnavailable=0 — meaning at least the current replica count is always running during the update. If your pods take 30 seconds to pass a readiness probe, expect the rollout to take at least 30s × replicas in total.

Rolling back when something breaks

kubectl rollout undo is the command you want to know before you need it.

# Roll back to the previous version
kubectl rollout undo deployment/api-gateway -n production

# Or roll back to a specific revision
kubectl rollout history deployment/api-gateway -n production
# REVISION  CHANGE-CAUSE
# 1         kubectl create deployment api-gateway ...
# 2         kubectl set image api-gateway=v1.4.2
# 3         kubectl set image api-gateway=v1.5.0

kubectl rollout undo deployment/api-gateway --to-revision=2 -n production

One gotcha: CHANGE-CAUSE is empty unless you annotate your deployments with kubernetes.io/change-cause. Without that annotation you're guessing which revision is which from timestamps alone. Add this to your deploy script:

kubectl annotate deployment/api-gateway \
  kubernetes.io/change-cause="release v1.5.0 (PR #823)" \
  -n production

Inspecting pods and diagnosing common problems

Once pods are running (or failing to), these four commands cover the majority of diagnosis:

# Show pod status with node placement
kubectl get pods -n production -o wide

# Full event log for a pod — read the Events block at the bottom
kubectl describe pod api-gateway-7d9f-abc -n production

# Follow logs across all pods in a deployment
kubectl logs -f deploy/api-gateway -n production

# Open a shell inside a running pod
kubectl exec -it api-gateway-7d9f-abc -n production -- sh

The Events block in kubectl describe is where Kubernetes writes the actual failure reason in plain language — ImagePullBackOff with the 403 from your registry, Insufficient memory with the node it tried to schedule on, Readiness probe failed: HTTP probe failed with statuscode: 500. Reading it takes five seconds and saves five minutes.

If a pod is stuck in CrashLoopBackOff, add --previous to logs to read the output from the container before it crashed:

kubectl logs api-gateway-7d9f-abc --previous -n production

Five kubectl flags that save 10 minutes a day

-o wide — adds columns for node name and pod IP. Essential the moment you suspect a node-level problem.

--all-namespaces (or -A) — scans every namespace at once. Useful when you're not sure which namespace a workload landed in: kubectl get pods -A | grep api-gateway.

--watch (or -w) — streams updates instead of requiring repeated get calls: kubectl get pods -w -n production.

--dry-run=client -o yaml — generates a manifest from an imperative command without creating anything:

kubectl create deployment test --image=nginx --dry-run=client -o yaml > deployment.yaml

This is the fastest way to generate a skeleton YAML for an unfamiliar resource.

--field-selector — filters by field value, not label: kubectl get pods --field-selector=status.phase=Failed -A lists every failed pod across the cluster in one command.

If you work with Docker images before they reach the cluster, the Docker cheat sheet covers the build, tag, and push workflow that feeds into kubectl set image and kubectl create deployment.

Made by Toolora · Updated 2026-06-22