How do you troubleshoot a pod stuck in CrashLoopBackOff or Pending

Crisp answer: CrashLoopBackOff means the container keeps starting and immediately exiting — look at logs and exit codes. Pending means it was never scheduled — look at events for the reason.

CrashLoopBackOff:

# See the current state and restart count
kubectl get pod <pod>
# NAME     READY   STATUS             RESTARTS   AGE
# myapp    0/1     CrashLoopBackOff   8          4m

# Check exit code and last state
kubectl describe pod <pod>
# Last State: Terminated
#   Reason:   OOMKilled / Error / Completed
#   Exit Code: 137 (SIGKILL/OOM), 1 (application error), 0 (clean exit but no process)
#   Started:   ...
#   Finished:  ...

# Get logs from the CURRENT container
kubectl logs <pod>

# Get logs from the PREVIOUS crashed container
kubectl logs <pod> --previous

# Get logs for a specific container in a multi-container pod
kubectl logs <pod> -c <container> --previous

Common exit codes:

OOMKilled:

# If exit code 137 and reason OOMKilled:
kubectl describe pod <pod> | grep -A 5 "OOM\|Limits\|Requests"
# The container exceeded its memory limit — the kernel killed it

# Solution: increase memory limit in the pod spec:
resources:
  limits:
    memory: "512Mi"   # was 256Mi

# Or check for a memory leak in the application

Container failing to start (bad image, wrong command):

kubectl describe pod <pod>
# Events:
# Failed to pull image "myapp:latest": rpc error: ... not found
# Back-off pulling image "myapp:latest"

# exec into a running container to debug:
kubectl exec -it <pod> -- /bin/sh

# If the container keeps crashing before you can exec, use an init container
# or override the command temporarily:
kubectl run debug --image=myapp:latest --command -- sleep infinity
kubectl exec -it debug -- /bin/sh

Pending pod:

kubectl describe pod <pod>
# Events section will show the scheduling failure:
# "0/3 nodes are available: 3 Insufficient memory"
# "0/3 nodes are available: 1 node(s) had taint..."
# "0/3 nodes are available: 3 node(s) didn't match Pod's node affinity/selector"
# "persistentvolumeclaim not found" or "volume is already exclusively attached"

# Check node resources:
kubectl describe nodes | grep -A 6 "Allocated resources"

# Check if a PVC is bound:
kubectl get pvc

ImagePullBackOff:

# Authentication issue pulling from private registry:
kubectl describe pod <pod>
# Failed to pull image: unauthorized: authentication required

# Fix: create a pull secret and reference it in the pod:
kubectl create secret docker-registry regcred \
  --docker-server=harbor.joysontech.com \
  --docker-username=robot \
  --docker-password=<token>

# In pod spec:
spec:
  imagePullSecrets:
  - name: regcred

What to say in the interview:

"CrashLoopBackOff: check kubectl logs --previous for the last crash message, and kubectl describe pod for the exit code. 137 means OOMKilled — raise the memory limit. Exit code 1 means the app errored — the logs tell you why. For Pending: the Events section in describe pod shows exactly why the scheduler rejected every node. Usually it's insufficient resources, a taint mismatch, or a PVC that can't bind. I go to events first before touching anything else — Kubernetes tells you what's wrong in plain English."