Rolling Update

The primary objective of a rolling update is to maintain service availability throughout the deployment process. This is achieved by:

• Sequential Pod Replacement: New pods are created and pass their readiness probes before old pods are terminated.
• Traffic Shifting: The orchestrator (e.g., Kubernetes) automatically shifts traffic from old to new, healthy pods.
• Continuous Service: End-users experience no interruption, as at least one replica is always available to serve requests.

Rolling updates provide fine-grained control over the speed and risk of the deployment through configurable parameters:

• maxUnavailable: Defines the maximum number or percentage of pods that can be unavailable during the update (e.g., 25%). This controls the impact on capacity.
• maxSurge: Defines the maximum number or percentage of pods that can be created over the desired number (e.g., 25%). This allows for faster rollouts by temporarily over-provisioning.
• MinReadySeconds: Forces new pods to be 'ready' for a minimum period before being considered available, catching late-start failures.

The strategy relies on probes to autonomously validate the health of new instances, preventing defective versions from receiving traffic.

• Readiness Probes: Determine if a new pod is fully initialized and ready. Traffic is only directed to pods that pass this check.
• Liveness Probes: Continuously check if a running pod is healthy. A failing pod is restarted.
• Rollback Trigger: If the number of unavailable pods exceeds maxUnavailable due to probe failures, the update can be automatically paused or rolled back, acting as a built-in circuit breaker.

During the update, multiple application versions run simultaneously, enabling instant recovery.

• Gradual Traffic Migration: Traffic is split between old and new versions, allowing for performance comparison and A/B testing.
• Atomic Rollback Capability: If the new version fails, the orchestrator can immediately reverse the process by terminating the new pods and scaling up the old ones. This leverages the immutable nature of container images and declarative state.
• State Management: For stateless services, this is straightforward. Stateful services require careful design using PersistentVolumes to ensure data consistency across versions.

Rolling updates are managed declaratively by orchestration platforms like Kubernetes Deployments or Amazon ECS Services.

• Declarative Spec: The engineer defines the desired end state (new image, replica count). The orchestrator's controller loop executes the precise sequence of pod lifecycle events to achieve it.
• Event-Driven Coordination: The system handles pod scheduling, image pulling, network attachment, and health checking without manual intervention.
• Integration with Ecosystem: Works seamlessly with Horizontal Pod Autoscaling (HPA), Pod Disruption Budgets (PDB), and Service Meshes for advanced traffic shaping and resilience.

Rolling updates are the default strategy for most stateless microservices but must be evaluated against alternatives.

• Ideal For: Frequent, automated deployments of backend APIs, web services, and worker processes where brief version coexistence is acceptable.
• Comparison to Blue-Green: Less resource-intensive (no full parallel environment) but slower to rollback completely. Blue-green offers instantaneous switchover.
• Comparison to Canary: A rolling update is a broad technique; a canary deployment is a specific application of it where the new version is released to a small, controlled subset of traffic first, often using a service mesh for sophisticated traffic splitting.

In a microservices architecture, rolling updates allow teams to deploy new versions of a single service independently. This is critical for:

• Backward-Compatible API Changes: Deploying a new service version that understands both old and new request formats, allowing client services to update at their own pace.
• Database Schema Migrations: Applying non-breaking schema changes (e.g., adding a nullable column) before deploying code that uses the new schema. The rolling update ensures some pods use the old schema and some the new during the transition, maintaining overall system function.

A risk-mitigation strategy where a new version is released to a small, controlled subset of users or infrastructure (the 'canary') before a full rollout. It is often used in conjunction with a rolling update to first validate stability and performance metrics.

• Key Difference: A rolling update gradually replaces all instances, while a canary deployment initially targets a subset for validation.
• Use Case: Testing a new model version with 5% of production traffic to monitor for latency spikes or errors before proceeding.

A strategy that maintains two identical, full-scale production environments (Blue and Green). Traffic is switched entirely from the old environment (Blue) to the new one (Green) in a single cutover.

• Key Difference: Provides instant rollback by switching traffic back, whereas a rolling update rollback requires re-deploying the previous version across instances.
• Trade-off: Requires double the infrastructure resources during the transition but minimizes deployment risk and complexity.

The underlying mechanism for directing a controlled percentage of user requests to different service versions. It is the enabling technology for canary deployments and A/B tests.

• Implementation: Often managed by a service mesh (like Istio or Linkerd) or an API gateway using rules based on HTTP headers or weights.
• Observability Link: Critical for monitoring key performance indicators (KPIs) like error rates and latency per version during a progressive rollout.

Health checks defined in a pod specification that the orchestrator uses to manage a rolling update's lifecycle.

• Readiness Probe: Determines if a pod is ready to serve traffic. A new pod must pass this check before being added to the load balancer, preventing user errors.
• Liveness Probe: Determines if a pod is still running. If it fails, the pod is restarted, ensuring faulty instances are replaced.
• Rollout Control: These probes govern the pace and success of the incremental pod replacement in a rolling update.

A Kubernetes policy that limits the number of concurrent voluntary disruptions to pods in an application. It is a safety mechanism for rolling updates and other maintenance operations.

• Function: Ensures a minimum number of pods (e.g., minAvailable: 90%) or a maximum number of unavailable pods (e.g., maxUnavailable: 1) are always running.
• Impact on Updates: The rolling update controller respects the PDB, pacing the pod replacements to maintain the defined availability guarantee.

The process of reverting a deployment to a previous, stable version. In the context of a rolling update, this is typically triggered automatically if the new version fails health checks or manually due to observed issues.

• Kubernetes Mechanism: Executed by updating the deployment manifest to point to the previous container image, triggering a new rolling update in reverse.
• Observability Dependency: Effective rollbacks depend on rapid detection of anomalies through metrics, logs, and traces collected during the update.