Kubernetes is designed for resilience at scale. But what happens when a pod or container fails? The answer lies in the Kubernetes pod restart policy—a core feature that keeps your workloads healthy and available even when things go wrong.
What is Kubernetes Pod Restart Policy?
A Kubernetes pod restart policy controls what happens when a container inside a pod stops running. This setting tells Kubernetes whether to restart the container—and under which conditions it should do so. By default, this policy applies to all containers in a pod unless you use advanced per-container settings introduced in newer versions of Kubernetes.
Understanding how these policies work helps you avoid unwanted downtime or resource waste in your clusters.
Types of Pod Restart Policies in Kubernetes
Kubernetes offers three main restart policies for pods: Always, OnFailure, and Never. Each fits different workload needs.
Always: Kubernetes restarts the container no matter why it stopped—whether it failed or finished successfully. This is the default for most workloads managed by controllers like Deployments or StatefulSets.
OnFailure: The container restarts only if it exits with an error (a non-zero exit code). If it finishes successfully (exit code 0), it will not restart.
Never: The container will not restart regardless of how it exits—the pod remains but its containers stay stopped after completion or failure.
If you do not set a specific policy, Kubernetes uses Always by default for most cases except Jobs or CronJobs—which use OnFailure unless specified otherwise.
How to Set Pod Restart Policy?
Setting the kubernetes pod restart policy is straightforward but must be done correctly within your YAML manifest’s spec section—or via command line tools like kubectl run—for standalone pods or jobs only.
For standalone pods:
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: busybox
image: busybox
command: ["sh", "-c", "exit 1"]
restartPolicy: OnFailure
This configuration ensures that if busybox exits with an error code, Kubernetes will attempt to restart it; otherwise, it stays down after success.
You can also create such pods using kubectl:
kubectl run mypod --image=busybox --restart=Never -- sh -c "echo Hello"
Here you specify Never as the policy directly from CLI—useful for quick tests or debugging sessions outside CI/CD pipelines.
For workloads managed by controllers such as Deployments or StatefulSets:
This design ensures high availability but limits flexibility compared to standalone pods/jobs.
Why Choose Different Restart Policies?
Choosing the right kubernetes pod restart policy depends on your workload’s requirements—and making mistakes here can lead to wasted resources or unexpected downtime.
Best Practices for Common Workload Types
Let’s look at typical scenarios:
Long-running services (web servers/APIs): Use Always so they recover from crashes automatically—ensuring high availability even during rolling updates or node failures.<br>
Batch jobs/scripts that must retry until successful completion benefit from OnFailure; failed runs get retried while successful ones finish cleanly.<br>
One-off tasks/debugging sessions should use Never so they don’t loop endlessly after finishing—ideal when investigating issues interactively.<br>
Mapping policies correctly avoids problems like batch jobs stuck in infinite loops due to Always being set accidentally—or web servers failing silently because Never was chosen by mistake.
Real-world Scenarios & Pitfalls
Imagine deploying a data migration job that is supposed to run only once and then stop—even if it fails—so you can manually inspect the results before triggering it again.
If you accidentally set its restart policy to Always instead of Never, the job may repeatedly rerun unfinished migration tasks, potentially causing data corruption.
Conversely, if you deploy an HTTP API server with a restart policy of Never, it won’t recover from crashes triggered by transient network issues. Users would experience unnecessary outages until someone intervenes manually.
Choosing the right restart policy for each workload type prevents accidental reruns, avoids downtime, and saves a lot of operational headaches in production environments.
Protecting Your Workloads with Vinchin Backup & Recovery
While configuring appropriate restart policies enhances application resilience, comprehensive protection against data loss and operational risks requires robust backup solutions tailored for enterprise environments. Vinchin Backup & Recovery stands out as a professional, enterprise-level platform purpose-built for safeguarding Kubernetes workloads across diverse infrastructures.
Vinchin Backup & Recovery delivers powerful features including full and incremental backups, fine-grained restore capabilities at cluster, namespace, application, PVC, and resource levels, cross-cluster/cross-version recovery options, secure encrypted transmission/storage with WORM protection, and intelligent automation through flexible backup strategies and custom scripts. Together these capabilities ensure efficient disaster recovery, seamless migration between clusters/Kubernetes versions/clouds, regulatory compliance, and simplified day-to-day operations—all through one unified solution.
The intuitive web console makes protecting your Kubernetes environment simple. Typically you’ll follow four steps:
Step 1. Select the backup source
Step 2. Choose the backup storage
Step 3. Define the backup strategy
Step 4. Submit the job
Join thousands of global organizations who trust Vinchin Backup & Recovery for enterprise data protection—top-rated worldwide! Try all features free for 60 days; click below to start your trial today.
Kubernetes Pod Restart Policy FAQs
Q1: Can I change the restart policy of a running pod?
A1: No—you must delete then recreate the pod with your desired kubernetes pod restart policy applied at creation time.
Q2: Why does my pod keep restarting even after completing successfully?
A2: If set to Always, Kubernetes restarts containers regardless of their exit status—including normal completions!
Q3: How do I set different restart policies for containers within one pod?
A3: Enable ContainerRestartRules via feature gates in supported clusters then specify each rule under its respective container spec during manifest creation/redeployment cycle.
Q4: How does kubernetes pod restart policy interact with liveness/readiness probes?
A4: Liveness probes trigger restarts based on health checks but never override your defined kubernetes pod restart policy—they work together rather than replace each other.
Conclusion
The kubernetes pod restart policy gives you precise control over application resilience—helping ensure uptime while avoiding unnecessary resource usage across diverse workloads.
For complete protection—including automated backups/migrations—Vinchin delivers robust enterprise-grade solutions trusted worldwide! Try Vinchin free today—and safeguard every layer of your cloud-native stack.
