How Kruise Rollout Enables Progressive Delivery in Cloud‑Native Kubernetes

Progressive Delivery Overview

Progressive delivery divides a release into multiple batches, allowing fine‑grained control over when each batch starts, stops, and is verified. It supports both instance‑count and traffic‑percentage dimensions, enabling canary, A/B testing, and blue‑green strategies.

Key Characteristics

Incremental release : Deployments are split into batches that can be paused or resumed independently.

Dual‑dimension gray‑scale : Traffic routing and replica scaling are controlled together.

Stage verifiability : Each batch can be validated (e.g., health checks, metrics) before proceeding.

Example Scenario

Assume version X runs in production and needs to be upgraded to version Y. The rollout is defined as a sequence of batches (e.g., first batch updates ten pods). Traffic is gradually shifted to Y —initially only internal users—while health checks run. If the checks pass, the next batch is released; any failure triggers an immediate rollback to X.

Relation to Kubernetes Workloads

Kubernetes workloads such as Deployment and StatefulSet manage Pods. Deployment offers maxUnavailable and maxSurge but only supports a single streaming rollout without batch control. StatefulSet can perform batch updates but lacks traffic routing and progress control. Progressive delivery extends these workloads by adding traffic routing and explicit batch orchestration.

Design Goals for Kruise Rollout

Non‑intrusive : No changes to native workload controllers or user‑defined YAML; original resources remain clean.

Extensible : Works with native workloads, custom workloads, and various traffic routers (e.g., Nginx, Istio).

Ease of use : Provides out‑of‑the‑box functionality that integrates with GitOps pipelines.

Comparison with Other Community Solutions

Argo Rollout defines a new workload that embeds rollout capabilities. It offers rich features but requires migrating existing Deployments, making it suitable for greenfield projects.

Flagger augments native Deployments with traffic gray‑scale and batch logic, staying compatible with Helm and Argo CD. It incurs double pod resources during the double‑deployment phase and may need extra integration for custom platforms.

API Design

ObjectRef : Identifies the target workload (e.g., Deployment name).

Strategy : Describes rollout steps, such as a canary that releases 5% of replicas and 5% of traffic, awaiting manual approval before the next step.

TrafficRouting : References the traffic routing resource (Service, Ingress, or Gateway API).

Status : Reports the current phase, health, and any errors of the rollout.

Rollout Mechanism

User applies a new version of the application (kubectl apply).

A Kruise Rollout webhook intercepts the request and pauses the underlying workload controller by adjusting its strategy.

The controller modifies workload parameters (e.g., partition) to create the defined batch.

After each batch, the associated Service/Ingress is updated to route the appropriate traffic slice to the new version.

Prometheus metrics (e.g., HTTP status codes, latency) are consulted to verify health before advancing.

When all batches complete, the original workload configuration is restored, achieving a zero‑intrusion rollout.

Repository and Documentation

Source code and releases are hosted at https://github.com/openkruise/rollouts. Additional documentation is available at https://openkruise.io/.