Container Orchestra, 2015

What you will do

1. list the cluster's nodes and their status kubectl get nodes

   Kubernetes (Greek for "helmsman") shipped from Google in 2014, built on a decade of internal Borg experience. A node is any machine, control-plane or worker, running a kubelet.

2. see extra columns: internal IP, OS image, kernel, container runtime kubectl get nodes -o wide

   -o wide is the same object, more columns — no different API call, just more of the response rendered. Every kubectl output is a real Kubernetes object underneath.

3. inspect one node in full: capacity, allocatable resources, conditions kubectl describe node k8s-node1

   Capacity is the whole box; Allocatable is what the kubelet will actually schedule onto (it reserves some for itself and the OS). Conflating the two is a classic capacity-planning mistake.

4. list namespaces — the cluster's logical partitions kubectl get ns

   default, kube-system, kube-public, kube-node-lease ship with every cluster. Namespaces scope names and RBAC, not performance or security in themselves.

5. see the control plane itself, running as pods kubectl get pods -n kube-system

   etcd, kube-apiserver, kube-controller-manager, kube-scheduler — on a kubeadm cluster, the control plane is not magic infrastructure, it is pods, same as your app, just in kube-system.

6. view the cluster's recent event log kubectl get events

   Events are the audit trail of "what just happened" — Scheduled, Pulled, Created, Started. Every describe's Events section is a filtered view of exactly this stream.

7. view live CPU/memory usage per node (via the metrics-server) kubectl top nodes

   top reads from the metrics-server, a separate lightweight component — not etcd. If metrics-server is not installed, top simply fails; it is optional, not core.

8. list pods in the current (default) namespace kubectl get pods

   A pod is Kubernetes' smallest deployable unit — one or more containers that always land on the same node and share network + storage.

9. list deployments — the controllers that keep pods running kubectl get deploy

   A Deployment does not run containers directly — it manages a ReplicaSet, which manages Pods. Three layers so rolling updates and rollbacks have somewhere to keep history.

10. see which node each pod actually landed on, and its pod IP kubectl get pods -o wide

    The scheduler places each pod exactly once, based on resource requests, affinity/anti-affinity, and taints — -o wide is how you see the outcome of that decision.

11. declaratively create a new deployment from a manifest kubectl apply -f api-deploy.yaml

    apply is declarative: it diffs the manifest against the live object and reconciles the difference. create is imperative and simply fails if the object already exists — apply is the everyday tool.

12. change a deployment's desired replica count kubectl scale deploy web --replicas=3

    Scaling just edits one field, replicas, on the Deployment spec. The ReplicaSet controller does the rest — it is a reconciliation loop, not a one-shot script.

13. delete a single pod directly and watch the deployment heal itself kubectl delete pod web-6c5df97d97-4kxpl

    A core Kubernetes lesson: you almost never delete a pod to "fix" it. Its controller notices the gap between desired and actual state and creates a replacement, self-healing, not magic.

14. list services — the stable network identities in front of pods kubectl get svc

    Pod IPs are ephemeral — a new pod gets a new IP every time. A Service gives a stable ClusterIP and DNS name that survives pods being replaced underneath it.

15. create a Service that load-balances traffic across a deployment's pods kubectl expose deploy web --port=80 --target-port=80

    expose reads the deployment's pod template labels and turns them straight into the new Service's selector — no separate YAML required for the common case.

16. see which pod selector each service is load-balancing to kubectl get svc -o wide

    The SELECTOR column is the entire mechanism: any pod whose labels match gets automatically wired into the Service's Endpoints — no manual registration.

17. inspect a service's endpoints — the actual pod IPs it is routing to kubectl describe svc web

    If Endpoints is empty, the selector matched nothing. That is the most common "service does not work" root cause, and the first thing to check.

18. filter pods by a label selector — the same mechanism services use internally kubectl get pods -l app=web

    Labels are just key=value tags. Every Service, ReplicaSet and NetworkPolicy in the cluster is really just "act on whatever currently matches this selector."

