Explain what maxSurge and maxUnavailable do in a Kubernetes Deployment's RollingUpdate strategy, what their default values are, and when you would choose the Recreate strategy instead.

## The two bounds A rolling update is a constrained search: the Deployment controller repeatedly asks "may I add a pod to the new ReplicaSet?" and "may I remove one from the old?", answering with two ceilings measured against `spec.replicas`. **`maxSurge`** caps total pods above desired. `replicas: 10, maxSurge: 25%` allows up to 13 pods (12.5 rounded **up**) to exist at once. Surge is what lets a rollout add capacity before removing any, so throughput never drops. **`maxUnavailable`** caps how many desired replicas may be unavailable. `replicas: 10, maxUnavailable: 25%` means at least 8 must be available at all times (2.5 rounded **down** to 2). The asymmetric rounding is deliberate: both rules err toward more capacity. They cannot both be 0 — with no surge headroom and no tolerance for unavailability there is no legal move, and the API rejects it. ## What "available" means Availability, not existence, drives the loop. A pod counts when it is **Ready** and has been Ready for `minReadySeconds` (default 0). Consequences worth stating in an interview: - Without a readiness probe, a pod counts as available as soon as its container starts, so a slow-starting service can have its old pods removed while the new ones cannot serve — a self-inflicted outage that looks like a Kubernetes bug. - `minReadySeconds` guards against processes that pass readiness and then crash seconds later; the rollout stalls instead of sweeping the fleet. - Removing an old pod also requires graceful termination to avoid dropping in-flight requests; the rolling strategy governs *counts*, not connection draining. ## Choosing values The decision is capacity headroom versus degradation tolerance: - **`maxUnavailable: 0, maxSurge: 1`** — the conservative production default for a service with a tight capacity budget per pod. You never serve with fewer than N ready pods; you need room in the cluster for one extra pod, and the rollout is serial and slow. - **`maxUnavailable: 0, maxSurge: 25%`** — same guarantee, faster, at the cost of temporarily running ~125% of the pods (and their connection pools, licences, and database connections — a real constraint when a downstream limits connections). - **`maxSurge: 0, maxUnavailable: 1`** — for workloads that cannot exceed a fixed pod count: constrained node pools, a licence limit, or a fixed shard count. You run degraded during the rollout, so N must have enough margin. - **Aggressive percentages (50%+)** — fine for large stateless fleets where speed matters and capacity is elastic. Remember both are evaluated per Deployment, not per zone or node, and neither is aware of topology; spreading is a scheduling concern (topology spread constraints), not a rollout knob. ## Recreate `strategy.type: Recreate` ignores both fields. The controller scales the old ReplicaSet to 0, waits for every pod to terminate, then scales the new one up. There is a genuine outage between those steps, proportional to termination plus startup time. You choose it when two versions must never run simultaneously: - **Singleton processes** — a leader-less scheduler or migration runner where two instances would double-execute work. - **ReadWriteOnce volumes** — a PVC that only one node can mount; a surged pod on a different node would be stuck `Pending` forever, silently hanging the rollout. This is the most common accidental discovery of Recreate's necessity. - **Incompatible schema or protocol versions** — when the new version writes a format the old cannot read and you have not done an expand/contract migration. - **Non-production environments** — where the simplicity and lower resource use beat availability. A good answer names the RWO-volume case explicitly, because it turns Recreate from a nostalgic default into an engineering decision. ## Verifying During a rollout, `kubectl get rs` shows both generations with their DESIRED/CURRENT/READY counts, and their sum against `replicas` demonstrates the two bounds in action. `kubectl describe deployment` prints `RollingUpdateStrategy: 25% max unavailable, 25% max surge` and events narrating each scale step, which is the quickest way to confirm the strategy actually in force versus the one you believe you applied.