"If Pods keep getting recreated and their IP addresses change, how does my application continue to work?"

It's a great question because understanding the answer unlocks one of the most important concepts in Kubernetes networking.

The short answer is:

Applications should never communicate directly with Pods. They should communicate with Services.

Let's see why.

The Problem with Pod IPs

Every Pod in Kubernetes gets its own IP address.

For example:

Pod-1 → 10.244.1.10
Pod-2 → 10.244.1.11
Pod-3 → 10.244.1.12

Everything works fine until a deployment happens.

A Pod crashes or gets replaced.

Pod-1 → 10.244.1.10
Pod-4 → 10.244.3.55
Pod-3 → 10.244.1.12

Notice what happened?

Pod-2 disappeared and Pod-4 got a completely different IP address.

If applications were configured to connect directly to Pod IPs, every deployment would risk breaking connectivity.

Clearly, we need something more stable.

Enter Kubernetes Services

A Service provides a stable way to access a group of Pods.

Instead of talking directly to Pod IPs, applications talk to a Service.

      Application
         │
        ▼
 Kubernetes Service
        │
 ┌───┼───┐
 ▼    ▼    ▼
Pod    Pod   Pod

The Service remains constant even when Pods are created, deleted, scaled, or replaced.

Think of it like a company's customer support number.

Employees may come and go, but customers continue calling the same number.

The company routes the call internally.

A Kubernetes Service works similarly.

How Traffic Flows

Suppose you have a backend application running three Pods.

backend-1
backend-2
backend-3

A Service selects those Pods using labels.

Example Service:

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080

Any Pod with:

labels:
  app: backend

becomes part of the Service.

When a request reaches the Service:

1. Kubernetes identifies healthy Pods matching the selector.

2. One Pod is chosen.

3. Traffic is forwarded to that Pod.

4. If a Pod disappears, it is removed automatically.

The client never notices the change.

What Happens During a Deployment?

Let's say we start with:

Service
   │
   ├── Pod-1
   ├── Pod-2
   └── Pod-3

Now a rolling update begins.

Pod-2 terminated
Pod-4 created

Kubernetes updates the Service backend list automatically.

Service
   │
   ├── Pod-1
   ├── Pod-4
   └── Pod-3

Traffic continues flowing.

No application configuration changes.

No DNS updates.

No manual intervention.

This is one of the reasons Kubernetes can perform rolling deployments with minimal disruption.

A Real Production Incident

I once investigated an incident where:

• All Pods were Running

• The application was unreachable

• Container logs showed no errors

The team spent hours checking application code.

The actual problem was much simpler.

The Service selector didn't match the Pod labels.

Service:

selector:
  app: payment

Pods:

labels:
  app: payments

Notice the difference?

payment
payments

Because the labels didn't match, the Service had no backend Pods.

The application was effectively disconnected.

A small typo caused a major outage.

The First Three Things I Check

Whenever a Kubernetes application is unreachable, I usually check these first:

1. Verify the Service

kubectl get svc

Ensure the Service exists and exposes the expected port.

2. Check Endpoints

kubectl get endpoints

or

kubectl get endpointslices

If there are no endpoints, the Service has no healthy backend Pods.

3. Verify Labels

kubectl get pods --show-labels

Compare Pod labels with the Service selector.

Most Service-related issues can be identified within minutes using these commands.

The Mental Model That Helps

Whenever you're learning Kubernetes networking, remember:

Pods are temporary.

Services are permanent.

Pods can be:

• Created

• Deleted

• Restarted

• Rescheduled

Services remain stable.

Applications should trust Services, not Pod IPs.

Once this concept clicks, topics like:

• CoreDNS

• Ingress

• Load Balancers

• API Gateways

• Service Meshes

become much easier to understand because they all build on top of the Service abstraction.

Key Takeaways

• Pod IPs are temporary and can change at any time.

• Services provide stable networking for applications.

• Services use label selectors to identify backend Pods.

• Kubernetes automatically updates Service backends during deployments.

• Many production outages occur because Service selectors don't match Pod labels.

• Always check Services, Endpoints, and Labels during troubleshooting.

