Three commands answer most questions: get, describe, and logs.

Every kubectl command is an HTTP call to the API server. Start with the cheapest read and move deeper only when needed.

zsh: shop / gke-eu-prod

$ kubectl apply -f deployment.yaml
deployment.apps/checkout created
$ kubectl get pods -l app=checkout -o wide
NAME              READY  STATUS   NODE        IP
checkout-7d9f8-a  1/1    Running  gke-np1-x2  10.244.1.5
checkout-7d9f8-b  0/1    Pending  <none>
$ kubectl describe pod checkout-7d9f8-b
Events:
  Warning  FailedScheduling  0/3 nodes: Insufficient cpu
$ kubectl logs checkout-7d9f8-a -c app --tail=20
$ kubectl rollout status deployment/checkout

1 get

What exists and what state is it in? Add -o wide, -o yaml, -l label, -A.

2 describe

Why is it in that state? The Events at the bottom name the failing step.

3 logs

What did the application say? Use -c for a container and --previous after a crash.

4 apply and diff

kubectl diff -f then apply -f. Declarative, repeatable, reviewable.

Local practice: kind, minikube or k3d give you a real cluster on a laptop in a minute. Production uses the same commands.

kubectl: get, describe, events first

kubectl is a thin client. Run any command with -v=8 and you will see the HTTP request it sends to the API server. That is why everything you can do with kubectl, controllers and CI tools can do too, using the same API and the same authorization.

Learn the diagnostic order. get shows what exists and a one-word status. describe adds the detail and, crucially, the Events: a short history written by the scheduler, kubelet and controllers, such as FailedScheduling with its reason. logs shows what the application itself wrote; add --previous to read the last crashed container. Many problems are solved by these three alone, and Deck 4 turns them into full diagnostic trees.

For changes, prefer declarative commands: edit the YAML, run kubectl diff to preview, then kubectl apply. Imperative shortcuts like kubectl run or kubectl scale are fine for experiments, but they leave no record and drift from what is in Git.

To practise you do not need a cloud account: kind runs a cluster inside Docker containers, minikube uses a VM or container, k3d runs k3s in Docker. Reveal the four steps with the right arrow. The terminal output is a representative reconstruction, not a capture from a real cluster.