Four pods, four different reasons they are not serving
After a deploy, a Deployment reports 3 of 8 replicas available. One pod is Pending, one is in CrashLoopBackOff, one is Running but not Ready, and one has restarted eleven times with the last state showing OOMKilled. The team's instinct is to delete the pods and let them reschedule.
The fix that looks right
Deleting the pods. It is the fastest action available, it is what the platform documentation implies is safe because pods are disposable, and it produces immediate visible movement — new pods appear. It also destroys the four pieces of evidence that would have identified four different causes, and every replacement lands in the same state: still Pending because the cluster is still full, still crash-looping because the config is still missing, still OOMKilled because the limit is still 128Mi. The team then repeats the deletion, and the incident becomes a loop with a person in it.