The next time an application becomes unreachable in Kubernetes, don't start with container logs.

Start by asking:

"Does the Service actually know where my Pods are?"

That simple question can save hours of debugging.

#kubernetes #devops #sre #cloud-native #networking #platform-engineering #containers #docker

Why DNS failures are deceptive

When DNS breaks in a Kubernetes cluster, it rarely announces itself clearly. You don't see a message that says "CoreDNS is throttled." What you see instead is: service timeouts, app-level connection errors, "host not found" in application logs, and engineers spending hours suspecting the wrong component.

DNS is the nervous system of a Kubernetes cluster. Every pod-to-pod call starts with a DNS resolution. If that resolution is slow or fails intermittently, the symptoms propagate upward and look exactly like application bugs or network instability.

Key insight: CoreDNS is not a background process. It is critical infrastructure that every pod in your cluster queries on every TCP connection. Treating it as a "set and forget" component is how production incidents happen.

Root causes — what actually goes wrong

There are four common failure modes. Understanding which one you're hitting before running a single command will cut your debug time in half.

The ndots:5 problem explained

The default ndots:5 setting means: if a hostname has fewer than 5 dots, try every search domain suffix before falling back to a direct lookup.

What happens when you call api.stripe.com with ndots:5

1. api.stripe.com.default.svc.cluster.local   → NXDOMAIN ❌
2. api.stripe.com.svc.cluster.local            → NXDOMAIN ❌
3. api.stripe.com.cluster.local                → NXDOMAIN ❌
4. api.stripe.com                              → 34.206.0.1 ✓

4 DNS queries instead of 1 — for every external call, from every pod, at every request. At scale with hundreds of pods, this becomes a DNS query storm.

Fix: set ndots:2

1. api.stripe.com.default.svc.cluster.local   → NXDOMAIN ❌
2. api.stripe.com                              → 34.206.0.1 ✓

Cuts DNS query volume by ~60% in large clusters. No CoreDNS restart needed.

Step-by-step: diagnosing the issue

Run these commands in order. Each one narrows down the cause before you move to the next.

Step 1 — Confirm it is a DNS problem

# Test DNS resolution directly
kubectl exec -it <pod-name> -n <namespace> -- nslookup kubernetes.default

# Test service-to-service name resolution
kubectl exec -it <pod-name> -n <namespace> -- \
  curl http://<service>.<namespace>.svc.cluster.local

# Check DNS config inside the pod
kubectl exec -it <pod-name> -n <namespace> -- cat /etc/resolv.conf

What to look for:

• Intermittent failure → DNS problem

• Consistent failure → check Service and Endpoints instead

• ndots:5 in resolv.conf → query multiplication problem (fix in Step 4)

Step 2 — Inspect CoreDNS health

# Pod status
kubectl get pods -n kube-system -l k8s-app=kube-dns

# CPU and memory usage
kubectl top pods -n kube-system -l k8s-app=kube-dns

# Logs — look for errors
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100 \
  | grep -i "SERVFAIL\|timeout\|i/o"

Red flags in logs:

• SERVFAIL → query is failing at CoreDNS

• i/o timeout → upstream resolver unreachable

• CPU near limit → throttling is the cause

• Repeated pod restarts → crash or OOM

Step-by-step: fixing the issue

Fix 1 — Remove CPU limits, scale replicas

CPU limits on CoreDNS cause throttling at peak load. Removing limits allows CoreDNS to burst freely. Scaling replicas ensures resilience if one pod restarts.

# Scale CoreDNS — target 1 replica per 10–15 nodes
kubectl scale deployment coredns --replicas=5 -n kube-system

# Edit resource config — remove the limits block
kubectl edit deployment coredns -n kube-system

Under resources:, keep requests and delete the limits block entirely:

resources:
  requests:
    cpu: 100m
    memory: 70Mi
  # Delete the limits section entirely

Fix 2 — Set ndots:2 in your pod spec

Add this to every Deployment or Pod spec where external DNS calls are made:

spec:
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: single-request-reopen
  dnsPolicy: ClusterFirst

Impact: Reduces DNS query volume by ~60% in large clusters. No CoreDNS restart needed.

