The Kubernetes Failure Map

The Kubernetes Failure Map

Where Kubernetes Actually Breaks in Production

Kubernetes doesn’t fail randomly. It fails in patterns. If you don’t know the pattern, you debug in circles.

Most engineers know how to deploy to Kubernetes. Very few know how Kubernetes dies.

And in production, the difference between those two skills is the difference between:

• 5-minute incident resolution

• 2-hour panic war room

Today, we’ll give you something most engineers never build: A mental failure map of Kubernetes.

First Truth: Kubernetes Is Two Systems

Most people treat Kubernetes as “one thing.” It is not.

It is two separate planes:

If you don’t separate these in your mind, you will misdiagnose outages.

The 7 Major Kubernetes Failure Zones

Here’s the real failure map.

Kubernetes breaks into seven predictable zones:

1. API Server Failure

2. etcd Failure

3. Scheduler Failure

4. Node / kubelet Failure

5. CNI (Networking) Failure

6. DNS Failure

7. Resource Pressure Failure

Let’s walk through each like we’re in a real incident.

1. API Server Failure: “Everything Looks Dead.”

Real Scenario

• kubectl get pods hangs

• CI/CD pipeline stuck

• HPA not scaling

• No new deployments possible

But existing pods still serve traffic.

Why?

The API server is the control brain.

If it fails:

• You can’t modify cluster state

• But running workloads continue

This is a control-plane-only outage.

How to Confirm

1. kubectl get component statuses

2. `kubectl cluster-info`

3. curl https://<api-server-endpoint>/healthz

In managed EKS/GKE, check cloud metrics.

KGI Insight

If existing pods are serving traffic but you can’t deploy or scale, suspect API server first.

2. etcd Failure: “The Memory of the Cluster Is Corrupt.”

etcd stores the cluster state.

If etcd is slow:

• API latency spikes

• Scheduling delays

• Controllers behave weirdly

If etcd is corrupt:

• Cluster may refuse to start

Real-World Scenario

1. A company scaled to 25k objects.

2. etcd disk hit 95% usage.

3. Write latency increased.

Result:

• Deployments stuck in “Creating.”

• Controllers timing out

• Cluster appeared “slow but aliv.e”

Diagnose

1. etcdctl endpoint status

2. etcdctl alarm list

KGI Insight

etcd performance = cluster performance.

If etcd is unhealthy, everything becomes “mysteriously slow.”

3. Scheduler Failure: “Pods Stay Pending Forever.”

Real Scenario: You deploy.

Pods remain in: Pending

Why? Scheduler decides where pods run.

Common causes:

• Node selectors mismatch

• Taints not tolerated

• Insufficient resources

• Affinity rules too strict

Diagnose: kubectl describe pod 

Look at events:

• “0/5 nodes available”

• “node(s) had taint”

• “insufficient cpu”

KGI Insight

If pods are Pending, Kubernetes is healthy.

Your constraints are not.

4. Node / kubelet Failure: “Pod Exists in API, But Not on Node”

Real Scenario: kubectl get pods shows Running.

But:

• Service unreachable

• Logs missing

• Node shows NotReady

Why? The kubelet stopped reporting.

Check:

1. kubectl get nodes

2. journalctl -u kubelet

3. systemctl status kubelet

If kubelet dies:

• Control plane still thinks pod exists

• Reality disagrees

This creates “ghost pods.”

KGI Insight

API shows desired state.

kubelet shows actual state.

Confuse them, and you chase illusions.

5. CNI (Networking) Failure: “Pods Run, But Nothing Talks”

Most production outages in Kubernetes are networking.

Real Scenario:

• Pods healthy

• CPU normal

• But the services timeout

Common causes:

• CNI plugin crash

• IP exhaustion

• conntrack table full

• Calico policy blocking traffic

Check IP exhaustion: kubectl get pods -o wide

If pod stuck in: ContainerCreating

Possible CNI failure.

On node: ip addr

conntrack exhaustion

1. cat /proc/sys/net/netfilter/nf_conntrack_count

2. `cat /proc/sys/net/netfilter/nf_conntrack_max`

If count ~ max → new connections fail silently.

KGI Insight

Most “application latency” in Kubernetes is CNI or conntrack.

6. DNS Failure: “Everything Times Out Randomly.”

CoreDNS is small but deadly.

If DNS is slow:

• Pods wait

• Apps hang

• Retries explode

Check:

1. kubectl get pods -n kube-system

2. kubectl logs -n kube-system deployment/coredns

Common issue:

• Too many DNS queries

• No caching

• Upstream resolver slow

Real Incident: A company disabled DNS caching in Java apps.

Result:

• 50k QPS to CoreDNS

• DNS throttled

• The entire cluster slowed

KGI Insight

DNS issues rarely crash pods. They just slow them.

7. Resource Pressure Failure: “The Silent Killer.”

This is the most common real-world failure.

Node pressure types:

• MemoryPressure

• DiskPressure

• PIDPressure

Check: kubectl describe node <node>

Look for: Conditions: MemoryPressure = True

Real Scenario

Java app memory leak.

Nodes swap.

OOM killer triggered.

Pods restarted randomly.

But CPU metrics looked fine.

KGI Insight

Kubernetes doesn’t break first. Linux does.

Control Plane runs parallel: API Server → etcd → Scheduler → Controllers

Every failure lives somewhere on this tree. If you don’t know where to look, you look everywhere.

Real War Room Example

Symptoms:

• Random 504 errors

• CPU normal

• Pods healthy

• No restarts

Where to start?

Use the map:

1. API working? Yes.

2. Pods running? Yes.

3. Networking? Investigate.

4. conntrack count? At the limit.

5. Root cause? Node-level connection tracking exhaustion.

Solved in 12 minutes.

Without map? 2 hours of guesswork.

The KGI Kubernetes Insight

Kubernetes doesn’t fail in Kubernetes. It fails in Linux, networking, storage, or state management.

If you debug only at YAML level, you will never master production.

Bookmark Section: Rapid Diagnosis Commands

# Cluster health

kubectl get nodes
kubectl get pods -A

# Pending pods

kubectl describe pod <pod>

# Node pressure

kubectl describe node <node>

# Networking

ss -s
conntrack -S

# DNS

kubectl logs -n kube-system deployment/coredns

# API latency

kubectl get --raw /healthz

Final Thought

Kubernetes is not complex. It is layered.

Once you see the layers, you stop panicking. You start navigating.

Next Issue

Next Friday, we will: Break a Kubernetes cluster intentionally and walk through the failure using this map.

Real commands. Real metrics. Real recovery.

“Don’t memorize commands. Memorize where systems fail.”

Welcome to kubectl get insights.

Where DevOps engineers learn to think like architects.

---