EKS Operations
Explore how to systematically troubleshoot EKS clusters by classifying symptoms into control plane, node capacity, or workload runtime issues. Learn to identify the correct evidence source such as API reachability, node status, or pod logs to resolve common failures like Pending pods or CrashLoopBackOff, enabling you to maintain stable Kubernetes workloads on AWS.
When kubectl cannot reach the cluster API, the failure sits on the EKS control plane boundary. Control plane reachability evidence is the place to start. When kubectl works but a Deployment's pods enter CrashLoopBackOff, the control plane is usually healthy enough to run workloads, and the failure is inside the workload's runtime or configuration.
That boundary drives an evidence-first rule in EKS: the symptom gets classified before logs are opened. Otherwise the search ends up in CloudWatch application logs for what's actually an API outage, or staring at kubectl logs when the real problem is that no pods can schedule at all.
Comparing the three symptom families and the fastest first checks for each is how that classification becomes practice rather than theory.
Symptom Family | First User-Visible Symptom | First Logs/Signals to Check | Fastest Confirmation Signal |
Control plane API reachability | kubectl times out | Client errors, DNS, VPC endpoints | Can reach cluster endpoint |
Scheduling and capacity | Pods | Events, scheduler, node groups | Unschedulable event reason |
Workload runtime and config |
| Pod logs, events, probes | Container exits, or probe fails |
The first checks by boundary
Control plane symptoms show up as API ...