How to rolling restart pods without changing deployment yaml in kubernetes?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
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