19. tunnel a local port straight to a service, bypassing Ingress entirely kubectl port-forward svc/web 8080:80

    port-forward is the fastest way to poke a service or pod from your own laptop for debugging — it goes over the API server, not the cluster network, so it works even with no Ingress configured yet.

20. list ConfigMaps — non-sensitive configuration stored in the cluster kubectl get cm

    A ConfigMap decouples configuration from the container image — the same image can run in dev or prod by mounting a different ConfigMap, nothing rebuilt.

21. view a ConfigMap's actual key/value data kubectl describe cm app-config

    ConfigMap data is plaintext by design — describe happily prints it. That is exactly why it must never hold a password or API key; that is what Secrets are for.

22. list Secrets — and notice describe never shows you the values kubectl get secret

    Secrets are base64-encoded, not encrypted, by default — a courtesy against accidental terminal leaks, not real security. Real protection needs RBAC plus encryption-at-rest in etcd.

23. roll out a bad image tag and watch the deployment start to update kubectl set image deployment/api api=api:v2-broken

    set image is a one-line shortcut for editing .spec.template.spec.containers[].image — it triggers exactly the same rolling update apply -f would.

24. check whether the rollout is actually progressing kubectl rollout status deployment/api

    By default a Deployment keeps the old, working ReplicaSet up until the new one is Ready — that is why the rollout hangs instead of taking your app down.

25. read the Events section to find out WHY the new pod is stuck kubectl describe pod api-5f6b7c8d9e-p4q5r

    ImagePullBackOff means the kubelet cannot even fetch the image — a typo'd tag, a private registry with no pull secret, or a network-policy block. describe's Events tell you which.

26. try to read the container's logs — and see why that is the wrong tool here kubectl logs api-5f6b7c8d9e-p4q5r

    A container that never started has no logs to show. This is the tell that separates an ImagePullBackOff (check describe) from a CrashLoopBackOff (check logs) — same symptom, opposite diagnosis.

27. roll back to the last working revision kubectl rollout undo deployment/api

    Every Deployment keeps a revision history. undo is a one-line "put the previous ReplicaSet back to full scale, retire the broken one" — no manifest editing required under pressure.

28. force a rolling restart of an already-healthy deployment kubectl rollout restart deployment/web

    A ConfigMap or Secret consumed as an environment variable never updates in a running container — only volume-mounted keys get periodic kubelet syncs. rollout restart is the standard way to pick up env-var config changes: new pods, same image, fresh environment.

29. load the boss scenario — a deployment stuck in CrashLoopBackOff scenario start

    Good incident response is a method, not a guess: reproduce the symptom, read the evidence (describe, then logs), form a hypothesis, fix the root cause, then verify.

30. confirm the symptom and read the restart count kubectl get pods -l app=checkout

    A climbing RESTARTS count with STATUS CrashLoopBackOff means the container starts, then exits non-zero, every time — the kubelet is not the problem, the application is.

31. find the exit code, the last-terminated reason, and the injected environment variable kubectl describe pod checkout-8f7d6c5b4-z1x2c

    Exit Code 1 plus a "Terminated: Error" is the application crashing on its own — describe's Environment section is where a bad env var like a mistyped hostname hides in plain sight.

32. read the actual crash message — the smoking gun kubectl logs checkout-8f7d6c5b4-z1x2c

    Unlike the ImagePullBackOff a few missions ago, this container DID start, so it DID log, and its last words before dying are exactly the evidence you need.

33. apply a corrected manifest: fixed env var AND right-sized to 3 replicas kubectl apply -f checkout-fix.yaml

    A real fix goes in the manifest, not a live kubectl edit — so the correction survives the next apply instead of silently drifting from what is checked in.

34. Boss missionFINAL STEP — expose the now-healthy deployment as a service and confirm the whole incident is resolved kubectl expose deploy checkout --port=80 --target-port=8080

    Diagnose (describe + logs), fix the root cause (apply), scale for real load, expose it to the network — that four-step loop is the entire job, and it is exactly what a CKA exam performance task expects you to demonstrate.

Certificate

Nearby eras

All 25 eras in the Terminal Academy