Fix 3 — Deploy NodeLocal DNSCache

This is the highest-impact fix. A DaemonSet runs a DNS cache on every node — most queries are answered locally without ever reaching CoreDNS.

# Deploy NodeLocal DNSCache DaemonSet
kubectl apply -f \
  https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml

# Verify DaemonSet is running on all nodes
kubectl get daemonset nodelocaldns -n kube-system

# Should show one pod per node — DESIRED == READY

Fix 4 — Add DNS monitoring

CoreDNS exposes Prometheus metrics by default. Add these to your dashboards before you need them.

# Scrape endpoint on every CoreDNS pod
http://<coredns-pod-ip>:9153/metrics

# Alert: p99 DNS latency over 100ms
coredns_dns_request_duration_seconds{quantile="0.99"} > 0.1

# Alert: any SERVFAIL responses
coredns_dns_responses_total{rcode="SERVFAIL"} > 0

# Alert: upstream failures
coredns_forward_request_failures_total > 0

Quick cluster health check

Run this bundle right now on any cluster to get a baseline reading:

# 1. CPU usage — is CoreDNS near its limit?
kubectl top pods -n kube-system | grep coredns

# 2. Replica count — is it enough for your cluster?
kubectl get deployment coredns -n kube-system

# 3. Any errors in recent logs?
kubectl logs -n kube-system -l k8s-app=kube-dns \
  --tail=50 | grep -i "error\|fail\|timeout"

# 4. Is NodeLocal DNSCache deployed?
kubectl get daemonset nodelocaldns -n kube-system 2>/dev/null \
  || echo "Not deployed"

Summary — the complete fix checklist

The mental model that changes everything

CoreDNS is not a default add-on you configure once.

It is a critical database that every pod queries on every connection.

Right-size it. Monitor it. Scale it proactively — before it becomes a production incident.

Found this useful? Save it for your next DNS debugging session. If you've hit a DNS issue in production that's not covered here, share it in the comments — every cluster has its own flavor of chaos.

I've been on-call when a pod restart count hit 40. I've watched a node flip NotReady at 2 AM and taken down three services with it. I've spent 45 minutes debugging a "networking issue" that turned out to be a label typo on a service selector.

Kubernetes doesn't lie to you — but it doesn't exactly make things easy either. It gives you cryptic status messages, events that disappear after an hour, and logs that only exist for the container that's already dead.

This guide is what I wish I had when I started. Not a list of commands — but the reasoning behind each command, the mental model for reading what Kubernetes is actually telling you, and the exact terminal steps I use in production when something breaks.

We'll cover four of the most common — and most misdiagnosed — failures:

1. CrashLoopBackOff — your pod keeps dying and you don't know why

2. OOMKilled — Kubernetes silently murdered your container

3. Pending pods — your pod refuses to schedule and says nothing useful

4. Node NotReady — the machine underneath is sick

Before we start: the three commands you always run first

Before you do anything else in Kubernetes troubleshooting, run these three. Every time. In this order.

kubectl get pods -n <namespace>
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous

The first tells you what is wrong. The second tells you where it went wrong. The third shows you what the dead container saw before it died. Together, they answer 70% of production issues.

Now let's go deeper.

1. CrashLoopBackOff — "My pod keeps restarting and I have no idea why"

What you see

$ kubectl get pods -n production

NAME                          READY   STATUS             RESTARTS   AGE
api-deployment-7d9f8b-xk2pl   0/1     CrashLoopBackOff   23         18m

That restart count of 23 means Kubernetes has tried to start your container 23 times. Each time it crashed. Kubernetes is now applying exponential backoff — waiting longer between each restart attempt. That's the "BackOff" part of the name.

What's actually happening behind the scenes

When Kubernetes starts a container, it runs your defined command or the image's entrypoint. If that process exits with a non-zero code — for any reason — Kubernetes marks the container as failed and increments the restart counter. It doesn't know why your process exited. It just knows it did.

The critical insight: the current running container knows almost nothing. It just started. The container that holds the clues is the previous one — the one that already crashed.

The diagnostic flow

Step 1 — Read the current logs first (quick check)

