Kubernetes Cheat Sheet

The kubectl commands developers actually use daily — pods, deployments, services, debugging, and rollouts — with real examples, common mistakes, and a searchable quick reference.

runs locally on your browser. Your data never leaves your device.
13 sections
46 commands
Searchable quick reference
100% offline

Core Concepts & kubectl

Before anything else makes sense: which cluster, which namespace, and how to check both — every command below runs against whatever kubectl is currently pointed at.

kubectl cluster-info
Essential

Shows the control plane's address and the core services running on the cluster — a quick sanity check that kubectl is actually talking to the right place.

kubectl get nodes
Essential

Lists every machine — physical or virtual — in the cluster that can run workloads, along with its status.

kubectl config current-context
Essential

Shows which cluster kubectl is currently pointed at. Kubernetes lets you juggle multiple clusters from one machine, and running a command against the wrong one is a classic, costly mistake.

kubectl config use-context my-cluster
Handy

Switches kubectl to a different cluster or context.

kubectl get namespaces
Handy

Lists every namespace in the cluster — Kubernetes' way of dividing one cluster into isolated groups of resources.

kubectl get all -n my-namespace
Handy

Lists most resource types — pods, services, deployments — in a given namespace, in one shot.

Check your context before anything destructive
kubectl runs a command against whatever cluster it's currently pointed at — production included — with no extra confirmation prompt. Get in the habit of running kubectl config current-context before anything you can't easily undo.
Note
Resources with no explicit namespace go into "default." Add -n my-namespace to look in a specific one, or -A (short for --all-namespaces) to look across every namespace at once.

Pods & Deployments

What actually runs your code, and the layer of management sitting on top of it.

kubectl get pods
Essential

Lists pods — the smallest deployable unit in Kubernetes, one or more containers sharing storage and network — in the current namespace.

kubectl describe pod my-pod
Essential

Shows a pod's full details: events, container statuses, resource requests. The first command to reach for when a pod won't start.

kubectl get deployments
Essential

Lists Deployments — the higher-level object that manages a set of identical pods and keeps the requested number of them running.

kubectl create deployment my-app --image=nginx
Handy

Quickly creates a Deployment from a container image, without writing a YAML file first.

kubectl delete pod my-pod
Handy

Deletes a pod. If it's managed by a Deployment, a replacement is created automatically, almost immediately.

kubectl get replicasets
Advanced

Lists ReplicaSets — the object a Deployment creates and manages underneath to actually keep the right number of pod replicas running.

Pod, ReplicaSet, Deployment — in one line each
A Pod runs your containers. A ReplicaSet keeps a specified number of identical Pods running. A Deployment manages ReplicaSets for you, handling rollouts and rollbacks. You almost always create a Deployment directly and let it manage the rest.
Tip
Deleting a pod managed by a Deployment isn't as destructive as it sounds — the Deployment notices immediately and replaces it. That's actually a common, safe way to force a specific pod to restart.

Creating & Applying Resources

The declarative model at the center of Kubernetes: describe the end state in YAML, and let the cluster figure out how to get there.

kubectl apply -f deployment.yaml
Essential

Creates or updates resources defined in a YAML file to match exactly what's described — the standard, declarative way to manage anything in Kubernetes.

apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 template: spec: containers: - name: app image: my-app:v1

kubectl apply -f ./manifests/
Handy

Applies every YAML file in a directory in one command.

kubectl create -f deployment.yaml
Advanced

Creates resources from a file, but fails outright if they already exist. apply is almost always what you want instead, since it's safe to run repeatedly.

kubectl delete -f deployment.yaml
Handy

Deletes every resource defined in a file — the exact inverse of apply -f.

kubectl diff -f deployment.yaml
Advanced

Shows what would change if you applied a file, without actually applying it — a dry run for a YAML edit.

kubectl get pod my-pod -o yaml
Handy

Dumps a resource's full definition as YAML, including fields Kubernetes filled in automatically — useful for seeing exactly what a resource actually looks like right now.

