10 Essential kubectl Commands Every Developer Should Know

There are over 400 kubectl subcommands. Nobody uses 400 subcommands. In two years of running production Kubernetes clusters, I probably use about 15 commands regularly, and 10 of them show up every single day.

This isn't an exhaustive reference — the official Kubernetes docs are for that. This is the set of commands you actually need to be functional on any K8s cluster, with real example output and the flags that matter.

Before we start: install kubectl shell completion. Tab completion for resource names saves more time than any shortcut I know.

Setup: Useful Aliases

Before the commands, a few aliases that make daily life better:

# Add to your .bashrc or .zshrc
alias k='kubectl'
alias kns='kubectl config set-context --current --namespace'
alias kctx='kubectl config use-context'

# Show current context and namespace in your prompt
# (use kube-ps1 for this — it's worth it)

Most people type k instead of kubectl within a week. It adds up.

1. kubectl get — Your Constant Companion

kubectl get lists resources. You'll type this hundreds of times a day.

kubectl get pods

NAME                        READY   STATUS    RESTARTS   AGE
web-app-7d4b9c8f5-2xkrm    1/1     Running   0          2d
web-app-7d4b9c8f5-p9vn8    1/1     Running   0          2d
web-app-7d4b9c8f5-wr5tq    1/1     Running   0          2d
postgres-0                  1/1     Running   0          5d

Common variations:

# Get pods in a specific namespace
kubectl get pods -n production

# Get pods across all namespaces
kubectl get pods -A

# Get more detail (node, IP, etc.)
kubectl get pods -o wide

# Watch in real time (updates automatically)
kubectl get pods -w

# Get everything in a namespace
kubectl get all -n staging

# Get specific resource types
kubectl get deployments,services,ingress

# Output as YAML
kubectl get pod web-app-7d4b9c8f5-2xkrm -o yaml

The -o wide flag is one I use constantly — it shows which node a pod is on, useful for debugging node-specific issues.

2. kubectl describe — When Get Isn't Enough

describe gives you the full story on a resource, including events at the bottom which are almost always where the answer to "why is this broken" lives.

kubectl describe pod web-app-7d4b9c8f5-2xkrm

Name:             web-app-7d4b9c8f5-2xkrm
Namespace:        default
Node:             node-1/10.0.0.5
Start Time:       Wed, 29 May 2026 14:22:31 +0000
Labels:           app=web-app
Status:           Running
IP:               172.17.0.4

Containers:
  web:
    Image:          myapp:1.2
    Port:           3000/TCP
    Limits:
      cpu:     500m
      memory:  256Mi
    Requests:
      cpu:     100m
      memory:  128Mi
    Liveness:   http-get http://:3000/health delay=30s timeout=5s

Events:
  Type    Reason     Age   Message
  ----    ------     ----  -------
  Normal  Scheduled  2d    Successfully assigned to node-1
  Normal  Pulled     2d    Successfully pulled image "myapp:1.2"
  Normal  Started    2d    Started container web

The Events section at the bottom is critical. ImagePullBackOff, OOMKilled, Liveness probe failed — problems announce themselves here.

# Describe a deployment
kubectl describe deployment web-app

# Describe a node (great for capacity issues)
kubectl describe node node-1

3. kubectl logs — Reading Container Output

kubectl logs web-app-7d4b9c8f5-2xkrm

Useful flags:

# Stream logs in real time
kubectl logs -f web-app-7d4b9c8f5-2xkrm

# Show last 100 lines
kubectl logs --tail=100 web-app-7d4b9c8f5-2xkrm

# Logs from the previous container instance (after a crash)
kubectl logs --previous web-app-7d4b9c8f5-2xkrm

# If the pod has multiple containers, specify which one
kubectl logs web-app-7d4b9c8f5-2xkrm -c sidecar-container

# Logs from all pods matching a label (very useful for deployments)
kubectl logs -l app=web-app --tail=50

