Rolling Update

The primary objective of a rolling update is to achieve zero-downtime deployment. It does this by maintaining a minimum number of healthy instances at all times. The orchestrator (like Kubernetes) follows a controlled sequence:

• Terminates an old pod/instance.
• Schedules and starts a new pod/instance.
• Waits for the new instance to pass its readiness probe.
• Only then proceeds to update the next old instance. This ensures the overall service remains available to users throughout the entire update process.

Rolling updates are governed by configurable parameters that control the pace and risk of the rollout. In Kubernetes, these are defined in a Deployment's strategy spec:

• maxUnavailable: The maximum number of pods that can be unavailable during the update (e.g., 25%). This controls the degradation in capacity.
• maxSurge: The maximum number of pods that can be created over the desired number (e.g., 25%). This allows extra resources to be provisioned during the transition. These settings allow engineers to balance deployment speed against resource consumption and risk tolerance.

A key safety feature is the automatic rollback capability. If the update introduces a critical failure—such as a new pod repeatedly failing its startup or readiness checks—the orchestrator can automatically halt the rollout and revert to the previous stable version. This is often triggered by progress deadlines or health check failures. In Kubernetes, you can manually trigger a rollback using kubectl rollout undo deployment/<name>, which points the Deployment's Pod template back to the previous ReplicaSet.

The safety of a rolling update is entirely dependent on correctly configured health probes. These are the mechanisms the orchestrator uses to determine instance viability:

• Readiness Probes: Signal when a pod is ready to accept traffic. A rolling update waits for new pods to pass this probe before continuing.
• Liveness Probes: Signal if a pod is running. A failed liveness probe causes the pod to be restarted. Without accurate probes, the system might route traffic to broken pods or terminate healthy ones, leading to service disruption.

Rolling updates are ideally suited for stateless applications. Since each instance is independent and disposable, replacing them in sequence does not cause data inconsistency or session corruption. For stateful applications (e.g., databases), a standard rolling update is often insufficient and risky, as it can disrupt quorums or replication. Stateful workloads typically require more sophisticated strategies like partitioned updates or operator-driven updates that understand the stateful semantics.

Rolling updates differ from other deployment strategies in granularity and traffic control:

• vs. Blue-Green: Blue-green maintains two complete, separate environments and switches all traffic at once. Rolling updates change the same environment incrementally. Blue-green offers instant rollback but requires double the resources.
• vs. Canary Deployment: A canary release is a targeted subset rollout, often to specific users. A rolling update is a full, gradual infrastructure replacement. Canary deployments are a form of progressive delivery focused on validation, while rolling updates focus on safe infrastructure replacement. They are often used in combination.

A risk mitigation strategy where a new application version is released to a small, controlled subset of users or infrastructure before a full rollout. This allows teams to validate stability, performance, and user experience with minimal exposure.

• Key Mechanism: Traffic is split, with a small percentage (e.g., 5%) directed to the new version.
• Monitoring: Critical metrics (error rates, latency) are closely watched. If issues are detected, the rollout is halted and the canary traffic is reverted.
• Example: A social media platform tests a new recommendation algorithm on 1% of its user base to gauge engagement before enabling it for everyone.

A strategy that maintains two identical, full-scale production environments: Blue (current version) and Green (new version). Traffic is switched instantaneously from one environment to the other, enabling zero-downtime releases and instant rollbacks.

• Core Benefit: Eliminates the incremental replacement of instances, removing the "rolling" phase and its associated complexity.
• Rollback Process: If the new version (Green) fails, traffic is immediately switched back to the stable version (Blue).
• Infrastructure Cost: Requires double the production infrastructure during the cutover window, which can be managed with cloud automation.

A Kubernetes controller that automatically scales the number of pods in a deployment or replica set based on observed CPU utilization, memory consumption, or custom metrics. It is a critical companion to rolling updates for maintaining performance during deployment churn.

• How it works: The HPA continuously monitors pod metrics. If demand increases, it creates new pods to handle load; if demand drops, it scales pods down to save resources.
• Interaction with Rolling Updates: During an update, the HPA ensures the newly created pods from the new version can scale to meet demand as old pods are terminated.
• Custom Metrics: Can scale based on application-specific metrics like requests per second or queue length.

Kubernetes health checks that determine if a container is operational and ready to serve traffic. They are essential for the safety of rolling updates.

• Readiness Probe: Signals that a container is ready to accept requests. If it fails, the pod is removed from Service endpoints, ensuring traffic is not sent to an unprepared instance during an update.
• Liveness Probe: Determines if a container is running. If it fails, the kubelet kills and restarts the container.
• Update Safety: A proper readiness probe ensures new pods are fully initialized before receiving traffic, and old pods are drained of traffic before termination, preventing request failures.

An overarching software delivery methodology that uses techniques like canary deployments, feature flags, and A/B testing to gradually roll out changes while continuously monitoring for issues. Rolling updates are a foundational technical mechanism within this philosophy.

• Core Principle: Decouple deployment (releasing code to infrastructure) from release (exposing functionality to users).
• Tools Used: Combines infrastructure patterns (rolling/canary) with application-level controls (feature flags) and rigorous observability.
• Goal: To reduce the risk of releases, increase release velocity, and make data-driven decisions about feature impact.

The practice of routing a defined percentage of user requests to different versions of a service. This is the enabling mechanism for canary deployments and A/B testing, often implemented at the load balancer or service mesh layer.

• Implementation: Can be done via configuration in an API Gateway (e.g., 90% to v1, 10% to v2) or a Service Mesh (e.g., Istio VirtualService).
• Precision: Allows for very fine-grained control (e.g., 1%, 5%, 50%) compared to the instance-based granularity of a basic rolling update.
• Use Case: Enables gradual exposure, performance comparison between versions, and targeted feature releases to specific user segments.