10/08/2026
🔥 DAY 60 — KUBERNETES TROUBLESHOOTING MASTERCLASS
🚨 YOUR POD IS RUNNING.
YOUR SERVICE EXISTS.
YOUR INGRESS EXISTS.
BUT YOUR APPLICATION IS STILL DOWN.
After 60 days of Kubernetes, there's one skill that separates someone who knows Kubernetes commands from someone who can actually operate Kubernetes in production:
🧠 TROUBLESHOOTING.
When production breaks, don't randomly restart Pods.
Don't delete Deployments.
Don't blame Kubernetes.
TRACE THE TRAFFIC. TRACE THE FAILURE. FIX THE FIRST BROKEN LAYER.
🏆 DAY 60/60 — THE KUBERNETES TROUBLESHOOTING PLAYBOOK
Save this.
This is your Kubernetes incident-response cheat sheet.
🔥 THE GOLDEN RULE
When something doesn't work:
DON'T GUESS.
↓
OBSERVE.
↓
IDENTIFY THE BROKEN LAYER.
↓
FIX IT.
↓
VERIFY.
🧠 THE 10-LAYER KUBERNETES DEBUGGING MODEL
When an application fails, walk through these layers:
1. NODE
↓
2. POD
↓
3. CONTAINER
↓
4. APPLICATION
↓
5. SERVICE
↓
6. ENDPOINTS / ENDPOINTSLICE
↓
7. NETWORKPOLICY
↓
8. INGRESS
↓
9. DNS
↓
10. EXTERNAL NETWORK
🔥 Don't jump to Layer 10 when Layer 5 is broken.
1️⃣ IS THE NODE HEALTHY?
Start here:
kubectl get nodes
You want:
STATUS
Ready
Then:
kubectl describe node
Look for:
Conditions
Taints
Capacity
Allocatable
Events
Check:
kubectl top nodes
Potential problems:
NotReady
MemoryPressure
DiskPressure
PIDPressure
NetworkUnavailable
2️⃣ IS THE POD HEALTHY?
kubectl get pods -A
Don't stop at:
STATUS = Running
Check:
READY
STATUS
RESTARTS
AGE
Example:
NAME READY STATUS RESTARTS
api-### 0/1 Running 15
🚨 Running does NOT necessarily mean healthy.
3️⃣ DESCRIBE THE POD
When something looks suspicious:
kubectl describe pod
Pay special attention to:
Events
State
Last State
Reason
Conditions
Mounts
Volumes
Node
Events often tell you exactly what Kubernetes is unhappy about.
4️⃣ CHECK THE CONTAINER
Application crashing?
kubectl logs
Previous container crashed?
kubectl logs --previous
Multiple containers?
kubectl logs -c
Interactive debugging:
kubectl exec -it -- sh
🔥 If the image doesn't contain debugging tools:
kubectl debug
Use an ephemeral debugging container instead of modifying the production image.
5️⃣ CHECK THE APPLICATION
Kubernetes can say:
Pod: Running
Container: Running
while your application is completely broken.
Check:
Application logs
Environment variables
ConfigMap
Secret
Ports
Dependencies
Health endpoints
For example:
kubectl exec -it -- curl localhost:8080/health
The application must actually be listening.
6️⃣ CHECK THE SERVICE
Application works inside the Pod but users can't reach it?
kubectl get svc
Then:
kubectl describe svc
Check:
Selector
Port
TargetPort
Type
🔥 Compare:
SERVICE SELECTOR
↓
POD LABELS
Example:
Service:
app=api
Pod:
app=backend
❌ No match.
7️⃣ CHECK ENDPOINTS
This is one of the fastest Kubernetes troubleshooting tricks.
kubectl get endpoints
Or modern:
kubectl get endpointslice
If you see:
investigate:
Selector mismatch
Pod readiness
Wrong namespace
Pod not selected
Mental model:
Service
↓
Selector
↓
Pod Labels
↓
EndpointSlice
↓
Pod IP
8️⃣ CHECK NETWORKPOLICY
Pods exist.
Service exists.
Endpoints exist.
But:
curl
fails.
Now investigate NetworkPolicy.
kubectl get networkpolicy -A
Ask:
WHO can talk to this Pod?
WHO can this Pod talk to?
Is ingress allowed?
Is egress allowed?
Is DNS allowed?
🔥 Remember:
RBAC
↓
Kubernetes API access
NetworkPolicy
↓
Network traffic
9️⃣ CHECK INGRESS
External users receive:
404
502
503
504
Check:
kubectl get ingress
Then:
kubectl describe ingress
Verify:
IngressClass
Host
Path
Backend Service
Service Port
Endpoints
TLS
Traffic path:
Internet
↓
DNS
↓
Ingress Controller
↓
Ingress Rule
↓
Service
↓
EndpointSlice
↓
Pod
🔥 Find the first broken link.
🔟 CHECK DNS
DNS problem?
Inside a Pod:
nslookup
or:
getent hosts
Check:
kubectl get svc -n kube-system
And inspect CoreDNS:
kubectl get pods -n kube-system
Logs:
kubectl logs -n kube-system -l k8s-app=kube-dns
🚨 THE 404 / 503 / 504 CHEAT SHEET
404
Think:
Wrong host
Wrong path
Ingress rule
Application route
503
Think:
Service
Endpoints
Readiness
Ingress backend
No healthy backend
504
Think:
Timeout
Network
Application response
Upstream connectivity
🔥 Don't treat every HTTP error as a Pod problem.
🧠 COMMON KUBERNETES INCIDENTS
❌ Pod stuck Pending
Check:
kubectl describe pod
Investigate:
Insufficient CPU
Insufficient memory
Taints
Node affinity
Pod affinity
ResourceQuota
PVC
Node availability
❌ CrashLoopBackOff
Run:
kubectl logs
kubectl logs --previous
kubectl describe pod
Look for:
Application crash
Bad configuration
Missing Secret
Missing ConfigMap
Wrong command
Permission problem
OOMKilled
❌ ImagePullBackOff
Check:
kubectl describe pod
Look for:
Wrong image name
Wrong tag
Registry authentication
ImagePullSecret
Network access
❌ Service has no endpoints
Check:
Selector
Labels
Readiness
Namespace
EndpointSlice
❌ Ingress returns 404
Check:
Host
Path
PathType
IngressClass
Controller
Service
❌ DNS doesn't work
Check:
CoreDNS
NetworkPolicy
DNS Service
Pod configuration
Cluster DNS
🏆 THE COMMANDS YOU SHOULD KNOW BY HEART
kubectl get pods -A
kubectl describe pod
kubectl logs
kubectl logs --previous
kubectl exec -it -- sh
kubectl get svc
kubectl describe svc
kubectl get endpoints
kubectl get endpointslice
kubectl get networkpolicy -A
kubectl get ingress
kubectl describe ingress
kubectl get events --sort-by=.lastTimestamp
🔥 If you remember only one:
kubectl get events --sort-by=.lastTimestamp
Events can reveal what changed and what Kubernetes is currently complaining about.
🧩 THE PRODUCTION DEBUGGING FLOW
When someone says:
"THE APPLICATION IS DOWN!"
Don't panic.
Run:
APPLICATION DOWN
│
▼
NODE HEALTHY?
/ \
NO YES
│ │
FIX NODE POD HEALTHY?
/ \
NO YES
│ │
DEBUG POD SERVICE?
/ \
NO YES
│ │
FIX SVC ENDPOINTS?
/ \
NO YES
│ │
FIX SELECTOR NETWORKPOLICY?
/ \
YES NO
│ │
FIX INGRESS?
│
DNS?
│
EXTERNAL NETWORK
🔥 Follow the traffic path.
🚨 5 KUBERNETES MISTAKES THAT WASTE HOURS
❌ 1. Restarting everything
Instead:
Observe → isolate → fix
❌ 2. Assuming Running = Healthy
Check:
READY
RESTARTS
PROBES
LOGS
EVENTS
❌ 3. Ignoring labels
Services, selectors, affinity and many Kubernetes mechanisms depend heavily on labels.
❌ 4. Forgetting namespaces
Always verify:
kubectl get pods -A
❌ 5. Debugging from the outside only
Test from inside the cluster too:
kubectl exec -it -- sh
Then test:
DNS
Service
Port
Application
🧠 THE ULTIMATE KUBERNETES MENTAL MODEL
Remember this:
USER
│
▼
DNS
│
▼
INGRESS
│
▼
SERVICE
│
▼
ENDPOINTSLICE
│
▼
POD
│
▼
CONTAINER
│
▼
APPLICATION
And around the entire system:
┌──────────────────────────┐
│ NETWORKPOLICY │
│ Who can talk to whom? │
└──────────────────────────┘
┌──────────────────────────┐
│ RBAC │
│ Who can use the API? │
└──────────────────────────┘
┌──────────────────────────┐
│ OBSERVABILITY │
│ Logs / Metrics / Events │
└──────────────────────────┘
🏆 60 DAYS COMPLETE
Over these 60 days, you've covered the Kubernetes skills that repeatedly appear in real production environments:
🔥 Pods & workloads
🔥 Deployments
🔥 ReplicaSets
🔥 Rolling updates
🔥 Rollbacks
🔥 ConfigMaps & Secrets
🔥 Probes
🔥 Jobs & CronJobs
🔥 Init Containers
🔥 Scheduling
🔥 Taints & Tolerations
🔥 Node & Pod Affinity
🔥 Resource management
🔥 SecurityContext
🔥 RBAC
🔥 Pod Security Admission
🔥 Ephemeral Containers
🔥 Audit Logging
🔥 NetworkPolicy
🔥 Services
🔥 EndpointSlices
🔥 Ingress
🔥 Troubleshooting
But the biggest lesson is:
KUBERNETES IS NOT ABOUT MEMORIZING COMMANDS.
It's about understanding:
WHAT
↓
IS BROKEN?
WHERE
↓
IS IT BROKEN?
WHY
↓
IS IT BROKEN?
HOW
↓
DO I VERIFY THE FIX?
🎯 FINAL DAY 60 CKA CHALLENGE
Production is reporting:
"The website is down."
You discover:
Nodes → Ready
Pods → Running
Services → Running
Endpoints → Present
Ingress → Present
But users receive:
HTTP 503
You discover the Ingress Controller is healthy.
What should you investigate next?
A. Delete the Pods
B. Check Service → Endpoint connectivity and readiness
C. Restart kubelet on every node
D. Recreate the entire cluster
👇 DROP YOUR ANSWER: A, B, C, OR D.
🚀 READY FOR CKA?
You've spent 60 days learning Kubernetes concepts.
Now turn that knowledge into a certification.
🚀 Linux Foundation Certifications – 30% OFF
💥 Get 30% OFF Linux Foundation Courses & Certifications
COUPON CODE: CLOUDGURU
Get the Certified Kubernetes Administrator (CKA): https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/?source=aw&sv1=affiliate&sv_campaign_id=2797056&awc=85919_1773067536_a1f91345cf951dbbbecaad9281bf8434
🎉 DAY 60/60 COMPLETE
🔥 SAVE THIS — YOUR KUBERNETES TROUBLESHOOTING CHEAT SHEET
🔥 SHARE WITH EVERY DEVOPS ENGINEER
🔥 FOLLOW CLOUD GURU
KUBERNETES • DEVOPS • AWS • CLOUD • CKA • LINUX • CAREER
🚀 60 DAYS. 60 KUBERNETES LESSONS. ONE GOAL: MASTER KUBERNETES.