The -l label selector approach is something I use constantly. Instead of finding the exact pod name, just select by label and get logs from all matching pods at once.

4. kubectl exec — Getting Into a Running Container

Sometimes you need to poke around inside a container. exec runs a command in it.

# Get an interactive shell
kubectl exec -it web-app-7d4b9c8f5-2xkrm -- sh

# If bash is available
kubectl exec -it web-app-7d4b9c8f5-2xkrm -- bash

# Run a one-off command without interactive mode
kubectl exec web-app-7d4b9c8f5-2xkrm -- env
kubectl exec web-app-7d4b9c8f5-2xkrm -- ls /app
kubectl exec web-app-7d4b9c8f5-2xkrm -- cat /app/config.json

Note: many minimal container images (Alpine-based) only have sh, not bash. Use -- sh as your default.

A pattern I use often: checking if a service can reach another service from inside the cluster:

kubectl exec -it web-app-7d4b9c8f5-2xkrm -- sh
# Inside the container:
wget -O- http://postgres-service:5432
curl http://redis-service:6379

5. kubectl apply — Deploying Configuration

apply is how you deploy. Point it at a YAML file (or directory) and Kubernetes reconciles the live state with what you've described.

# Apply a single file
kubectl apply -f deployment.yaml

# Apply all YAML files in a directory
kubectl apply -f ./k8s/

# Apply from a URL
kubectl apply -f https://raw.githubusercontent.com/org/repo/main/deploy.yaml

# Preview what would change without applying (dry run)
kubectl apply -f deployment.yaml --dry-run=client

# Show the diff between current and desired state
kubectl diff -f deployment.yaml

The --dry-run=client flag is your safety net before applying changes to production. Always use it when you're unsure.

6. kubectl rollout — Managing Deployments

This is the one people forget about and then struggle without.

# Check the status of a rolling update
kubectl rollout status deployment/web-app

# View rollout history
kubectl rollout history deployment/web-app

# Rollback to the previous version
kubectl rollout undo deployment/web-app

# Rollback to a specific revision
kubectl rollout undo deployment/web-app --to-revision=3

# Pause a rollout (useful for canary deployments)
kubectl rollout pause deployment/web-app

# Resume a paused rollout
kubectl rollout resume deployment/web-app

# Restart all pods in a deployment (forces re-pull of image with same tag)
kubectl rollout restart deployment/web-app

kubectl rollout restart is the proper way to force a pod refresh. Many people delete pods manually — that works but it's messier. Restart triggers a proper rolling update.

7. kubectl scale — Changing Replica Count

# Scale a deployment to 5 replicas
kubectl scale deployment web-app --replicas=5

# Scale down to 0 (stops all pods but keeps the deployment)
kubectl scale deployment web-app --replicas=0

# Scale a StatefulSet
kubectl scale statefulset postgres --replicas=3

Scaling to 0 is useful for maintenance — it stops the pods without deleting the deployment configuration. Scale back up when you're done.

8. kubectl port-forward — Local Access to Cluster Services

You don't need an Ingress or LoadBalancer to test a service locally. Port forwarding creates a tunnel from your laptop directly to a pod or service.

# Forward local port 8080 to port 3000 in the pod
kubectl port-forward pod/web-app-7d4b9c8f5-2xkrm 8080:3000

# Forward to a service (load balances across pods)
kubectl port-forward service/web-app-service 8080:80

# Forward to a deployment
kubectl port-forward deployment/web-app 8080:3000

# Access a database directly (very useful for debugging)
kubectl port-forward service/postgres 5432:5432

After running this, localhost:8080 on your machine connects to the pod. Press Ctrl+C to stop the tunnel. I use this almost daily for debugging — connecting to a database, hitting an internal API, checking a metrics endpoint.

9. kubectl config — Managing Contexts

Real workloads usually involve multiple clusters — development, staging, production. kubectl config manages which cluster you're talking to.