$ kubectl logs api-deployment-7d9f8b-xk2pl -n production

Error: Cannot connect to database at postgres-service:5432
Connection refused

Sometimes you get lucky and the error is right here. Most times the container crashes so fast there are no current logs. Move to step 2.

Step 2 — Read the PREVIOUS container's logs (this is the real one)

$ kubectl logs api-deployment-7d9f8b-xk2pl -n production --previous

[2024-01-15 02:14:33] INFO  Starting application server...
[2024-01-15 02:14:33] INFO  Loading configuration from /etc/config/app.yaml
[2024-01-15 02:14:33] FATAL Missing required environment variable: DATABASE_URL
[2024-01-15 02:14:33] ERROR Application startup failed. Exiting.

There it is. The --previous flag tells kubectl to fetch logs from the terminated container, not the currently running one. This is the most commonly skipped step in K8s debugging.

Step 3 — Check the events section in describe

$ kubectl describe pod api-deployment-7d9f8b-xk2pl -n production

...
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Pulled     23m                kubelet            Successfully pulled image
  Normal   Created    23m                kubelet            Created container api
  Normal   Started    23m                kubelet            Started container api
  Warning  BackOff    2m (x18 over 20m)  kubelet            Back-off restarting failed container

The Events section is a timeline of everything Kubernetes did to this pod. Read it from top to bottom. The BackOff warning confirms we're in CrashLoopBackOff and shows how long it's been happening.

Step 4 — Check the last state of the container

$ kubectl get pod api-deployment-7d9f8b-xk2pl -n production -o yaml | grep -A 10 "lastState"

    lastState:
      terminated:
        containerID: docker://a3f9b2...
        exitCode: 1
        finishedAt: "2026-03-15T02:14:34Z"
        reason: Error
        startedAt: "2026-03-15T02:14:33Z"

The exitCode: 1 tells you the app exited with a general error. If you see exitCode: 137, stop — that's OOMKilled (we cover that next). If you see exitCode: 0, the app is exiting cleanly, which means your liveness probe is probably the problem, not the app itself.

Common root causes and their fixes

Missing environment variable: Add it to your deployment's env section or reference a Secret/ConfigMap.

env:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: database-url

Liveness probe killing the container before it's ready: If your app takes 30 seconds to start but your liveness probe fires after 10 seconds, Kubernetes will kill it before it's healthy. Fix this with initialDelaySeconds.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30   # give the app time to start
  periodSeconds: 10
  failureThreshold: 3

External dependency not reachable: Use an init container to wait for the dependency before your main container starts.

initContainers:
  - name: wait-for-db
    image: busybox
    command: ['sh', '-c', 'until nc -z postgres-service 5432; do echo waiting for database; sleep 2; done']

2. OOMKilled — "Kubernetes silently killed my container"

What you see

$ kubectl get pods -n production

NAME                        READY   STATUS      RESTARTS   AGE
worker-6b9c4d-p8mwz         0/1     OOMKilled   5          12m

Or sometimes it shows as CrashLoopBackOff with OOMKilled buried inside.

What's actually happening behind the scenes

OOMKilled stands for Out Of Memory Killed. When your container's memory usage exceeds the limits.memory value in its spec, the Linux kernel's OOM (Out Of Memory) killer terminates the process immediately. No warning. No graceful shutdown. No logs. It's a hard kill — exit code 137.

This is not a Kubernetes decision. Kubernetes sets the cgroup memory limit, but the kernel does the killing. That's why it's so abrupt and why your application has no chance to write a final log message.

The diagnostic flow

Step 1 — Confirm it's actually OOMKilled

$ kubectl describe pod worker-6b9c4d-p8mwz -n production

Containers:
  worker:
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Mon, 28 Mar 2026 02:10:11 +0000
      Finished:     Mon, 28 Mar 2026 02:11:43 +0000
    Limits:
      memory:  256Mi
    Requests:
      memory:  128Mi

Exit code 137 = OOMKilled. Always. If you see 137, skip the application logs — the app didn't write anything. The kernel killed it mid-execution.

Step 2 — Check how much memory it was actually using before the kill

