Visit Website →
← Back to blog

How to Restart Pods in Kubernetes: Safe Methods and Commands

October 19, 2026
How to Restart Pods in Kubernetes: Safe Methods and Commands

Kubernetes has no kubectl restart pod command. A pod is meant to be replaced, not rebooted. To restart pods that belong to a Deployment, StatefulSet or DaemonSet, run kubectl rollout restart deployment/<name> (swap in statefulset/ or daemonset/ as needed). The controller then replaces the pods one by one. To restart a single misbehaving pod, delete it and let its controller create a fresh one.

This guide covers each method, when it is the right one, what can go wrong in production, and how to find out why a pod restarted in the first place.

Kubezilla Desktop
Manage Kubernetes Restarts With Clarity
Use Kubezilla Desktop to manage cluster resources in real time, with live logs and metrics available in a unified interface.
Explore Kubezilla Desktop

TL;DR

  • Use kubectl rollout restart for anything managed by a Deployment, StatefulSet or DaemonSet. It replaces pods gradually and respects your rollout limits.
  • Deleting a single pod is fine for one stuck replica. Deleting dozens at once can bypass those limits and cause an outage.
  • A bare pod with no controller will not come back after deletion. Recreate it from its manifest.
  • Before restarting to "fix" something, read kubectl describe pod and kubectl logs --previous. A restart that hides an OOMKill only postpones it.
  • Always confirm with kubectl rollout status that the new pods are ready.

Table of Contents

Why Kubernetes has no "restart pod" command

A pod is the smallest deployable unit, and it is designed to run until something replaces it. As one widely read walkthrough puts it, there is no way to restart a pod in place. You replace it.

That matters because two different things get called "restart":

  • Container restart. The kubelet restarts a container inside the same pod when it exits, according to the pod's restart policy (Always, OnFailure or Never). The pod object, its IP and its volumes' pod-level identity stay put. The Kubernetes pod lifecycle documentation describes this behavior.
  • Pod replacement. A controller, usually a Deployment, creates a brand-new pod object and removes the old one. New name, new IP, fresh filesystem, and a fresh read of any ConfigMap or Secret exposed as environment variables.

Changing a container's restart policy will not help when what you need is a new pod environment or a configuration update. You need replacement, and the methods below all produce it in different ways.

Method 1: kubectl rollout restart

This is the method most engineers should reach for first. The official kubectl reference lists these examples:

# Restart a deployment
kubectl rollout restart deployment/nginx

# Restart a daemon set
kubectl rollout restart daemonset/abc

# Restart all deployments in a namespace
kubectl rollout restart deployment -n test-namespace

# Restart deployments with a label
kubectl rollout restart deployment --selector=app=nginx

The command works by patching the pod template with a new annotation. Because the template changed, the controller treats it as a normal rolling update and replaces pods gracefully. Your manifests in Git are untouched, which is why this is the cleanest way to force a restart without a real change.

Watch the rollout finish

Do not assume the command's return means success. It only means the restart was requested. Follow it:

kubectl rollout status deployment/nginx -n production

This blocks until the rollout completes or fails. If new pods never become ready, you can roll back with kubectl rollout undo deployment/nginx. We go deeper on verification and the bulk-restart mistakes teams make in our guide to restarting a Kubernetes deployment.

What controls how fast pods are replaced

A Deployment's rolling strategy is governed by maxUnavailable and maxSurge. According to the Deployment documentation, both default to 25%. With 8 replicas, that means at most 2 pods can be unavailable and at most 2 extra pods can be created during the restart.

Eight replicas with rolling update limits

If your service is sensitive to capacity, tune these before a restart, not during an incident. A common conservative choice for small replica counts is maxUnavailable: 0 with maxSurge: 1, so a replacement is ready before any old pod goes away. That needs spare capacity on the nodes, so check it first.

Restarting every deployment in a namespace

The command with -n shown above is the simplest route. Some engineers prefer an explicit loop so they can pace it and verify each step. The pattern, as discussed on Stack Overflow, looks like this:

kubectl get deployments -n production -o name \
  | xargs -n 1 kubectl rollout restart -n production

The weakness is that it fires all restarts at once. For a large namespace, run them one at a time and wait on kubectl rollout status between each, starting with the least critical services.

Method 2: Delete the pod