# Show all contexts
kubectl config get-contexts

# Switch to a different cluster
kubectl config use-context production-cluster

# Show current context
kubectl config current-context

# Set namespace for current context (avoids typing -n all the time)
kubectl config set-context --current --namespace=my-app

# View your kubeconfig file
kubectl config view

Output of get-contexts:

CURRENT   NAME                  CLUSTER          AUTHINFO         NAMESPACE
*         local-minikube        minikube         minikube         default
          staging-eks           eks-staging      eks-staging      staging
          production-gke        gke-prod         gke-prod         production

The * shows your active context. Getting this wrong and applying to production when you meant staging is a rite of passage that everyone does once. After that, you double-check your context every time.

10. kubectl delete — Cleaning Up

# Delete a specific pod
kubectl delete pod web-app-7d4b9c8f5-2xkrm

# Delete a resource defined in a file
kubectl delete -f deployment.yaml

# Delete by label
kubectl delete pods -l app=web-app

# Delete a namespace (removes EVERYTHING in it)
kubectl delete namespace staging

# Force delete a stuck pod
kubectl delete pod stuck-pod --grace-period=0 --force

Be careful with --force and --grace-period=0. It skips the graceful shutdown sequence and can cause issues if your app wasn't designed to handle abrupt termination. Only use it when a pod is genuinely stuck (common with evicted pods that won't clean up).

Bonus: kubectl get events

This one doesn't make the top 10 list because it's not used constantly, but it's invaluable when debugging:

# Get all events in current namespace, newest last
kubectl get events --sort-by=.lastTimestamp

# Watch events in real time
kubectl get events -w

# Events for a specific namespace
kubectl get events -n production --sort-by=.lastTimestamp

Quick Reference Table

Putting It Into Practice

The best way to learn these commands is to have a local cluster to experiment on. Minikube is the most accessible option — install it, run minikube start, and you have a single-node Kubernetes cluster on your laptop. Then deploy a Node.js app on Kubernetes with Minikube — that walkthrough uses all 10 of these commands in a real deployment sequence.

If you're building out the skills from scratch, the web dev roadmap 2026 puts Kubernetes in context alongside all the other things a backend developer needs to know. And once you're ready to automate deployments, CI/CD pipeline best practices shows you how these commands fit into automated pipelines.

For the backend side of what you're deploying, look at Node.js vs Go vs Python — the language you pick affects how you containerise and operate your apps.

Conclusion

These 10 commands — get, describe, logs, exec, apply, rollout, scale, port-forward, config, delete — cover the vast majority of what you'll do day to day in a Kubernetes environment. You don't need to memorise every flag immediately. Focus on the core command, then learn the flags as you hit the situations where they matter.

The thing about kubectl is that muscle memory builds fast. After a few weeks, you'll be typing these without thinking. Start with a local Minikube cluster, deploy something you actually care about, and break it deliberately. That's where the learning happens.

FAQ

How do I switch between Kubernetes clusters with kubectl? Use kubectl config use-context <context-name> to switch clusters. Run kubectl config get-contexts to see all available contexts. If you work with many clusters, install kubectx — it's a small tool that makes switching one command: kubectx my-cluster. It also lets you switch namespaces fast with kubens.

What is the difference between kubectl apply and kubectl create? kubectl create creates a resource and errors if it already exists. kubectl apply creates the resource if it doesn't exist, or updates it if it does. In practice, use apply for everything unless you specifically want the 'already exists' error as a guard. Apply is also idempotent, which makes it safe for CI/CD pipelines.

How do I debug a pod that keeps crashing? Start with kubectl describe pod <name> to see events and status. Then kubectl logs <name> --previous to see logs from the last crash. If the container won't even start, check the image name, environment variables, and resource limits. kubectl get events --sort-by=.lastTimestamp shows cluster-wide events in order, which often reveals the root cause faster than looking at individual pods.