Ditch the cheat sheets. A Senior DevOps Engineer breaks down the handful of kubectl commands you’ll actually use every day to diagnose and manage your Kubernetes clusters, based on what the pros in the trenches really do.

From the Trenches: The Only Kubectl Commands You Really Need

It was 3 AM. PagerDuty was screaming about our primary `auth-service` being down. I jumped on a call with Alex, a sharp junior engineer on my team, who was already deep in the weeds. He was flustered, pasting commands from a blog post, trying to check CPU limits, then volume mounts, then network policies. He was drowning in the possibilities. I told him to stop, take a breath, and just run three commands. In less than 90 seconds, we found it: a new ConfigMap had been deployed with a typo in a database URL, causing the pod to enter a nasty crash loop. Alex was trying to boil the ocean when all he needed was a thermometer. This isn’t a knock on him; it’s a rite of passage for every Kubernetes engineer.

The Problem: The ‘kubectl’ Command Overload

Let’s be honest: kubectl is a beast. It’s a Swiss Army knife with a thousand attachments. The official documentation is a perfect, comprehensive reference manual, but it’s not a field guide. When you’re new—or just stressed—staring at that wall of flags and subcommands is paralyzing. You see discussions with arcane uses of --field-selector and complex jsonpath queries and think you need to know it all. You don’t. The Pareto principle is in full effect here: about 20% of the commands will solve 80% of your daily problems. My goal is to give you that 20%.

Inspired by a recent Reddit thread where a bunch of us graybeards shared our go-to commands, I’ve distilled the noise down to the essentials. These are the commands I type, muscle-memory style, dozens of times a day.

The Core Toolkit: My Three Tiers of Kubectl Mastery

I think of my daily kubectl use in three distinct phases: Observation, Interaction, and Declaration.

Tier 1: Situational Awareness (The ‘What’s Happening?’)

This is your first port of call. Before you change anything, you need to understand the state of the system. These three commands are my holy trinity of diagnostics.

1. kubectl get: This is your entry point. It’s the “ls” of Kubernetes. I almost always start with pods.

   # Is the pod running? How many restarts?
   kubectl get pods -n an-important-namespace
   
   # Get more info, like which node it's on. Crucial for debugging node-specific issues.
   kubectl get pods -n an-important-namespace -o wide

   This command isn’t just for pods. It’s your window into everything. Here are some of the other resources I `get` constantly:

   Resource Abbreviation	What it is
   svc	Services (your internal load balancers)
   ing	Ingresses (how traffic gets into the cluster)
   cm	ConfigMaps (your configuration data)
   pvc	PersistentVolumeClaims (your storage)

2. kubectl describe: If `get` tells you what, `describe` tells you why. If a pod is stuck in `Pending` or `CrashLoopBackOff`, this is your next command.

   kubectl describe pod auth-service-b8f9c69d-j4s5f -n an-important-namespace

   My advice? Scroll straight to the bottom and look at the Events section. This is where Kubernetes tells you its life story: “I couldn’t pull the image,” “I failed the liveness probe,” “I couldn’t mount the volume.” It’s pure gold.

3. kubectl logs: You’ve confirmed the pod is running but misbehaving. Time to see what the application itself is saying.

   # Tail the logs in real-time
   kubectl logs -f auth-service-b8f9c69d-j4s5f -n an-important-namespace
   
   # See logs from a pod that died and restarted
   kubectl logs -p auth-service-b8f9c69d-j4s5f -n an-important-namespace

Pro Tip: Do yourself a massive favor and set up an alias. No one has time to type `kubectl` all day.

alias k=kubectl
Your fingers will thank you.

Tier 2: Interactive Troubleshooting (The ‘Let’s Poke It’)

Okay, you’ve observed the situation. Now it’s time to get your hands dirty. These commands let you bridge the gap between your local machine and the isolated world of the cluster.

1. kubectl exec: The “break glass in case of emergency” command. This drops you into a shell inside a running container.

   # Get an interactive shell inside the pod
   kubectl exec -it auth-service-b8f9c69d-j4s5f -n an-important-namespace -- /bin/sh

   Why is this so useful? You can `ls` to check for config files, `cat` them to see if they were mounted correctly, or use `curl` to hit another service from *inside the cluster network*. This is invaluable for diagnosing connectivity issues between your microservices.

2. kubectl port-forward: My absolute favorite “hacky but it works” command. This lets you connect to a pod or service on its cluster port directly from your local machine.

   # Forward my local port 8080 to the service's port 80
   kubectl port-forward svc/auth-service 8080:80 -n an-important-namespace

   Now I can open `http://localhost:8080` in my browser and interact with the service as if it were running on my laptop. It’s perfect for debugging a problematic API or a web UI in a dev environment without having to expose it through an Ingress.

3. kubectl edit: I’m going to get some flak for this one. This command opens a resource’s YAML definition in your default editor, and when you save and close, it applies the changes.
   

   WARNING: Using kubectl edit on a production deployment is a terrible idea. Your changes will be wiped out the next time your CI/CD pipeline runs. This is for quick-and-dirty testing in a dev/staging environment ONLY. You’ve been warned.

   # Don't do this in prod!
   kubectl edit deployment auth-service -n an-important-namespace

   It’s useful for temporarily changing an environment variable or bumping an image tag to see if it fixes an issue before you go through the whole process of a proper PR and deployment.

Tier 3: Declarative Power Plays (The ‘Production Grade’ Moves)

This is where you move from being reactive to being proactive. These commands are about managing the state of your cluster deliberately and safely, the way we do it in production.

1. kubectl apply: This is the heart of declarative configuration and GitOps. You have a YAML file that defines the desired state, and you tell Kubernetes to make it so.

   # Apply all configuration from a directory
   kubectl apply -f ./kubernetes/deploy/
   
   # Or just a single file
   kubectl apply -f auth-service-deployment.yaml

   This is idempotent. You can run it a hundred times, and if nothing has changed in your file, Kubernetes does nothing. It’s the right way to manage applications because your configuration lives in source control, not as a series of manual commands.

2. kubectl rollout: Your deployment’s best friend and your “undo” button. When you `apply` a change to a Deployment, a rollout is triggered. This command lets you manage it.

   # Watch a new deployment happen in real time
   kubectl rollout status deployment/auth-service -n an-important-namespace
   
   # See the history of changes
   kubectl rollout history deployment/auth-service -n an-important-namespace
   
   # The "OH NO" button: Go back to the previous version
   kubectl rollout undo deployment/auth-service -n an-important-namespace

   That `undo` command has saved my bacon more times than I can count. A bad deploy goes out, metrics start to tank, and you can revert to the last known good state in seconds while you figure out what went wrong.

3. kubectl explain: The built-in documentation you’ll actually use. Tired of Googling what a specific field in a YAML file does? Just ask `explain`.

   # What fields can I put in a pod's spec?
   kubectl explain pod.spec
   
   # Tell me more about containers within a pod spec
   kubectl explain pod.spec.containers
   
   # What the heck is a terminationGracePeriodSeconds?
   kubectl explain pod.spec.terminationGracePeriodSeconds

   This command is a massive productivity boost when you’re writing new manifests. It stops the constant context-switching between your editor and the Kubernetes docs website.

And that’s it. Seriously. While there are dozens of other commands, these are the ones that form the foundation of my daily workflow. Master these, and you’ll be able to handle the vast majority of what Kubernetes throws at you. Don’t try to memorize the encyclopedia; just get really, really good with your core toolkit.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions