CrashLoopBackOff After a Config Change
The report, in their words
A service was redeployed at 11:20 and none of its pods stay up: 0/1 Ready, status CrashLoopBackOff, restart count climbing. The image is byte-for-byte the one that has been running since yesterday. The only thing in the merge was a ConfigMap update.
Pull evidence
One item at a time, and nothing here tells you which one matters. Deciding what is worth looking at is most of the diagnosis.
kubectl describe pod — container state and events
kubectl logs --previous
The ConfigMap diff in the merge
How the Deployment consumes the ConfigMap
Liveness and readiness probes
Was it out of memory?
Image identity
Node conditions
The Secret mounted alongside
0 of 9 inspected. You are not required to open all of them — a real investigation is judged on how few you needed.
What is your diagnosis?
Commit to one. Nothing below is shown until you do.
Guessing wrong and being told exactly why is the point of this page. Reading the answer first is not practice.