apply vs. create
apply is declarative — describe the end state, and Kubernetes figures out the diff — and safe to rerun any time. create is imperative and fails on a resource that already exists. Default to apply.
Pro trick
Run kubectl diff -f before kubectl apply -f on anything you're not fully sure about — it's the closest thing kubectl has to a dry run for a change you're about to make live.

Services & Networking

Pods come and go, and get new IP addresses every time — Services are the stable thing everything else actually talks to.

kubectl get services
Essential

Lists Services — the stable network identity that sits in front of a changing set of pods.

kubectl expose deployment my-app --port=80 --type=ClusterIP
Essential

Creates a Service in front of an existing Deployment, giving its pods a stable internal address.

kubectl expose deployment my-app --port=80 --type=LoadBalancer
Handy

Same idea, but provisions an external load balancer (on a cloud provider that supports it) so the service is reachable from outside the cluster.

kubectl port-forward pod/my-pod 8080:80
Essential

Tunnels a local port straight to a port inside a specific pod — the fastest way to poke at something running in the cluster from your own machine, entirely bypassing Services.

kubectl get endpoints my-service
Advanced

Shows exactly which pod IPs a Service is currently routing traffic to — the thing to check when a Service exists but nothing seems to reach the pods behind it.

ClusterIP, NodePort, LoadBalancer — in one line each
ClusterIP (the default) is only reachable from inside the cluster. NodePort opens the same port on every node's own IP. LoadBalancer provisions an external cloud load balancer in front of the service, when your cluster's provider supports it.
Tip
kubectl port-forward is the fastest way to check whether a specific pod's app is actually working, completely bypassing Services and networking configuration that might be the real problem.

ConfigMaps & Secrets

Configuration kept separate from the application image itself, so the same image can run in different environments unchanged.

kubectl create configmap app-config --from-literal=LOG_LEVEL=debug
Essential

Creates a ConfigMap — a set of non-sensitive key/value configuration data pods can reference, kept separate from the image.

kubectl create secret generic db-creds --from-literal=password=hunter2
Essential

Creates a Secret — the same idea as a ConfigMap, but intended for sensitive values.

kubectl get configmaps kubectl get secrets
Handy

Lists ConfigMaps or Secrets in the current namespace.

kubectl describe configmap app-config
Handy

Shows a ConfigMap's keys and values. describe secret shows keys but not decoded values, by design.

Secrets are encoded, not encrypted, by default
A Kubernetes Secret is base64-encoded, not encrypted — anyone with API access to read it can trivially decode it. Treat it as "separated from the image," not "secure at rest," unless your cluster has encryption at rest specifically configured.
Note
Both ConfigMaps and Secrets can be consumed by a pod two ways: as environment variables, or mounted as files into the container's filesystem. Which one to use depends on whether the app expects configuration as env vars or as config files on disk.

Inspecting & Debugging

For once a pod isn't behaving the way you expected — or isn't behaving at all.

kubectl logs my-pod
Essential

Shows a pod's container logs. Add -f to follow live, the same idea as tail -f.

kubectl logs my-pod -c my-container
Handy

Specifies which container's logs to show, for a pod running more than one container.

kubectl exec -it my-pod -- sh
Essential

Opens an interactive shell inside a running pod's container — the main way to poke around inside one directly.

kubectl get events --sort-by=.metadata.creationTimestamp
Advanced

Lists cluster events in chronological order — scheduling failures, image pull errors, and everything else that doesn't show up in a pod's own logs because the pod never actually started.

kubectl get pods -o wide
Handy

Lists pods with extra columns — which node each is running on, and its internal IP — useful when narrowing down a node-specific problem.

kubectl logs only shows what a container already printed
A pod stuck Pending or in CrashLoopBackOff before its process ever really starts won't have useful logs at all. Reach for kubectl describe pod and kubectl get events instead for anything that fails before startup.
Pro trick
kubectl exec -it my-pod -- sh needs the -- before the command, separating kubectl's own flags from the command being run inside the container — forgetting it is a very common source of a confusing error.

