For apply new configuration the new pod should be created (the old one will be removed).

• If your pod was created automatically by Deployment or DaemonSet resource, this action will run automaticaly each time after you update resource's yaml. It is not going to happen if your resource have spec.updateStrategy.type=OnDelete.

• If problem was connected with error inside docker image, that you solved, you should update pods manually, you can use rolling-update feature for this purpose, In case when new image have same tag, you can just remove broken pod. (see below)

• In case of node failure, the pod will recreated on new node after few time, the old pod will be removed after full recovery of broken node. worth noting it is not going to happen if your pod was created by DaemonSet or StatefulSet.

Any way you can manual remove crashed pod:

kubectl delete pod <pod_name>

Or all pods with CrashLoopBackOff state:

kubectl delete pod `kubectl get pods | awk '$3 == "CrashLoopBackOff" {print $1}'`

If you have completely dead node you can add --grace-period=0 --force options for remove just information about this pod from kubernetes.

Generally a fix requires you to change something about the configuration of the pod (the docker image, an environment variable, a command line flag, etc), in which case you should remove the old pod and start a new pod. If your pod is running under a replication controller (which it should be), then you can do a rolling update to the new version.

When destroying the pods with

$ kubectl get pods | awk '$3 == "CrashLoopBackOff" {print $1}'

the pods would attempt to restart. You can destroy the cluster containing the pods on google with

$ gcloud container clusters delete <pod name> --zone "<your zone>"