sample-app: PDB + RollingUpdate strategy to contain bad rollouts#4
Conversation
- Deployment.spec.strategy: maxUnavailable=0, maxSurge=1 so a bad rollout stalls on failing readiness instead of replacing healthy pods - PodDisruptionBudget (maxUnavailable=1) so voluntary disruptions can't stack with an in-progress bad rollout and take the whole fleet down - runbook.md: documents both, and flags the still-open gap (alert runbook_url + automated rollback) as out of scope for this repo
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a rolling update strategy to the deployment configuration, adds a PodDisruptionBudget (PDB) to prevent voluntary disruptions, and documents these rollout containment strategies in the runbook. The review feedback suggests changing the hardcoded maxUnavailable: 1 in the PDB to a percentage-based value ("33%") to scale dynamically with the Horizontal Pod Autoscaler, along with a corresponding update to the documentation.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| metadata: | ||
| name: sample-app | ||
| spec: | ||
| maxUnavailable: 1 |
There was a problem hiding this comment.
Since the application uses a Horizontal Pod Autoscaler (hpa.yaml), the number of replicas can scale dynamically. Using a hardcoded absolute value of maxUnavailable: 1 can become highly restrictive as the application scales up (e.g., during node drains or cluster upgrades, only one pod can be evicted at a time, which significantly slows down cluster maintenance).
Consider using a percentage-based value like maxUnavailable: "33%" instead. This scales dynamically with the replica count while maintaining the same behavior for lower replica counts:
- 1 replica (dev):
1 * 33% = 0.33(rounded up to1), allowing full disruption. - 2 replicas (staging):
2 * 33% = 0.66(rounded up to1), allowing at most 1 unavailable pod. - 3 replicas (prod):
3 * 33% = 0.99(rounded up to1), allowing at most 1 unavailable pod.
maxUnavailable: "33%"| healthy pods until the new ones pass readiness. Combined with the readiness | ||
| probe, a crash-looping new version stalls the rollout instead of replacing | ||
| the whole fleet. | ||
| - **PodDisruptionBudget**: `maxUnavailable: 1` on `sample-app` protects |
There was a problem hiding this comment.
Update the documentation to reflect the percentage-based maxUnavailable value if the suggestion to use "33%" is adopted.
| - **PodDisruptionBudget**: `maxUnavailable: 1` on `sample-app` protects | |
| - **PodDisruptionBudget**: `maxUnavailable: "33%"` on `sample-app` protects |
1 participant
Closes the "no PDB, no maxUnavailable/maxSurge" part of the crash-loop gap. Rollback docs already existed (runbook.md, rollback.md); this adds the missing containment mechanics and links them in the runbook.
Still open (flagged, not fixed here, out of scope repos): alert -> runbook_url wiring in cluster-observability, and automated rollback (Argo Rollouts analysis).