Scaling & Rollouts

Changing how many pods are running, and rolling out — or rolling back — a change to what they're running.

kubectl scale deployment my-app --replicas=5
Essential

Changes how many pod replicas a Deployment should keep running, immediately.

kubectl rollout status deployment/my-app
Essential

Watches a Deployment's rollout — from a new image, a config change, anything — until it finishes or fails.

kubectl rollout history deployment/my-app
Handy

Lists previous revisions of a Deployment, each corresponding to a past rollout.

kubectl rollout undo deployment/my-app
Essential

Rolls a Deployment back to its previous revision — the fastest way to recover from a bad deploy.

kubectl set image deployment/my-app app=my-app:v2
Handy

Triggers a new rollout with just the image changed, without editing or reapplying the whole YAML file.

kubectl autoscale deployment my-app --min=2 --max=10 --cpu-percent=80
Advanced

Creates a HorizontalPodAutoscaler that automatically scales replica count between the given bounds based on CPU usage.

Tip
kubectl rollout undo is often faster than diagnosing a bad deploy live — roll back first to restore service, then investigate what went wrong with the breathing room that buys you.

Storage

Pods are disposable; data usually shouldn't be — how Kubernetes separates the two.

kubectl get pv
Handy

Lists PersistentVolumes — actual storage resources provisioned in the cluster, independent of any specific pod.

kubectl get pvc
Essential

Lists PersistentVolumeClaims — a pod's request for storage, which Kubernetes binds to an available PersistentVolume that satisfies it.

kubectl get storageclass
Advanced

Lists StorageClasses, which define how storage gets dynamically provisioned — what kind of disk, which provider — when a PVC doesn't point at an existing volume directly.

kubectl describe pvc my-claim
Handy

Shows a PersistentVolumeClaim's status and which PersistentVolume, if any, it's bound to — the first thing to check when a pod is stuck waiting on storage.

PV vs. PVC
A PersistentVolume is the actual storage. A PersistentVolumeClaim is a pod's request for some amount of storage with certain properties, which Kubernetes matches to a PV — or dynamically provisions one via a StorageClass.

Namespaces & Resource Management

Keeping a cluster organized, and keeping one misbehaving pod from taking down its neighbors.

kubectl create namespace staging
Handy

Creates a new namespace — an isolated group of resources within the same cluster.

kubectl config set-context --current --namespace=staging
Handy

Makes a namespace the default for the current context, so you stop needing -n on every single command.

kubectl top pods
Essential

Shows live CPU and memory usage per pod. Requires the metrics-server add-on to be installed in the cluster.

resources: requests: cpu: 250m memory: 128Mi limits: cpu: 500m memory: 256Mi

kubectl top nodes
Handy

The same idea as kubectl top pods, per node instead of per pod.

Set requests and limits explicitly
A request is what a pod is guaranteed to get, and what the scheduler uses to decide which node it fits on. A limit is the hard ceiling it isn't allowed to exceed. An unset memory limit in particular is how one misbehaving pod can take down everything else sharing its node.

Quick Reference

Already comfortable with kubectl — just blanked on a flag? Search instead of scrolling.

kubectl cluster-info

Show the control plane's address and core cluster services

kubectl get nodes

List every machine in the cluster that can run workloads

kubectl config current-context

Show which cluster kubectl is currently pointed at

kubectl config use-context

Switch kubectl to a different cluster or context

kubectl get namespaces

List every namespace in the cluster

kubectl get all -n

List most resource types in a given namespace at once

kubectl get pods

List pods in the current namespace

kubectl describe pod

Show a pod's full details, events, and container statuses

kubectl get deployments

List Deployments and their desired vs. ready replica counts

kubectl create deployment

Quickly create a Deployment from a container image

kubectl delete pod

Delete a pod; a Deployment replaces it automatically

kubectl get replicasets

List ReplicaSets, the object a Deployment manages underneath

kubectl apply -f

Create or update resources declaratively from a YAML file

kubectl create -f

Create resources from a file; fails if they already exist

