Kubectl Commands Cheatsheet (2026): Daily Kubernetes CLI Guide for DevOps

Last Updated: January 2026

When something breaks in Kubernetes, nobody has time to remember obscure kubectl flags. I learned that the hard way—usually in production, usually under pressure.

The truth is, you don’t need to memorize every kubectl command. You need quick access to the ones that actually solve problems.

This kubectl commands cheatsheet is built from real-world usage, not documentation theory. It includes the kubectl commands I rely on daily to debug pods, inspect deployments, troubleshoot networking issues, and understand what’s actually happening inside a Kubernetes cluster.

Instead of listing commands alphabetically, this guide is organized by what you’re trying to fix—failed pods, broken services, stuck deployments, resource issues, and late-night incidents.

If you work with Kubernetes in production, bookmark this page. When you’re staring at a pod that won’t start or a deployment that won’t roll out, this cheatsheet will save you time—and frustration.

Kubectl Commands Cheatsheet – Getting Started

Before anything else, you need to know which cluster you’re talking to. I’ve been in situations where someone was debugging the wrong cluster for twenty minutes. Not fun.

Check your current context:

kubectl config current-context

List all available contexts:

kubectl config get-contexts

Switch to a different cluster:

kubectl config use-context my-production-cluster

View your kubeconfig file:

kubectl config view

A tip from experience: if you manage multiple clusters, tools like kubectx and kubens will save your sanity. They let you switch contexts and namespaces with autocomplete instead of typing full names.

Working with Pods: Essential kubectl Commands for Pod Debugging

Most of your time in Kubernetes involves managing pods. Here’s what you actually need to do with them.

Get all pods in the current namespace:

kubectl get pods

Get pods with more details (includes IP addresses and node info):

kubectl get pods -o wide

Get pods from a specific namespace:

kubectl get pods -n my-namespace

Get pods from all namespaces (dangerous command, use carefully):

kubectl get pods -A

Watch pods in real-time (refreshes every second):

kubectl get pods -w

This is incredibly useful when you’re deploying something and want to see pods transition from Pending to Running.

Get detailed information about a specific pod:

kubectl describe pod my-app-5d4f7c6b9

Run this when a pod won’t start. The events section at the bottom usually tells you exactly what went wrong.

See pod logs:

kubectl logs my-app-5d4f7c6b9

Follow logs in real-time (like tail -f):

kubectl logs -f my-app-5d4f7c6b9

Get logs from the previous instance of a pod (if it crashed):

kubectl logs my-app-5d4f7c6b9 --previous

This saved me hours of debugging when I had a pod that crashed immediately on startup.

Execute a command inside a running pod:

kubectl exec -it my-app-5d4f7c6b9 -- bash

Open an interactive shell inside a pod:

kubectl exec -it my-app-5d4f7c6b9 -- sh

The difference: bash is more full-featured, but sh works on minimal containers when bash isn’t installed.

Delete a pod (it will be recreated if managed by a Deployment):

kubectl delete pod my-app-5d4f7c6b9

Deployments: The Most Common Resource

Deployments are how you actually run applications in Kubernetes. Here’s what you need to do with them.

List all deployments:

kubectl get deployments

Get deployment details:

kubectl describe deployment my-app

Check deployment status:

kubectl rollout status deployment/my-app

Run this after deploying something new to see if it actually rolled out successfully.

View rollout history:

kubectl rollout history deployment/my-app

Rollback to the previous version:

kubectl rollout undo deployment/my-app

I’ve used this in production more times than I’d like to admit. Thankfully, it usually works perfectly.

Rollback to a specific revision:

kubectl rollout undo deployment/my-app --to-revision=2

Update the image in a deployment:

kubectl set image deployment/my-app my-container=my-registry/my-app:v2.0

This is how you deploy updates without touching the YAML file.

Scale a deployment:

kubectl scale deployment/my-app --replicas=3

Edit a deployment directly (opens in your default editor):

kubectl edit deployment my-app

This opens the live YAML in your editor. Changes apply immediately. Use with caution in production.

Services and Networking

Services expose your pods to traffic. If pods can’t be reached, check the service.

List services:

kubectl get svc

Get detailed service information:

kubectl describe svc my-service

Get endpoints (which pods are behind the service):

kubectl get endpoints my-service

If this is empty, your pods probably don’t match the service selector.

Port forward to access a service locally:

kubectl port-forward svc/my-service 8080:80

Now you can access the service at localhost:8080. This is invaluable for testing services without exposing them publicly.

Port forward to a specific pod:

kubectl port-forward pod/my-app-5d4f7c6b9 8080:8080

ConfigMaps and Secrets: Managing Configuration

ConfigMaps store configuration, Secrets store sensitive data. They’re similar enough to cover together.

List ConfigMaps:

kubectl get configmaps

View ConfigMap contents:

kubectl describe configmap my-config

Create a ConfigMap from a file:

kubectl create configmap my-config --from-file=config.yaml

Create a ConfigMap from literal values:

kubectl create configmap my-config --from-literal=DB_HOST=localhost --from-literal=DB_PORT=5432

List secrets:

kubectl get secrets

View a secret (base64 decoded):

kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 --decode

Create a secret:

kubectl create secret generic my-secret --from-literal=password=mypassword

Persistent Volumes and Storage

Storage questions come up constantly, and they’re usually frustrating.