Deleting a pod does not reboot it. It triggers the owning controller to create a replacement immediately, as the walkthrough linked above explains. That makes it a good tool for one replica that is behaving strangely:

kubectl delete pod api-7d9c8b6f5-x2k4m -n production

You can also delete by label:

kubectl delete pod -l app=api -n production

Be careful with that second form. A label selector can match every replica at once, and deletion does not follow maxUnavailable. The Deployment controller will recreate all of them, but for a short window you may have no ready pods. Our research notes flag this as the main reason experienced admins avoid mass deletes in production. If you need to cycle many pods, use a rollout restart.

Does deleting a pod restart it?

In practice, yes, if a controller owns it. If the pod is a bare pod created with kubectl run or a standalone manifest, nothing will recreate it. Save its YAML first (kubectl get pod <name> -o yaml), delete it, and re-apply. Strip the runtime fields such as status and nodeName before you re-apply, or let kubectl apply of your original manifest do the work.

Graceful shutdown and the grace period

When a pod is deleted, the kubelet runs its shutdown sequence. By default the pod has 30 seconds (terminationGracePeriodSeconds) to exit. Kubernetes sends SIGTERM to the main process. If you defined a preStop hook, it runs first and must finish before SIGTERM is sent. If the hook and the shutdown together exceed the grace period, the container is killed with SIGKILL. This is described in the container lifecycle hooks documentation.

Two practical consequences:

  1. A preStop hook that hangs eats into your shutdown time. If it blocks for the full 30 seconds, your app never gets a clean SIGTERM window.
  2. If your app needs longer to drain connections or flush data, raise the grace period in the pod spec, or override it for one deletion:
kubectl delete pod api-7d9c8b6f5-x2k4m --grace-period=60

For StatefulSet pods, avoid forcing deletion with a grace period of 0. The Kubernetes docs on force deleting StatefulSet pods call that practice unsafe and strongly discouraged, because it asserts the old pod will never contact its peers again.

Method 3: Scale down and back up

Scaling to zero and back is the blunt option:

kubectl scale deployment/api --replicas=0 -n production
kubectl scale deployment/api --replicas=3 -n production

This guarantees a clean slate, but it takes the service fully offline between the two commands. Use it only in a dev or staging namespace, or when you truly need every pod gone before any new one starts, for example a schema migration that cannot tolerate two versions running. If you do it often, our walkthrough of scaling a Kubernetes deployment covers the commands and the traps.

Which method should you use?

SituationBest methodDowntime risk
Config or Secret changed, app must reload itkubectl rollout restartLow, rolling
One replica is stuck or erraticDelete that podLow, one replica
Restart everything in a namespaceRollout restart, one deployment at a timeLow if paced
Bare pod, no controllerDelete and re-apply the manifestFull for that pod
Need all old pods gone firstScale to 0, then upFull outage
Node-level agent (DaemonSet)rollout restart daemonset/<name>Depends on update strategy

Find out why the pod restarted before you force another one

A restart is often a symptom. Before you cycle pods to "fix" a problem, find out what happened. The Kubernetes guide to debugging running pods points to two commands:

kubectl describe pod <pod-name> -n production
kubectl logs <pod-name> -n production --previous

describe shows events and the last state of each container, including reasons such as OOMKilled, Error or FailedScheduling. For a container in CrashLoopBackOff, --previous prints the output of the last terminated instance, which often holds the stack trace. Plain kubectl logs shows only the current instance, so it will usually miss the crash. For multi-container pods add -c <container-name>.

Reading exit codes

Exit code 137 is 128 plus 9, meaning the process received SIGKILL. When the reason is OOMKilled, the container exceeded its memory limit and was killed. If the node itself ran out of memory, the kubelet may evict the whole pod instead, and the pod disappears from that node. This Kubernetes forum thread shows how to tell the two cases apart.

The rule of thumb: if the cause is a limit that is too low or a leak, restarting buys you time and nothing else. Raise the limit or fix the leak, then roll out.

A quick triage routine

  1. kubectl get pods -n <ns> and look at the RESTARTS and STATUS columns.
  2. kubectl describe pod and read the Events at the bottom, plus Last State for each container.
  3. kubectl logs --previous for the crashed instance.
  4. Check whether the restarts cluster on one node (kubectl get pods -o wide).
  5. Only then decide: rollout restart for a config change, delete for a single bad replica, or a manifest fix for a real defect.