kubectl delete -f

Delete every resource defined in a file

kubectl diff -f

Show what would change if a file were applied, without applying it

kubectl get -o yaml

Dump a resource's full definition as YAML

kubectl get services

List Services, the stable network identity in front of pods

kubectl expose deployment

Create a Service in front of an existing Deployment

kubectl port-forward

Tunnel a local port straight to a port inside a pod

kubectl get endpoints

Show which pod IPs a Service is actually routing traffic to

kubectl create configmap

Create a ConfigMap of non-sensitive key/value configuration

kubectl create secret generic

Create a Secret for sensitive values, base64-encoded

kubectl get configmaps

List ConfigMaps in the current namespace

kubectl get secrets

List Secrets in the current namespace

kubectl logs

Show a pod's container logs

kubectl logs -f

Follow a pod's logs live

kubectl logs --previous

Show logs from a pod's last crashed attempt

kubectl exec -it

Open an interactive shell inside a running pod

kubectl get events

List cluster events in chronological order

kubectl get pods -o wide

List pods with node and internal IP columns added

kubectl scale

Change how many replicas a Deployment should keep running

kubectl rollout status

Watch a Deployment's rollout until it finishes or fails

kubectl rollout history

List previous revisions of a Deployment

kubectl rollout undo

Roll a Deployment back to its previous revision

kubectl set image

Trigger a new rollout with just the image changed

kubectl autoscale

Create a HorizontalPodAutoscaler for a Deployment

kubectl get pv

List PersistentVolumes provisioned in the cluster

kubectl get pvc

List PersistentVolumeClaims and their bound status

kubectl get storageclass

List StorageClasses used for dynamic provisioning

kubectl describe pvc

Show a claim's status and which volume it's bound to

kubectl create namespace

Create a new isolated group of resources

kubectl config set-context

Set the default namespace for the current context

kubectl top pods

Show live CPU and memory usage per pod

kubectl top nodes

Show live CPU and memory usage per node

kubectl label

Add or update a label on a resource

46 of 46 commands

Common Use Cases

Real situations, not just isolated commands — the exact sequence that gets you through each one.

You deployed a bad image and need to recover fast

Roll back first, investigate second:

  1. kubectl rollout undo deployment/my-app
  2. kubectl rollout status deployment/my-app

You need to poke at a pod's app without exposing it via a Service

Tunnel straight to the pod, bypassing Services entirely:

  1. kubectl port-forward pod/my-pod 8080:80

A pod is stuck Pending and you don't know why

The reason is almost always in the Events section at the bottom:

  1. kubectl describe pod my-pod

You need to pass an API key to a pod without baking it into the image

Create a Secret, then reference it from the pod's env:

  1. kubectl create secret generic api-key --from-literal=KEY=abc123

You need to see which pods are eating the most CPU right now

Requires the metrics-server add-on to already be installed:

  1. kubectl top pods --sort-by=cpu

You accidentally ran a command against the wrong cluster

Confirm, then switch back before doing anything else:

  1. kubectl config current-context
  2. kubectl config use-context correct-cluster

Debugging & Troubleshooting

The exact pod states and error text kubectl actually prints, decoded.

Pod status stuck at Pending

Almost always a scheduling problem — not enough resources available on any node, or a PersistentVolumeClaim that can't bind. Read the Events section at the bottom of the pod's description for the actual reason.

kubectl describe pod my-pod
CrashLoopBackOff

The container starts and then exits, repeatedly, with increasing delay between retries. The cause is almost always inside the container itself. --previous shows the log from the last crashed attempt, not the current restarting one.

kubectl logs my-pod --previous
ImagePullBackOff or ErrImagePull

Kubernetes can't pull the image. Check for a typo in the image name or tag, confirm the image actually exists in the registry, and confirm an imagePullSecret is configured if it's a private registry.

A Service exists but nothing reaches the pods behind it

Check the Service's endpoints — if the list is empty, its selector almost certainly doesn't match any pod's labels.

kubectl get endpoints my-service
error: You must be logged in to the server (Unauthorized)

