Why does a deleted Kubernetes Pod come back with the same crash?

You delete a crashing Pod, and seconds later a new one appears with a different name. It crashes too. Pod abc12 is gone, but xk4p2 is already in CrashLoopBackOff. Something owns these Pods, and it recreated the Pod the moment you removed it.

Your Deployment, checkout, doesn't run Pods directly. It owns a ReplicaSet, and that ReplicaSet has one job: keep exactly three Pods alive. Those Pods, like abc12, are disposable instances. The ReplicaSet manages them, and it can replace any of them whenever the count drops.

You run kubectl delete pod, and the API Server removes it. Now the ReplicaSet controller sees two Pods against a desired three. It asks the API Server to create a new one from the template, and the Kubelet starts it. Then the container crashes again, within seconds.

Look at the Pod template. It pins the image shop/checkout:1.4, sets DB_HOST to db-old, and caps memory at 256Mi. Every replacement Pod is stamped from this. So if db-old is unreachable, each new Pod inherits that same failure and exits on startup.

Deleting abc12 removed one copy. It didn't touch the template. So the Pod Template stamps out xk4p2, with the same settings, and it exits with code 1 just like the first one.

Deleting a Pod erases one copy; the template prints another.

Kubernetes has two separate recoveries. When a container crashes, the kubelet restarts it inside the same Pod, so the name stays and RESTARTS climbs with growing backoff. When you delete the Pod, the ReplicaSet creates a new one, with a new name and a zero count. Both reuse the same spec.

All three checkout Pods crash with exit code one on three different nodes. Will deleting them fix it?

No, replacements use the same broken template. Every replacement is stamped from the same Pod template, with the same image and the same DB_HOST value. Crashes across different nodes point to the spec or a dependency, not one bad instance. Deleting all three just makes the ReplicaSet create three new copies of the same bug.

Deleting a Pod helps when the fault belongs to that instance, like a bad node or stuck state. It won't help when the cause is in the template, or outside it, like db-old being unreachable.

Look at the NODE column. All three Pods are crashing, on node-a, node-b, and node-c. Different machines, same failure, so the cause is spec-wide. One bad Pod on one node would point at the instance. Describe adds the detail: exit code 1, then back-off restarting.

Real fixes go upstream. Edit DB_HOST in the Deployment spec, or use rollout undo to return to a working revision. Either way, the Deployment rolls out new Pods from a better template. Scaling only changes how many copies run. And if the database is the problem, fix that.

Deleting a Pod erases one copy; the template prints another. So before you delete anything, run kubectl get pods -o wide. If every Pod crashes the same way, the cause lives in the spec, so change the template, not the copy.