What is the Kubernetes rolling update strategy and which parameters control its pace?

What is the Kubernetes rolling update strategy and which parameters control its pace?

• A. It scales the deployment by increasing replicas; minReadySeconds and terminationGracePeriodSeconds control pace.
• B. It replaces pods incrementally; maxUnavailable and maxSurge control pace.
• C. It creates a new cluster version; upgradePolicies control pace.
• D. It runs all pods at once to finish quickly; maxPods controls pace.

Answer: (B)

Rolling updates in Kubernetes update a Deployment by replacing pods incrementally rather than all at once. The pace of that update is controlled by two settings: maxUnavailable and maxSurge. maxUnavailable sets how many pods can be unavailable during the update (as a number or percentage of the desired replicas). maxSurge allows extra pods to be created above the desired count during the update, enabling a smoother ramp-up of the new version. For example, with 10 replicas, if maxUnavailable is 1 and maxSurge is 2, up to 12 pods can exist during the update (the 10 desired plus 2 surge), but at most 1 can be unavailable at any time. This means the system can bring up new versions gradually while older ones are still running, ensuring you don’t lose too much availability. The other options don’t fit the pacing concept: minReadySeconds and terminationGracePeriodSeconds govern readiness timing and how long to wait for pod termination, not the rollout speed. An upgradePolicies concept isn’t a standard Kubernetes setting. Running all pods at once would defeat the purpose of a rolling update and isn’t how Kubernetes deployments are designed to update.

Rolling updates in Kubernetes update a Deployment by replacing pods incrementally rather than all at once. The pace of that update is controlled by two settings: maxUnavailable and maxSurge. maxUnavailable sets how many pods can be unavailable during the update (as a number or percentage of the desired replicas). maxSurge allows extra pods to be created above the desired count during the update, enabling a smoother ramp-up of the new version.

For example, with 10 replicas, if maxUnavailable is 1 and maxSurge is 2, up to 12 pods can exist during the update (the 10 desired plus 2 surge), but at most 1 can be unavailable at any time. This means the system can bring up new versions gradually while older ones are still running, ensuring you don’t lose too much availability.

The other options don’t fit the pacing concept: minReadySeconds and terminationGracePeriodSeconds govern readiness timing and how long to wait for pod termination, not the rollout speed. An upgradePolicies concept isn’t a standard Kubernetes setting. Running all pods at once would defeat the purpose of a rolling update and isn’t how Kubernetes deployments are designed to update.