How to rolling restart pods without changing deployment yaml in kubernetes?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
In a Kubernetes environment, managing pod lifecycles efficiently is crucial for maintaining application availability and performance. A rolling restart updates your application pods gracefully without downtime. While this is typically triggered by altering the deployment YAML file, there are strategies to achieve this without any modifications to the deployment manifest.
This article explores different methods for triggering a rolling restart of pods within a Kubernetes deployment without changing the deployment YAML.
Understanding Kubernetes Rolling Restart
A rolling restart applies updates gradually to instances of a pod within a deployment, ensuring that the application remains available during the restart process. This is achieved by killing existing pods and creating new ones incrementally.
Reasons for Rolling Restarts
- Patch Vulnerabilities: There may be a need to restart pods to apply security patches.
- Resource Issues: Restarting can clear resource (CPU/Memory) leaks.
- Refreshing Configurations/Secrets: Sometimes applications need a restart to load new configurations or secrets.
Methods for Rolling Restart Without YAML Modification
1. Kubernetes kubectl rollout restart Command
The most straightforward way is to use the kubectl rollout restart command, which forces a restart of the pods in a deployment:
This command works by incrementing the deployment's pod-template-hash, thereby triggering a redeployment of pods.
Example:
2. Touch an Annotation
Changing annotations is another non-invasive way to restart pods, as updating an annotation doesn’t affect the application's logic.
Step-by-step Process:
- Identify the deployment:
- Patch the deployment by updating an existing annotation or adding a new one:
This command updates the pod template’s metadata, which causes the deployment to redeploy with the same spec since the pod template has changed.
3. Manual Pod Deletion
While this approach should be used cautiously, manually deleting pods can trigger Kubernetes to spin up new ones as replacements.
Procedure:
- Scale down the deployment to zero:
- Scale back up:
Note: Scaling to zero may cause downtime as all pods are deleted before new ones start, making this less ideal for zero-downtime requirements.
Comparing Methods
Related reading
- How to run a container in Kubernetes without creating Deployment or Job?
- How to run containers sequentially as a Kubernetes job?
- How to run kubectl commands inside a container?
- How to run kubernetes cronjob immediately
- How to run a cron job inside a docker container?
- How to run a docker container if not already running
- How to run shell script using CronJobs in Kubernetes?
- How to scale k8s pods according to rabbitmq queue message rate?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.