kubectl Commands

kubectl commands cheatsheet.

Inspect, debug, deploy and scale — the kubectl commands you reach for on any cluster. Tap to copy.

Viewing resources

kubectl get podsList pods in the current namespace

kubectl get pods -AList pods across all namespaces

kubectl get svcList services

kubectl get nodesList cluster nodes

kubectl get deploymentsList deployments

kubectl describe pod <name>Show detailed info and events for a pod

Logs & debugging

kubectl logs <pod>Print a pod's logs

kubectl logs -f <pod>Stream a pod's logs live

kubectl exec -it <pod> -- bashOpen a shell inside a pod

kubectl port-forward <pod> 8080:80Forward a local port to a pod

kubectl top podsShow CPU and memory usage per pod

Managing

kubectl apply -f <file>.yamlCreate or update resources from a file

kubectl delete -f <file>.yamlDelete the resources defined in a file

kubectl delete pod <name>Delete a pod

kubectl scale deploy <name> --replicas=3Scale a deployment to N replicas

kubectl rollout restart deploy <name>Restart a deployment's pods

Context & namespaces

kubectl config get-contextsList available cluster contexts

kubectl config use-context <name>Switch the active cluster context

kubectl get nsList namespaces

kubectl config set-context --current --namespace=<ns>Set the default namespace

The everyday kubectl loop

For all its reputation, day-to-day Kubernetes runs on a handful of verbs. kubectl get lists what exists (pods, services, deployments), kubectl describe shows the full detail and recent events for one thing, and kubectl apply -f ships changes from a YAML file. Getting comfortable with get and describe alone covers most of what you do in a cluster, because they answer the two questions you ask constantly: what's running, and why isn't it healthy?

Debugging pods

When something's broken, two commands do the heavy lifting. kubectl logs <pod> prints a pod's output (add -f to follow it live, like tailing a log), and kubectl exec -it <pod> -- sh opens a shell inside the running container so you can look around from the inside. kubectl get events often reveals the real reason a pod won't start — image pull failures, resource limits, failed health checks — when the pod status alone is cryptic.

Mind your context and namespace

The mistake that bites everyone at least once: running a command against the wrong cluster or namespace. kubectl config get-contexts shows which cluster you're pointed at, and most commands default to your current namespace unless you add -n <namespace>. Before anything that changes state, it's worth a half-second to confirm where you are — an apply or delete against production when you meant staging is a bad afternoon. These pair naturally with the Docker and cloud CLI commands.