Kubernetes Rollout Capacity Lab: Readiness, Surge, and Drain

The Kubernetes Rollout Capacity Lab is a deterministic browser-only teaching model. It creates no Pod, contacts no cluster, runs no benchmark, and produces no deployable configuration.

Quick answer

The lab advances old, starting, ready, and terminating modeled Pods through discrete steps. Desired replicas, modeled per-Pod capacity, incoming load, readiness delay, surge, unavailability, termination grace, and a failure preset determine the timeline. The result explains modeled serving capacity and rollout progress; it does not predict real latency, scheduling, OOM, availability, or business success.

Learning objectives

• Explain how readiness delay, surge, unavailability, termination, and per-version capacity interact during a rollout.
• Recognize when controller progress and modeled serving capacity diverge, then name the production evidence required next.

Prerequisites

Complete Safe Backend Releases and Production Kubernetes Troubleshooting. The capstone belongs to the Cloud-Native Backend course and topic cluster.

Six teaching scenarios

1. Healthy rolling update: readiness and spare capacity permit steady replacement.
2. Slow startup with a startup budget: new Pods take longer but eventually become useful.
3. Readiness never succeeds: surge fills and the rollout stalls without deleting protected old capacity.
4. Unavailable capacity mismatch: aggressive replacement creates a modeled overload window.
5. Termination too short: old Pods leave before the modeled drain requirement.
6. New-version capacity regression: Pod count looks healthy while useful modeled throughput falls.

The model accepts integers or percentages for maxSurge and maxUnavailable, then resolves them with the lesson’s stated rounding policy. It rejects non-finite, negative, fractional, oversized, or deadlocked inputs through structured field errors. A deliberately impossible 0/0 rollout reports a stalled result rather than looping.

Production failure scenario

The healthy preset is copied into a release review as proof that six real Pods can handle a traffic event. That is unsupported: the lab’s per-Pod capacity is an input, steps are not seconds, and the model contains no scheduler, JVM, database, proxy, client, or workload measurement.

Use the output to ask better questions, then validate with representative production-safe evidence: startup distribution, readiness behavior, throttling, connection ownership, request outcomes, termination, and durable business state.

Common misconceptions

• A timeline step is not a real duration.
• Modeled per-Pod capacity is not a benchmark result.
• “No overload” in the model is not an availability promise.
• A stalled scenario does not execute kubectl or inspect a Deployment.
• Copyable output is an educational explanation, not deployment YAML.

Decision checklist

• State which inputs are measured, assumed, or policy decisions.
• Compare resolved surge and unavailable counts with actual replica scale.
• Measure readiness and termination distributions in the real workload.
• Include database and downstream ownership during rollout overlap.
• Define user and business verification beyond controller progress.
• Keep the lab output labeled as deterministic educational modeling.

Open the Kubernetes Rollout Capacity Lab or restart the Cloud-Native Backend Operations course.

Related reading

• Production Kubernetes Backend Incident Troubleshooting
• Kubernetes Rolling Updates and Safe Backend Releases
• Kubernetes Resource Requests, Limits, and JVM Containers

Official sources

• Kubernetes Deployments, accessed August 18, 2026.
• Kubernetes workload management, accessed August 18, 2026.
• Kubernetes Pod lifecycle, accessed August 18, 2026.