Rakesh's Brain

CKA Day 37 — Application Failure Troubleshooting

6 min read

CKA Day 37 — Application Failure Troubleshooting

Day 37 of the 40-day Certified Kubernetes Administrator course by Tech Tutorials with Piyush. This session dives into application-level failures — the most common and most tested category in the Troubleshooting domain (~30% of the CKA exam).

Key Concepts Covered

The Application Failure Debugging Chain

Day 37 formalizes a systematic approach to diagnosing why an application is failing in Kubernetes. The video emphasizes that random guessing wastes exam time; instead, follow a structured chain:

kubectl get pods -o wide          ← Check status, restarts, node
kubectl describe pod <name>         ← Read Events (the most important section)
kubectl logs <name> --previous      ← Check crash output
kubectl logs <name> -c <container>  ← Multi-container target
kubectl exec -it <name> -- sh     ← Interactive debugging inside the Pod
kubectl get events --sort-by='.lastTimestamp'  ← Cluster-level event stream

CKA Insight: kubectl describe pod Events are ordered chronologically and often contain the exact error message. Most application failures are solved by reading Events carefully.

Common Application Failure Patterns

The video catalogs the failure modes that appear repeatedly on the CKA exam:

SymptomLikely CauseWhere to Look
ImagePullBackOffWrong image name, missing tag, or private registry without imagePullSecretskubectl describe pod → Events
CrashLoopBackOffApp crashes on start; bad command/args, missing env, or liveness probe too aggressivekubectl logs --previous, then kubectl describe
Error / Init:ErrorInit container exits non-zerokubectl logs <pod> -c <init-container>
Pod stuck PendingInsufficient resources, taint mismatch, or missing PVCkubectl describe pod → Events
OOMKilledMemory limit exceededkubectl describe pod → Last State, kubectl top pod
ContainerCannotRunVolume mount path wrong, or ConfigMap/Secret missingkubectl describe pod → Events
Service 502/timeoutReadiness probe failing, or backend Pods not readykubectl get endpoints, kubectl describe pod
Rolling update stuckNew Pods never become readykubectl rollout status deployment/<name>

Image Pull Failures (ImagePullBackOff)

When Kubernetes cannot pull the container image, the Pod enters ImagePullBackOff. The kubelet retries with exponential backoff. Causes:

  • Typo in image name or tag — most common; verify with kubectl get pod <name> -o yaml | grep image:
  • Private registry without credentials — the Pod’s ServiceAccount needs imagePullSecrets referencing a kubernetes.io/dockerconfigjson Secret
  • Registry is down or unreachable — network or DNS issue

Fix speed pattern: kubectl set image deployment/<name> <container>=<correct-image>:<tag>

Crash Loops (CrashLoopBackOff)

A container that repeatedly crashes and restarts is the hallmark of CrashLoopBackOff. The restart count climbs in kubectl get pod:

  • Missing environment variables — app expects DATABASE_URL but none is defined
  • Bad startup command or args — command/args override in the Pod spec conflicts with the image’s ENTRYPOINT
  • Missing ConfigMap or Secret — volume mount references a non-existent object
  • Liveness probe too aggressive — container killed before it finishes initializing
  • Resource limit too low — container OOMKilled immediately on startup

Service Connectivity Failures

Even when Pods are Running, traffic may not reach them. The video covers the Service-to-Pod routing chain:

  1. Check the Service selector — kubectl get svc <name> -o yaml | grep selector must match Pod labels
  2. Check Endpoints — kubectl get endpoints <svc> shows which Pod IPs are registered
  3. Check readiness — only ready Pods appear in Endpoints; kubectl describe pod for readiness probe status
  4. Check port mapping — port (Service) → targetPort (container) must be correct
  5. Check NetworkPolicy — if policies exist, ensure the Service’s Pods are allowed ingress from the client

Deployment and Rollout Failures

A Deployment rollout can stall when new Pods fail to become ready:

  • MaxUnavailable / MaxSurge — if maxUnavailable is 0 and new Pods can’t start, the rollout hangs
  • Readiness probe never passes — new Pods stay NotReady, so old Pods are never terminated
  • Resource quota exhausted — Namespace ResourceQuota blocks new Pod creation

Commands to diagnose:

kubectl rollout status deployment/<name>
kubectl rollout history deployment/<name>
kubectl rollout undo deployment/<name>  # Roll back to previous revision

Events as the Source of Truth

kubectl get events provides a cluster-wide chronological stream of everything that happened. This is invaluable when:

  • The Pod was deleted and recreated by a controller — events show the controller action
  • A node went NotReady and evicted Pods — events show the eviction reason
  • A volume failed to mount — events show the mount error from kubelet
# All events sorted by time
kubectl get events --sort-by='.lastTimestamp'
 
# Events for a specific object
kubectl get events --field-selector involvedObject.name=<pod-name>
 
# Warning events only (the failures)
kubectl get events --field-selector type=Warning

Synthesis

Day 37 is the practical culmination of the Troubleshooting domain. It takes the individual tools taught across the course — kubectl get, describe, logs, exec, top, rollout commands — and teaches how to combine them into a systematic debugging workflow. The video emphasizes that the CKA exam does not test esoteric failures; it tests the ability to methodically inspect the obvious: wrong image names, missing env vars, bad selectors, crashed containers, and readiness probe failures.

The golden rule for the exam: Events first. Before diving into logs or exec-ing into containers, read kubectl describe Events. They contain the human-readable explanation of why Kubernetes is failing to run the workload.

See Also

Wiki Concepts

Creator / Entity

Graph View

Latest Blog Posts

  • Loading posts...
Read more on Medium →

Backlinks