Learn to find and fix broken Kubernetes pods, services, DNS, nodes and control plane components with a repeatable method and timed CKA-style labs.
It is 2:10 AM. Checkout is returning errors, and the deployment dashboard shows green.
Most troubleshooting tasks start with a pod that is not healthy. The pod status column is your first clue, and the commands that follow depend on it.
A healthy pod can still be unreachable. A request to a Service passes through several stages, and a fault at any stage looks the same from the...
When a node stops reporting, the control plane marks it NotReady, and pods on it stop being managed correctly.
The control plane is the API server, etcd, the scheduler and the controller manager.
You do not need many commands. You need to know which one answers which question, and to type it from memory.
It is 2:10 AM. Checkout is returning errors, and the deployment dashboard shows green.
Most troubleshooting tasks start with a pod that is not healthy.
A healthy pod can still be unreachable. A request to a Service passes through several stages, and a fault at any stage...
When a node stops reporting, the control plane marks it NotReady, and pods on it stop being managed correctly.
The control plane is the API server, etcd, the scheduler and the controller manager.
You do not need many commands. You need to know which one answers which question, and to type it from memory.
This is the core of the module. Each lab gives you a broken cluster state, a task, and a way to verify your fix.
Timed drills are short, exam-style tasks done entirely from the command line.
Sometimes the usual commands return nothing useful. This topic covers what to do when your investigation hits a wall.
What is the symptom to first command to cause lookup?
Roles that use the skills in this module.
DevOps Engineer
Site Reliability Engineer
Platform Engineer
Not a software engineer sheet. Every problem comes from real DevOps, SRE, Platform and Cloud interviews, from your first script to a system you build yourself.
Open the Coding SheetWork from the outside in. First check whether kubectl can reach the API server, then whether nodes are Ready, then whether pods are healthy, and only then look at Services, DNS and network policies. Each layer depends on the one before it, so a failure at an early layer explains every symptom after it.
The default command shows the current container, which may have just restarted and not printed anything yet. Add the --previous flag to read the output of the last terminated container. If the container never started at all, there are no logs, and kubectl describe pod will show the reason in its events.
Check kubectl get nodes first. If a node is NotReady, every pod on it is affected and the cause is often the kubelet, the container runtime, the network plugin or resource pressure on that node, or lost connectivity between the node and the API server. If all nodes are Ready and only one workload fails, the cause is in that workload's own configuration.
Log in to the control plane node and use crictl, because it talks to the container runtime directly and does not need the API server. Look at the kube-apiserver container logs, then check its static pod manifest in /etc/kubernetes/manifests for a wrong flag or file path. The kubelet journal also shows why the static pod keeps failing.