$ kubectl top pod worker-6b9c4d-p8mwz -n production

NAME                    CPU(cores)   MEMORY(bytes)
worker-6b9c4d-p8mwz     142m         251Mi

It was using 251Mi against a limit of 256Mi — right at the edge. This tells you the limit is probably just too tight for the workload.

Step 3 — Check if it's a leak or a limit issue

Look at the restart timestamps in kubectl describe. If the pod runs for hours and then OOMKills, that's a memory leak — memory is growing slowly over time. If it OOMKills within seconds of starting, that's a limit too low — the app's baseline memory already exceeds the limit.

Step 4 — Check the cgroup memory stats directly on the node (advanced)

# SSH into the node first, then:
$ cat /sys/fs/cgroup/memory/kubepods/pod<pod-uid>/memory.usage_in_bytes
268435456  # bytes — convert to MB: 256MB (exactly at the limit)

$ cat /sys/fs/cgroup/memory/kubepods/pod<pod-uid>/memory.oom_control
oom_kill_disable 0
under_oom 0
oom_kill 1         # oom_kill: 1 confirms the kernel fired the OOM killer

Fixes that actually work in production

If the limit is genuinely too low: Increase it. But first, profile what the app actually needs under normal load.

resources:
  requests:
    memory: "256Mi"
  limits:
    memory: "512Mi"   # give 2x headroom over requests

If you want to guarantee the pod survives node memory pressure: Set requests == limits. This gives the pod "Guaranteed" QoS class — Kubernetes kills BestEffort and Burstable pods first when a node is under memory pressure. Guaranteed pods are the last to be evicted.

resources:
  requests:
    memory: "512Mi"
  limits:
    memory: "512Mi"   # requests = limits = Guaranteed QoS

If it's a memory leak: Horizontal scaling buys you time but doesn't fix the leak. Profile your application. For Python, use memory_profiler. For Java, take a heap dump. For Go, use pprof. Leaks don't fix themselves.

3. Pending Pods — "My pod is stuck and not scheduling"

What you see

$ kubectl get pods -n staging

NAME                      READY   STATUS    RESTARTS   AGE
ml-job-5f8d9c-kx7vp       0/1     Pending   0          8m

A pod that stays in Pending hasn't been scheduled to any node yet. The scheduler looked at your cluster and couldn't find a suitable place to put it.

The single most useful command for Pending pods

$ kubectl describe pod ml-job-5f8d9c-kx7vp -n staging

Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  8m    default-scheduler  0/3 nodes are available:
                                                      1 node(s) had taint {node-role: gpu} that
                                                      the pod didn't tolerate,
                                                      2 Insufficient memory.

The scheduler tells you exactly why it couldn't schedule the pod. Read this message carefully — it lists every node and why each one was rejected.

Diagnosing each failure type

"Insufficient memory" or "Insufficient CPU"

# See actual allocated resources across all nodes
$ kubectl describe nodes | grep -A 8 "Allocated resources"

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests      Limits
  --------           --------      ------
  cpu                1850m (92%)   2400m (120%)
  memory             3.2Gi (89%)   4.1Gi (114%)

92% CPU requested across the cluster. Your new pod has nowhere to go. You either need to scale the cluster or reduce the pod's resource requests.

"Node had taint that pod didn't tolerate"

# See what taints are on your nodes
$ kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

NAME        TAINTS
node-1      [map[effect:NoSchedule key:node-role value:gpu]]
node-2      <none>
node-3      <none>

A taint is a node saying "don't put pods here unless they explicitly tolerate me." Fix it by adding a toleration to your pod spec.

tolerations:
  - key: "node-role"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

"PersistentVolumeClaim not bound"

$ kubectl get pvc -n staging

NAME          STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ml-data-pvc   Pending                                      fast-ssd       9m

The PVC is also Pending. The pod can't schedule until the volume is ready.

$ kubectl describe pvc ml-data-pvc -n staging

Events:
  Warning  ProvisioningFailed  2m   persistentvolume-controller
           storageclass.storage.k8s.io "fast-ssd" not found

