A Deployment has 4 replicas and rollingUpdate.maxUnavailable set to 50%. During the update, how many Pods may be unavailable at once relative to the desired count?
Select an answer to reveal the explanation.
Short Explanation
Half of four chairs can be empty while you swap cushions—that’s two. maxUnavailable 50% on 4 replicas allows two unavailable Pods during the rolling update.
Full Explanation
With 4 replicas and rollingUpdate.maxUnavailable set to 50%, Kubernetes may have up to two Pods unavailable relative to the desired count during the update (50% of 4). That means the controller can allow availability to drop to roughly two Pods while replacing others, unless maxSurge and timing provide additional Ready capacity. For municipal APIs, understanding percentage-to-count rounding is essential to predict worst-case capacity during rollouts.
Why the other options fail by concept: Percentages do not always round down to zero unavailable—here 50% of 4 is 2. Requiring all 4 unavailable before starting new Pods is Recreate-like behavior, not maxUnavailable 50%. Claiming exactly 3 must always be unavailable misreads the percentage math.
Exam caveat: Kubernetes rounding rules for maxUnavailable/maxSurge percentages matter (absolute derived counts). Interaction with maxSurge can keep higher absolute Pod counts even when some are unavailable. “Unavailable” ties to Availability (Ready for minReadySeconds), not merely non-Running. Always compute against .spec.replicas.
Operational check: On a test Deployment with 4 replicas, maxUnavailable 50%, and a slow readiness, watch kubectl get pods during rollout and observe how many fall non-Ready/terminated concurrently. Compare observed minimum Ready count to the planned floor before using the same settings on a resident-facing Service.