Real failures usually trace to one mechanism from this deck.

Each case names the situation, the cause two levels deep, the fix and the lesson.

On-prem RKE2

kubectl apply fails everywhere

Symptom: every write is rejected; reads work.

Cause: etcd NOSPACE alarm, because compaction and defragmentation were never automated on this cluster.

Fix: compact, defrag one member at a time, alarm disarm.

Lesson: managed clusters hide this; self-managed ones need monitoring on etcd size.

EKS

One node failure, whole service down

Symptom: 3/3 replicas, then total outage.

Cause: all replicas landed on one node because nothing told the scheduler to spread them.

Fix: topology spread across zones plus a PDB.

Lesson: replica count is not redundancy.

GKE

Deployment shows 2 of 3, no Pending Pods

Symptom: a Pod never appears and nothing is Pending.

Cause: namespace ResourceQuota rejected it at admission, so no Pod object was created.

Fix: read the ReplicaSet events and raise or right-size the quota.

Lesson: admission failures are not scheduling failures.

When something breaks, ask which mechanism owns it: admission, etcd, scheduler, kubelet, endpoints, DNS or policy. The module map is your checklist.

Three foundations-level incidents, one cause each

These three incidents are composites of common real failures, and each maps to a mechanism you have studied. On the on-prem RKE2 cluster, the team had never scheduled etcd maintenance. Revision history accumulated, the database reached its quota, etcd raised the NOSPACE alarm and rejected all writes, so every kubectl apply failed while reads still worked, which was confusing. The fix is the compact, defragment, disarm sequence, and the lasting remedy is monitoring database size and automating maintenance. On managed clusters the provider handles this.

On EKS, a critical service had three replicas but no spread rule. When one node failed, every replica went with it. kubectl get pods had reported 3/3 Running right up until the failure, which is why replica count is not redundancy. Topology spread constraints across zones and a PodDisruptionBudget are the fix.

On GKE, a Deployment sat at two of three replicas while kubectl get pods showed nothing Pending. The namespace's ResourceQuota had rejected the third Pod at admission, so the Pod object never existed. The evidence was in the ReplicaSet's events. The lesson is to check the right object: admission failures surface on the controller, scheduling failures on the Pod.

Reveal the cases with the right arrow. In Deck 4 we turn this thinking into systematic diagnostic trees covering CrashLoopBackOff, OOMKilled, Pending, DNS and node failures.