The StorageClass doesn't exist. Either create it or fix the typo in your PVC definition. This is one of the most common causes — a simple typo in storageClassName.

4. Node NotReady — "The machine underneath is sick"

What you see

$ kubectl get nodes

NAME        STATUS     ROLES    AGE   VERSION
node-1      Ready      worker   45d   v1.30.0
node-2      NotReady   worker   45d   v1.30.0
node-3      Ready      worker   45d   v1.30.0

A NotReady node is serious. Kubernetes will start evicting pods from it after the pod-eviction-timeout (default 5 minutes). Those pods will be rescheduled to other nodes — which may then also go under pressure.

Diagnosing NotReady step by step

Step 1 — Read the node conditions

$ kubectl describe node node-2 | grep -A 20 "Conditions:"

Conditions:
  Type                 Status  Reason                  Message
  ----                 ------  ------                  -------
  MemoryPressure       False   KubeletHasSufficientMemory  kubelet has sufficient memory
  DiskPressure         True    KubeletHasDiskPressure  kubelet has disk pressure   ← HERE
  PIDPressure          False   KubeletHasSufficientPID kubelet has sufficient PID
  Ready                False   KubeletNotReady         PLEG is not healthy

DiskPressure: True — the node is running out of disk space. That's what triggered the NotReady state. Kubernetes marks a node NotReady when kubelet can't maintain a healthy state, which disk pressure causes by preventing kubelet from writing its own state files.

Step 2 — SSH into the node and check disk

$ ssh ubuntu@node-2

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   48G  200M  99% /
/dev/sda2        20G  1.2G   18G   7% /var/lib/kubelet

$ du -sh /var/lib/containerd/*
2.1G    /var/lib/containerd/io.containerd.content.v1.content
14G     /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs

14GB of overlay snapshots — container image layers that were never cleaned up. The disk is 99% full because nobody set up image garbage collection.

Step 3 — Clean up the disk (immediate fix)

# Remove unused images (safe — only removes images not used by any container)
$ crictl rmi --prune
Deleted: sha256:a3f9b2...
Deleted: sha256:7c4d81...
Deleted: sha256:ee2f19...

# Or if using docker runtime:
$ docker system prune -f
$ docker image prune -a -f

# Check disk again
$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   31G   19G  62% /

Step 4 — Check kubelet status after cleanup

$ systemctl status kubelet

● kubelet.service - kubelet: The Kubernetes Node Agent
   Active: active (running) since Mon 2024-01-15 02:45:11 UTC; 2min ago

# If kubelet is crashed, restart it:
$ systemctl restart kubelet

# Watch it recover:
$ kubectl get nodes --watch
NAME      STATUS     ROLES    AGE   VERSION
node-2    NotReady   worker   45d   v1.28.0
node-2    Ready      worker   45d   v1.28.0   ← recovery

Preventing disk pressure permanently

Set kubelet's garbage collection thresholds in /var/lib/kubelet/config.yaml:

evictionHard:
  nodefs.available: "10%"       # evict pods when disk < 10%
  imagefs.available: "15%"      # evict when image disk < 15%
imageGCHighThresholdPercent: 85 # start GC when image disk > 85%
imageGCLowThresholdPercent: 80  # GC down to 80%

The mental model that ties all of this together

Every Kubernetes failure follows the same investigation pattern. When something breaks, your job is to answer four questions in order:

What is the symptom? — kubectl get pods or kubectl get nodes

Where did it fail? — kubectl describe pod/node — always read the Events section to the bottom

Why did it fail? — logs (--previous for crashed containers), node metrics (df -h, free -m), or resource constraints (kubectl top)

When did it start? — timestamps in Events, restart counts, and duration. A pod that's been failing for 2 minutes is different from one that's been failing for 2 hours.

Get fast at these four questions and you'll resolve 90% of production Kubernetes incidents in under 10 minutes.

What's next

If you found this useful, follow along. Every post in this series is built from real incidents, not documentation.

Sumankant Jha — Senior DevOps & SRE Engineer at HCL Technologies, Based in Delhi, India.

Connect on LinkedIn: linkedin.com/in/skjha0207 Hashnode: hashnode.com/@skj02