Your kubeconfig's credentials for this context have expired or are wrong. Re-authenticate with your cluster provider's usual method, which typically refreshes kubectl's config automatically.

0/3 nodes are available: Insufficient memory

From a pod's Events — no node currently has enough allocatable memory to satisfy this pod's resource request. Either lower the request, free up room on existing nodes, or add capacity to the cluster.

Things to Remember

If you forget everything else on this page, keep these.

  • Always check kubectl config current-context before anything destructive — kubectl runs against whatever cluster it's currently pointed at, with no extra confirmation.
  • A Pod runs your containers; a Deployment manages a set of identical Pods and handles rollouts for you — you almost always create a Deployment, not a bare Pod.
  • kubectl apply -f is declarative and safe to rerun; kubectl create -f is imperative and fails if the resource already exists. Default to apply.
  • kubectl describe and kubectl get events are your first stop for anything that fails before it starts — kubectl logs only shows what a container already managed to print.
  • kubectl rollout undo is often faster than debugging a bad deploy live — roll back first, investigate with the breathing room that buys you.
  • Secrets are base64-encoded, not encrypted, by default — treat that as obscured, not secure, unless your cluster has encryption at rest configured.
  • Set resource requests and limits explicitly — an unset memory limit is how one misbehaving pod takes an entire node down with it.
  • kubectl port-forward bypasses Services and networking entirely — the fastest way to check whether a specific pod's app itself is actually the problem.
  • CrashLoopBackOff means the container starts and exits repeatedly — kubectl logs --previous shows the crash that already happened, not the current restart attempt.

Common Use Cases

Recall the exact kubectl command to roll back a bad deployment before debugging it live
Figure out why a pod is stuck in Pending or CrashLoopBackOff before staring at empty logs
Reference the difference between a ConfigMap and a Secret before wiring configuration into a pod
Search the quick-reference table for a kubectl verb's exact flags instead of digging through the docs

About Kubernetes Cheat Sheet

Kubernetes has one of the steepest cheat-sheet problems around — dozens of resource types (Pods, Deployments, Services, ConfigMaps, PersistentVolumeClaims) that all interact with each other, and most references either dump kubectl's entire verb list flat and alphabetized, or explain one concept in total isolation without ever showing how it actually fits with the others.

This one starts from kubectl basics and the cluster/context/namespace model you need before anything else makes sense, then into Pods and Deployments — what actually runs your code, and the layering between them. From there it covers applying YAML declaratively, Services and networking (how anything actually reaches a Pod), ConfigMaps and Secrets, and on into inspecting and debugging, scaling and rollouts, storage, and namespace/resource management.

Every section calls out the mistakes that actually cause outages or wasted afternoons: running a command against the wrong cluster context with zero extra confirmation, reaching for kubectl create when apply was the safer, rerunnable choice, assuming a Secret is encrypted when it's only base64-encoded by default, skipping resource limits until one misbehaving Pod takes an entire node down with it. There's a searchable quick reference for the moment you already know roughly what you want, and a troubleshooting section built around the exact pod states and error text kubectl actually prints — Pending, CrashLoopBackOff, ImagePullBackOff — not a paraphrase of them.

Nothing on this page requires a running cluster to read, and nothing here connects to one — it's a static reference, like every tool on AllCoreKit. The quick-reference search filters entirely in your browser, and nothing you read or search for is ever sent anywhere or logged.

Frequently Asked Questions

Related Tools

View all Cheat Sheets

Git Cheat Sheet

The Git commands developers actually use daily, organized by workflow — branching, rebasing, undoing mistakes, and recovery — with real examples and a searchable quick reference.

Regex Cheat Sheet

The regex syntax developers actually reach for — anchors, character classes, groups, and lookaround — with real patterns, common mistakes, and a searchable quick reference.

Prompt Engineering Cheat Sheet

The prompt patterns that actually change LLM output — anatomy, few-shot, chain-of-thought, and structured formatting — with real examples, pitfalls, and a searchable quick reference.