List persistent volumes:

kubectl get pv

List persistent volume claims:

kubectl get pvc

Describe a PVC to see what’s mounted:

kubectl describe pvc my-claim

Check storage classes available:

kubectl get storageclass

Debugging and Troubleshooting

When things go wrong (and they will), these commands help.

Get events from a namespace (shows recent activity):

kubectl get events -n my-namespace --sort-by='.lastTimestamp'

This shows you what’s actually happened in the cluster, in order.

Get cluster info:

kubectl cluster-info

Check node status:

kubectl get nodes

Get detailed node information:

kubectl describe node my-node

Get resource requests and limits:

kubectl top nodes
kubectl top pods

These show CPU and memory usage. Useful when things are slow.

Get all resources in a namespace:

kubectl get all -n my-namespace

Check API resources available:

kubectl api-resources

Get API versions:

kubectl api-versions

Advanced Selections and Filtering

Once you know the basics, these filters become your superpowers.

Get pods with specific labels:

kubectl get pods -l app=my-app

Get pods with multiple label conditions:

kubectl get pods -l app=my-app,version=v2

Get resources by field selector:

kubectl get pods --field-selector=status.phase=Running

Output as YAML:

kubectl get pod my-app-5d4f7c6b9 -o yaml

Output as JSON:

kubectl get pod my-app-5d4f7c6b9 -o json

Custom output formatting:

kubectl get pods -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,AGE:.metadata.creationTimestamp

Creating and Applying Resources

You probably manage YAML files, but here’s how to use them.

Apply a YAML file (creates or updates):

kubectl apply -f deployment.yaml

Apply everything in a directory:

kubectl apply -f ./my-manifests/

Create from a YAML file (fails if resource exists):

kubectl create -f deployment.yaml

Dry run to see what would be created:

kubectl apply -f deployment.yaml --dry-run=client -o yaml

This is how you validate YAML before applying it.

Delete resources:

kubectl delete -f deployment.yaml

Delete by name:

kubectl delete deployment my-app

Frequently Asked Questions

Q: How do I find a pod by partial name?

A: Use grep with kubectl. kubectl get pods | grep my-app or use label selectors: kubectl get pods -l app=my-app. Label selectors are more reliable because they work with Kubernetes’s filtering.

Q: What’s the difference between kubectl delete pod and kubectl scale deployment?

A: Deleting a pod removes it, but if it’s managed by a Deployment, Kubernetes immediately spins up a replacement. Scaling changes the number of replicas. The Deployment will create or delete pods to match your desired count. If you want to restart a pod without losing it, delete it and let the Deployment recreate it.

Q: Can I edit a running deployment safely?

A: Yes, kubectl edit deployment my-app is safe. Any changes trigger a rolling update. But I prefer keeping deployments in version control instead of hand-editing them. It’s clearer what changed and easier to revert.

Q: How do I know if a deployment rolled out successfully?

A: Run kubectl rollout status deployment/my-app. It waits until all replicas are ready. If it hangs, something’s wrong. Check kubectl describe deployment my-app to see what’s stuck.

Q: What’s the fastest way to restart all pods in a namespace?

A: kubectl rollout restart deployment -n my-namespace restarts all deployments, which recreates their pods. It’s cleaner than deleting pods manually.

Q: How do I access logs from multiple pods at once?

A: For pods matching a label: kubectl logs -l app=my-app --tail=100. The --tail flag limits output. You can also use --all-containers=true to see logs from all containers in a pod.

Q: Can I use kubectl without worrying about messing things up?

A: Use --dry-run=client before applying changes: kubectl apply -f file.yaml --dry-run=client. This shows what would happen without actually doing it. Also, use namespaces to isolate testing from production.

Q: How do I monitor pod restarts?

A: kubectl get pods -w shows restarts in real-time. For more detail: kubectl describe pod my-app shows restart count in the status section.

Q: What if I accidentally delete something important?

A: If it’s managed by a Deployment or StatefulSet, it auto-recreates. If you deleted a Deployment itself, it’s gone unless you have backups or version control. This is why everything should be in git. For data, persistent volumes protect you from pod deletion but not PVC deletion.

Q: How do I export and backup my cluster configuration?

A: kubectl get all -A -o yaml > backup.yaml exports everything. It’s not a true backup for data, but it saves your configurations. For production, use proper backup tools like Velero.

The Bottom Line

Here’s my honest take: you don’t need to memorize every kubectl command. You need to know how to find and fix problems when they happen. This cheatsheet covers about 80% of what most engineers actually do.

The remaining 20%? That’s context-specific. Your monitoring setup, your deployment strategy, your security model—they all change what commands matter most. But once you’re comfortable with what’s in this guide, you can learn anything else you need.

Keep a bookmark to this page. When you’re in production at 2 AM staring at a pod that won’t start, you’re going to want quick answers. And you’ll find them here.

The goal isn’t to become a kubectl wizard. It’s to become competent enough to troubleshoot your own infrastructure without constantly Googling. That competence comes from knowing what these commands do and why you’d use them.

Go forward with confidence. You’ve got this.

Additional Resources

External Resources:

Internal Resources:

About the Author

Kedar Salunkhe

DevOps Engineer | Seven years of fixing things that break at 2am

Kubernetes • OpenShift • AWS • Coffee

I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy. You can usually find me where the coffee is strong and the error logs are confusing.