kubectl CLI Command Reference

Overview

Overview

kubectl is the Swiss Army knife of Kubernetes operations. Knowing only kubectl get and kubectl apply is not enough for interviews, and the CKA and CKAD exams are entirely kubectl-based with no GUI.

What interviewers expect

• Debugging workflow — describe → logs → exec
• Local access — port-forward, proxy
• Node management — cordon, drain, taint

The most important debugging habit

Always start with kubectl describe pod and read the Events section before checking logs.

> [!IMPORTANT] Events surface scheduling, image pull and probe failures before any log output exists.

Key concepts

kubectl describe Events section

The Events table at the bottom of kubectl describe pod output is produced by the scheduler, kubelet, and other controllers. It shows the sequence of actions and failures — FailedScheduling (no node found), BackOff (crash loop), Failed (image pull error), Killing (probe triggered restart). This is the first diagnostic step for any pod that is not Running.

kubectl logs --previous

Fetches logs from the most recently terminated container instance in the pod — not the currently running one. Critical for CrashLoopBackOff: the current container restarts immediately and may produce no output, but --previous shows what the crashed instance printed before dying.

kubectl port-forward vs kubectl proxy

port-forward tunnels directly to one pod's TCP port, bypassing the Service — useful for debugging a specific pod. proxy exposes the full Kubernetes REST API at localhost and can also proxy to Services via the /api/v1/namespaces//services//proxy/ path — useful for accessing any cluster service without changing routing.

cordon vs drain

cordon marks a node unschedulable (no new pods) but does not touch existing pods. drain = cordon + evict all pods (respecting PodDisruptionBudgets). Use cordon for soft maintenance preparation; use drain before OS upgrades or node replacement.

Taint effects: NoSchedule vs NoExecute

NoSchedule prevents NEW pods without a matching toleration from being scheduled on the node — existing pods are unaffected. NoExecute additionally evicts EXISTING pods without a matching toleration (after optional tolerationSeconds). NoExecute is used by Kubernetes itself to evict pods when a node becomes NotReady.

When to use it

• Diagnosing a pod stuck in Pending — kubectl describe pod → Events section shows FailedScheduling reason
• Investigating CrashLoopBackOff — kubectl logs --previous to see the crash output from the prior container instance
• Accessing a cluster-internal service from laptop — kubectl port-forward service/ 8080:80
• Preparing a node for OS maintenance — kubectl cordon then kubectl drain with --ignore-daemonsets
• Checking which pods are consuming the most memory — kubectl top pods --sort-by=memory

More DevOps topics

• Jenkins
• Jenkins Controller vs Agent Architecture
• Jenkinsfile — Pipeline as Code
• JFrog Artifactory — Production Administration, Errors and Mistakes
• JFrog Xray — Policies, Watches, Impact Analysis, Errors and Mistakes
• Karpenter — Node Autoscaling
• Kubernetes — Stuck Rollouts, Version Upgrades and Mistakes
• Kubernetes Admission Control
• Kubernetes AI and GPU Scheduling
• Kubernetes API Aggregation
• Kubernetes API Errors — 4xx and 5xx Explained
• Kubernetes Architecture