Rolling Update maxSurge=0 vs Blue-Green for Zero-Downtime Migrations

Migration Strategy Trade-offs

A small stateless application requires a migration strategy that ensures zero downtime. Two documented Kubernetes patterns are under consideration: a RollingUpdate with maxSurge=0 and maxUnavailable=1, or a Blue-Green deployment using separate Services and selector updates.

Constraints and Uncertainties

The maxSurge=0 approach maintains a constant replica count, which is ideal for tight resource constraints but relies heavily on the readinessProbe to signal when the old pod can be terminated. Conversely, Blue-Green deployments allow for an instant cut-over after verifying the new version, but they require double the resource footprint during the transition period.

There is uncertainty regarding the interaction between terminationGracePeriodSeconds and the preStop hook when maxSurge=0 is used. If the preStop hook duration exceeds the grace period, it is unclear if the kubelet terminates the pod prematurely, potentially dropping in-flight requests before the new pod fully assumes the load.

• Does the kubelet prioritize the completion of the preStop hook over the terminationGracePeriodSeconds timer during a maxSurge=0 rollout?
• In a resource-constrained environment, does the Blue-Green selector switch provide a more reliable guarantee against request loss than a sequenced RollingUpdate?