The cleanest way to restart a pod in minikube is kubectl rollout restart deployment/<name>, which replaces every pod in the deployment one at a time with zero downtime. If you want a faster, blunter option, kubectl delete pod <pod> works too, because the controller that owns the pod immediately creates a new one. Standalone pods with no controller are the exception: deleting them just deletes them, so you have to recreate them from their manifest.
kubectl rollout restart deployment/<name> for a graceful restart, or kubectl delete pod <pod-name> to force the controller to recreate it now. For a bare pod with no deployment, use kubectl replace --force -f pod.yaml. Confirm with kubectl get pods -w.Kubernetes has no kubectl restart pod command, which surprises people coming from Docker. Pods are meant to be disposable, so “restarting” one really means getting rid of the old pod and letting something create a fresh one. This guide covers every practical method, explains which to use when, and adds the minikube specific details (drivers, image caching, single node scheduling) that make local clusters behave a little differently from a cloud cluster. If you have not set up a cluster yet, start with our guide on how to install minikube on Ubuntu and come back.
First, find out what owns the pod
The right restart method depends on whether the pod is managed by a controller. Check with:
kubectl get pods -n default
kubectl describe pod <pod-name> | grep -A2 "Controlled By"If Controlled By shows ReplicaSet/…, the pod belongs to a Deployment. StatefulSet/… and DaemonSet/… are also controllers. If the line is missing, you have a standalone pod, and only the “replace” method further down applies.
Pod names also give it away. A deployment pod looks like web-7d4b9c6f8-x2k9p, a StatefulSet pod looks like db-0, and a bare pod carries whatever name you gave it in the manifest.
Method 1: kubectl rollout restart (the recommended way)
This is the method to use for anything running under a Deployment, StatefulSet or DaemonSet. It patches the pod template with a restart timestamp annotation, which triggers a normal rolling update: new pods come up, pass their readiness probes, and only then are old pods terminated.
kubectl rollout restart deployment/web
kubectl rollout status deployment/web
# StatefulSets and DaemonSets work the same way
kubectl rollout restart statefulset/db
kubectl rollout restart daemonset/log-agent -n kube-system
# Restart every deployment in a namespace
kubectl rollout restart deployment -n myapprollout status blocks until the new pods are ready, which makes it useful in scripts. If the rollout stalls, kubectl rollout undo deployment/web brings back the previous ReplicaSet. The kubectl rollout restart reference lists the supported resource types.
Pending. Either restart minikube with more resources (minikube start --cpus 4 --memory 8192) or use the scale method below.Method 2: delete the pod and let the controller recreate it
When you want a pod gone right now (stuck process, bad state, you just want a fresh container), delete it. The ReplicaSet notices the missing replica within a second or two and schedules a replacement.
kubectl delete pod web-7d4b9c6f8-x2k9p
# Delete every pod matching a label
kubectl delete pods -l app=web
# Skip the graceful termination period (default 30 seconds)
kubectl delete pod web-7d4b9c6f8-x2k9p --grace-period=0 --forceThe difference from a rollout restart is ordering. Deleting removes the old pod first, then a new one is created, so a single replica deployment will have a short outage. With multiple replicas, deleting one pod at a time keeps the service up.
--grace-period=0 --force tells the API server to forget the pod immediately, without waiting for the container to actually stop. For StatefulSet pods this can produce two pods with the same identity writing to the same volume. Use it only on stateless workloads.Method 3: scale to zero and back
Scaling is useful when you want every pod in a deployment to stop before any new one starts, for example to clear a shared cache, release a lock, or free resources on a small minikube VM.
kubectl scale deployment/web --replicas=0
kubectl get pods -l app=web # wait until nothing is listed
kubectl scale deployment/web --replicas=3Make a note of the original replica count before you scale down. kubectl get deployment web -o jsonpath='{.spec.replicas}' prints it. If you scale a deployment that is managed by a HorizontalPodAutoscaler, the HPA will fight you and scale it back up; pause the HPA or use a rollout restart instead.
Method 4: kubectl replace –force for standalone pods
A pod created directly from a manifest (kind: Pod) or with kubectl run has no controller. Deleting it just removes it. To restart it, you replace the object with itself:
# From the original manifest
kubectl replace --force -f pod.yaml
# Without the manifest: export the live object and feed it back
kubectl get pod mypod -o yaml | kubectl replace --force -f ---force here means “delete then create,” which is exactly a restart. The second form works but carries a caveat: the exported YAML includes a nodeName, harmless on single node minikube but able to pin the pod to a node on a real cluster. Prefer the original manifest when you have it.
If the pod’s own container keeps crashing, none of this is needed. The kubelet already restarts containers according to the pod’s restartPolicy (default Always), and the RESTARTS column in kubectl get pods counts those.
Choosing a method
| Method | Works on | Downtime | Best for |
|---|---|---|---|
kubectl rollout restart | Deployment, StatefulSet, DaemonSet | None (rolling) | Picking up new ConfigMaps, Secrets, or a re pulled image |
kubectl delete pod | Any controller managed pod | Brief, per pod | One stuck pod, fastest turnaround |
kubectl scale 0 then N | Deployment, StatefulSet, ReplicaSet | Full | All pods must stop before any start |
kubectl replace --force | Standalone pods | Full | Pods created without a controller |
Verifying the restart
Watch the pod list change in real time, then check the new pod’s age and restart count:
kubectl get pods -w
kubectl get pods -o wide
kubectl describe pod <new-pod-name>
kubectl logs <new-pod-name> --previous # logs from the crashed container, if anyA new pod name with an AGE of a few seconds confirms the replacement. If the pod is still ContainerCreating after a minute, describe shows the reason in the Events section at the bottom, usually an image pull or a volume mount. To check the service is reachable again from your host, our guides on getting the minikube IP address and accessing a minikube service from outside cover minikube service and NodePort access.
Minikube specific notes
A few minikube behaviors change how restarts play out compared to a managed cluster.
Images are cached inside the minikube node. If you rebuilt an image with the same tag and restarted the pod, you may still get the old image, because the default imagePullPolicy for a tagged image is IfNotPresent. Either load the new image explicitly or set the policy to Always:
# Build straight into minikube's container runtime
eval $(minikube docker-env)
docker build -t myapp:dev .
# Or load an image built on the host
minikube image load myapp:dev
# Then restart
kubectl rollout restart deployment/myappThe driver matters. With the Docker driver, minikube runs as a container on your host, and minikube docker-env points at the runtime inside it. With VM drivers (VirtualBox, Hyperkit, KVM), image loading goes through minikube image load, and a restart of the VM itself (minikube stop then minikube start) restarts every pod at once. The minikube documentation on pushing images describes each driver’s options.
Single node scheduling. There is only one node, so anti affinity rules that require pods on separate nodes will leave the replacement pod Pending forever. Remove the rule locally or use the scale method so the old pod is gone before the new one is scheduled.
Restarting minikube itself. If pods across many namespaces are misbehaving (DNS failures, storage provisioner errors), restart the node instead of individual pods: minikube stop && minikube start. All pods get recreated. To wipe everything and start fresh, minikube delete then minikube start. If you only want to remove one workload, see how to delete a deployment in minikube.
Diagnosing CrashLoopBackOff
A restart will not fix a pod that shows CrashLoopBackOff. That status means the container starts, exits, and the kubelet is backing off between attempts (the delay doubles up to five minutes). Restarting resets the backoff timer but not the underlying problem. Diagnose it with three commands:
kubectl logs <pod> --previous
kubectl describe pod <pod> | sed -n '/Last State/,/Ready/p'
kubectl get events --sort-by=.lastTimestamp | tail -20Common causes, in rough order of frequency: a wrong command or entrypoint, a missing environment variable or mounted secret, a port already in use inside the pod, a liveness probe that fails before the app finishes starting (raise initialDelaySeconds), and an OOM kill (Last State shows OOMKilled, so raise the memory limit or give minikube more memory). Exit code 1 usually means the app raised an error; 137 means it was killed, typically by the OOM killer; 143 means it received SIGTERM.
kubectl run debug --image=myapp:dev --command -- sleep 3600, then kubectl exec -it debug -- sh and try to start the app by hand.Troubleshooting
The pod comes back but still has the old config
ConfigMap and Secret values mounted as files update automatically after a delay, but values injected as environment variables are read only at container start. A restart picks them up. If it did not, confirm you edited the right namespace and that the deployment references the ConfigMap by the name you changed.
New pod stuck in Pending
Run kubectl describe pod and read the Events. “Insufficient cpu” or “Insufficient memory” means minikube needs more resources or the old pod must terminate first. An unbound PersistentVolumeClaim means the storage provisioner addon is off: minikube addons enable storage-provisioner.
ImagePullBackOff after restart
The node cannot fetch the image. For local images, load them with minikube image load and set imagePullPolicy: IfNotPresent or Never. For private registries, create a pull secret and reference it under imagePullSecrets in the pod spec.
kubectl delete hangs on a Terminating pod
A finalizer or an unresponsive container is blocking deletion. Wait for the grace period first. If it stays stuck, use kubectl delete pod <pod> --grace-period=0 --force, and if even that fails, patch out the finalizers with kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'.
rollout restart says “not found” for a bare pod
Rollouts operate on controllers, not pods. There is no deployment with that name. Use kubectl replace --force -f for standalone pods, or convert the manifest to a Deployment so future restarts are easier.
Frequently asked questions
Why is there no kubectl restart pod command?
Kubernetes treats pods as ephemeral units that are replaced rather than repaired. The design pushes you to manage workloads through controllers such as Deployments, which own the create and replace cycle. kubectl rollout restart was added later as the sanctioned way to trigger that cycle on demand without editing the spec.
Does restarting a pod delete its data?
Anything written to the container’s own filesystem or to an emptyDir volume is lost when the pod is replaced. Data on a PersistentVolumeClaim survives, because the claim is bound to the workload, not the pod. Check the volumes section of your manifest before restarting a database or queue.
How do I restart every pod in the cluster?
For all deployments in all namespaces: kubectl rollout restart deployment --all-namespaces is not supported directly, so loop over namespaces or run kubectl get deploy -A -o name and pipe each one to a restart. On minikube, minikube stop followed by minikube start is simpler and restarts everything.
Is deleting a pod safe in production?
For a deployment with several replicas and readiness probes, yes; that is how the scheduler works during node drains. For a single replica service it causes a short outage, and for StatefulSets it can break ordering guarantees. In production prefer rollout restart, and reserve forced deletion for pods that are genuinely stuck.
Will a restart pull a newer image with the same tag?
Only if imagePullPolicy is Always, or the tag is latest (which defaults to Always). Otherwise the node uses its cached copy. On minikube, load the new image first with minikube image load, or build inside the node with minikube docker-env, then restart.
The bottom line
For anything managed by a Deployment, StatefulSet or DaemonSet, kubectl rollout restart is the correct tool: it is graceful, it is reversible with rollout undo, and it works identically on minikube and on a production cluster. Deleting a pod is the quick alternative when one replica is misbehaving, and scaling to zero handles the cases where everything has to stop at once.
On minikube, remember the two local quirks that cause most confusion: images are cached inside the node, so a restart alone will not pick up a rebuild unless you load it or set the pull policy, and there is only one node, so resource limits and anti affinity rules can leave the replacement pod pending. Check those two things first, and most “the restart did nothing” reports solve themselves.
