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
When maxUnavailable is a percentage, Kubernetes computes the absolute count from .spec.replicas (rounding down, with a minimum of zero unless other rules apply; for 50% of 4 the absolute value is 2). That caps how many Pods may be down relative to the desired replica count during RollingUpdate. It does not require all Pods down, nor a fixed three unavailable, and 50% of four is not zero.