A rolling deployment replaces old instances with new ones gradually, keeping the service available while the update progresses through the fleet.
A rolling deployment updates a subset of instances at a time, verifies health, and then continues until every instance runs the new version. Old and new versions coexist during the process, and the orchestrator manages capacity and readiness.
That incremental replacement is the default for many orchestrated systems because it avoids downtime without doubling infrastructure. The service remains partially available throughout the transition, assuming health checks work and the new version is backward compatible. The risk is slow detection of bad releases if early instances appear healthy and the rollout continues.
Think of it like this. Think of repaving a highway one lane at a time instead of closing the entire road. Traffic keeps flowing, but the work is slower and coordination matters.
The orchestrator updates a configurable batch of pods, containers, or VMs. Each batch passes readiness checks before the next batch starts. Failed batches halt the rollout. Old instances are drained and removed only after replacement instances are healthy.
"Rolling means no risk." Bad releases can still spread if health checks are weak. "Rollout speed should be uniform." Sensitive services benefit from slower, monitored steps. "Rolling works for every change." Schema migrations, stateful services, and breaking API changes need safer patterns.
Preserves availability and uses existing capacity efficiently, but rollout duration is longer than blue-green swaps and compatibility windows are narrower. Works well for stateless services; requires care for stateful workloads.