Restarting without dropping traffic

A rolling restart is only zero-downtime if the app and the Service cooperate. A few checks save you from surprises:

  • Readiness probes. Without a correct readiness probe, Kubernetes considers a new pod ready as soon as the container starts, and traffic can arrive before the app is listening.
  • Handle SIGTERM. Your app should stop accepting new connections and finish in-flight requests when it gets SIGTERM.
  • Mind terminating endpoints. Terminating pods have readiness set to false. The pod and endpoint termination tutorial notes that if you are draining traffic in a load balancer, you should look at the serving condition rather than readiness alone.
  • Use a PodDisruptionBudget for voluntary disruptions such as node drains, so a drain cannot remove too many replicas at once.
  • Run more than one replica. A single-replica Deployment will always have a gap unless maxSurge lets the new pod come up first.

Our perspective: restarts should be boring and visible

Most restart mistakes we see are not command mistakes. They are visibility mistakes. Someone runs a rollout restart in the wrong context because their terminal still points at production, or deletes pods by label without seeing how many match, or walks away before the rollout finished.

Our perspective: restarts should be boring and visible — overview diagram

We built Kubezilla Desktop around that gap. Our view is that the right tool puts the cluster, the namespace, the pod list with restart counts, the live logs and the metrics in one window, so you can see the effect of a restart as it happens instead of running get pods in a loop. Because Kubezilla is a native app written in Rust, it starts fast and stays light, and your kubeconfigs are stored locally, with no cloud sync or telemetry.

Our advice, whatever tool you use: read the previous logs before you restart, prefer rollouts over deletes, confirm the context before every write, and treat a restart that "fixes" something as a bug report you still owe the team.

— Margus

Doing this from a desktop client

Everything above works with kubectl alone. If you juggle several clusters, though, the friction is in the surroundings: switching contexts, opening a second terminal for logs, hopping through SSH tunnels to reach a private cluster. Kubezilla Desktop handles multi-cluster access and SSH tunneling in one native interface, with live log streaming, metrics, pod terminals and scaling next to the workload list. See how pod access works in our pod shell guide, or read how we approach SSH tunnels to Kubernetes clusters.

Kubezilla Desktop is available for Linux, macOS and Windows at €5 per month. You can read the details on the pricing page or start from the Kubezilla Desktop home page.

Mistakes that turn a restart into an incident

  • Restarting in the wrong context. Check kubectl config current-context before any write. The same applies to the namespace.
  • Mass deletion. Deleting every pod behind a label skips the rollout limits. Use a rollout restart.
  • Skipping the status check. If the new version of a config is broken, every new pod can fail its readiness probe. Watching rollout status catches this while the old pods still serve traffic.
  • Forgetting that restart will not change the image tag. A rollout restart re-creates pods from the same template. If you use a mutable tag like latest, whether the node pulls a new image depends on your imagePullPolicy. Pin immutable tags instead.
  • Restarting a StatefulSet casually. Pods are replaced in order, one at a time, and each must become ready. Plan for that duration.
  • Using restarts to hide leaks. If restart counts climb over days, you have a memory or resource issue to fix.

If you want to rehearse a change before you apply it, our piece on Kubernetes dry runs explains which dry-run option actually checks admission on the server.

FAQ

What is the kubectl command for rolling restarts?

Use kubectl rollout restart deployment/<name>. It also works for StatefulSets and DaemonSets. The controller replaces pods gradually according to its rollout strategy, and you can follow progress with kubectl rollout status.

How do I check the reason for a pod restart?

Run kubectl describe pod <name> and read the events and the container's last state, which will show reasons such as OOMKilled. Then run kubectl logs <name> --previous to see the output of the crashed container instance. Exit code 137 usually points to the process being killed, often for exceeding its memory limit.

How do I gracefully shut down a pod?

Kubernetes sends SIGTERM and waits up to 30 seconds by default (terminationGracePeriodSeconds) before sending SIGKILL. Make your app handle SIGTERM, and raise the grace period in the pod spec if it needs longer. For a single deletion you can pass --grace-period.

Does deleting a pod restart it?

If a controller such as a Deployment owns the pod, yes: it immediately creates a new replacement pod. It is a replacement, not a reboot, so the new pod gets a new name and IP. A bare pod with no controller will simply be gone.

Sources