Does kubectl rollout restart cause downtime?

Not if you have more than one replica and working readiness probes: old pods are only removed after replacements report ready. With a single replica there is a brief gap unless the deployment strategy is set to spin the new pod up first (maxUnavailable: 0, maxSurge: 1).

Why is there no kubectl restart command?

Because in Kubernetes pods are disposable, not restartable units: the declarative model replaces pods rather than restarting them in place. rollout restart expresses exactly that: it changes the pod template so controllers replace every pod through the normal update machinery.

Does restarting a pod pull a new image?

Only if the image reference changed or imagePullPolicy is Always (the default for the :latest tag). With IfNotPresent and an unchanged tag, the cached image is reused: restarting does not fetch new code that was pushed to the same tag on a node that already has it.

How do I restart just one container inside a multi-container pod?

You cannot restart a single container via kubectl: the unit of replacement is the pod. If the container's main process exits, the kubelet restarts that container in place, so kubectl exec -c -- kill 1 works as a rough hack, but deleting the pod is the supported route.

Will pods restart automatically after I update a ConfigMap?

No. Mounted ConfigMap files update in place (with delay) but env vars from ConfigMaps never refresh, and most apps read config once at boot. Run kubectl rollout restart after config changes, or hash the config into pod annotations so changes trigger rollouts automatically.

How-to

How to Restart a Pod with kubectl (the Right Way)

Updated July 27, 2026

In short

There is no kubectl restart command. The right way to restart pods is kubectl rollout restart deployment/<name>: a rolling replacement with zero downtime that works on Deployments, StatefulSets, and DaemonSets. For a single misbehaving pod, kubectl delete pod <pod-name> lets the controller recreate it. Scaling to 0 and back up also works but takes everything down. Bare pods without a controller cannot be restarted: they must be recreated from their manifest.

start here

kubectl rollout restart deployment/<deployment-name>

Step 1

Step 1: rolling restart (the default choice)

kubectl rollout restart patches the pod template with a kubectl.kubernetes.io/restartedAt annotation, which triggers a normal rolling update: new pods come up, pass readiness, and only then are old pods terminated. Traffic never drops as long as you run more than one replica. It works on deployments, statefulsets, and daemonsets.

kubectl rollout restart deployment/<name> -n <namespace>
kubectl rollout status deployment/<name> -n <namespace>

# every deployment in a namespace:
kubectl rollout restart deployment -n <namespace>

Step 2

Step 2: delete a single pod

When one replica is wedged and the rest are fine, delete just that pod. The controller notices the missing replica and recreates it immediately, usually on the same or another node, with a fresh container and a reset CrashLoopBackOff timer. This is the surgical option; it briefly reduces capacity by one replica.

kubectl delete pod <pod-name> -n <namespace>
# watch the replacement come up:
kubectl get pods -n <namespace> -w

Step 3

Step 3: scale down and up

Scaling to zero terminates every pod, then scaling back up starts them fresh. Unlike rollout restart this causes a full outage for the service, which is occasionally the point: clearing all in-memory state at once, breaking a distributed deadlock, or bouncing a singleton that must never run two instances concurrently.

kubectl scale deployment/<name> --replicas=0 -n <namespace>
kubectl scale deployment/<name> --replicas=3 -n <namespace>

Step 4

Step 4: bare pods (no controller)

A pod created directly (kubectl run without a controller, or a raw Pod manifest) has nothing watching it: delete it and it stays gone. The only restart is recreation from the manifest. kubectl replace --force does the delete-and-recreate in one step.

kubectl replace --force -f pod.yaml
# equivalent to:
kubectl delete pod <pod-name> && kubectl apply -f pod.yaml

Choosing the right method

Rolling restart: config/secret changes to pick up, memory bloat, "turn it off and on again" for a whole service without downtime. Delete pod: one bad replica, forcing a reschedule off a bad node, resetting backoff after a fix. Scale down/up: singleton services, wiping all state at once, or emergencies where downtime is acceptable. In every case, verify with rollout status and kubectl get pods rather than assuming.

Beyond the one-off fix

rollout restart is the most common remediation command there is, which makes it the first thing AI agents reach for when they operate infrastructure. That is fine until an agent restarts the wrong deployment in prod to "fix" a symptom. Nexus governs agent-issued kubectl the way RBAC governs humans, but at the action level: policies can require approval for restarts in protected namespaces, and every restart an agent performs lands in the audit trail with the reasoning that led to it.

Explore Swfte Nexus

Common questions

Does kubectl rollout restart cause downtime?: Not if you have more than one replica and working readiness probes: old pods are only removed after replacements report ready. With a single replica there is a brief gap unless the deployment strategy is set to spin the new pod up first (maxUnavailable: 0, maxSurge: 1).
Why is there no kubectl restart command?: Because in Kubernetes pods are disposable, not restartable units: the declarative model replaces pods rather than restarting them in place. rollout restart expresses exactly that: it changes the pod template so controllers replace every pod through the normal update machinery.
Does restarting a pod pull a new image?: Only if the image reference changed or imagePullPolicy is Always (the default for the :latest tag). With IfNotPresent and an unchanged tag, the cached image is reused: restarting does not fetch new code that was pushed to the same tag on a node that already has it.
How do I restart just one container inside a multi-container pod?: You cannot restart a single container via kubectl: the unit of replacement is the pod. If the container's main process exits, the kubelet restarts that container in place, so kubectl exec <pod> -c <container> -- kill 1 works as a rough hack, but deleting the pod is the supported route.
Will pods restart automatically after I update a ConfigMap?: No. Mounted ConfigMap files update in place (with delay) but env vars from ConfigMaps never refresh, and most apps read config once at boot. Run kubectl rollout restart after config changes, or hash the config into pod annotations so changes trigger rollouts automatically.