Blue‑Green Deployment with Kruise Rollouts: Concepts, Implementation, and Comparison

Kruise Rollouts is a side‑car component from the OpenKruise community that enhances native workloads such as Deployment, StatefulSet, and CloneSet with advanced release strategies like canary, rolling, and blue‑green deployments. Version 0.6.0 adds native blue‑green support for Deployment and CloneSet.

Blue‑green deployment maintains two identical production environments: the active "blue" environment serving traffic and a standby "green" environment where a new version is deployed. Traffic is switched between the two via routing or load‑balancer changes, enabling easy verification and instant rollback.

1. Blue‑Green Release Example

The example deploys an echoserver application with five replicas, a Service, and an Ingress, then creates a Rollout resource that defines a three‑step blue‑green strategy:

apiVersion: rollouts.kruise.io/v1beta1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: echoserver
  strategy:
    blueGreen:
      steps:
      - replicas: 100%   # launch green env, traffic 0%
        traffic: 0%
      - replicas: 100%   # shift 10% traffic to green
        traffic: 10%
      - replicas: 100%   # shift 100% traffic to green
        traffic: 100%
      trafficRoutings:
      - service: echoserver-service
        ingress:
          classType: nginx
          name: echoserver-ingress

Key kubectl commands used during the rollout include checking status, patching the rollout to move from StepPaused to StepReady , and approving the next step:

$ kubectl get rollout
$ kubectl patch rollout rollouts-demo --type merge --subresource status -p "{\"status\":{\"blueGreenStatus\":{\"currentStepState\": \"StepReady\"}}}"
$ kubectl-kruise rollout approve rollouts/rollouts-demo

During each step the pod list shows both blue and green replicas co‑existing. Traffic observations demonstrate that after the second step roughly 10% of requests are served by the green environment, and after the final step all traffic is routed to green.

2. Rollback and Completion

If verification fails at any stage, the blue environment can be restored instantly by patching nextStepIndex or by reverting the Deployment’s hostname back to "blue". Once the third step completes and validation passes, the blue environment is removed, leaving only the green version.

3. Underlying Mechanics

Kruise Rollouts keeps the original workload in a perpetual update state by setting spec.minReadySeconds and spec.progressDeadlineSeconds to very large values, allowing both environments to coexist. It creates duplicate Service and Ingress resources (e.g., echoserver-service‑canary ) with pod‑template‑hash selectors to route traffic to the appropriate set of pods.

4. Comparison with Other Open‑Source Solutions

Argo Rollouts requires migrating workloads to a custom Rollout resource and managing separate Services, incurring higher migration cost. Flux Flagger creates a separate workload for the new version, which can interfere with workload‑sensitive components such as WorkloadSpread or VPA. Kruise Rollouts, by operating on the original workload, avoids these issues and offers hot‑plug capability to modify rollout resources at any time.

5. Resource Considerations and Serverless Advantage

Blue‑green deployments double resource usage while both environments exist, which can be costly on traditional node‑based clusters. Serverless Kubernetes offerings (e.g., Alibaba Cloud ACS) charge based on actual pod usage, mitigating the cost impact and eliminating resource‑capacity constraints during the rollout.

Conclusion

The article provides a comprehensive guide to implementing blue‑green deployments with Kruise Rollouts, covering preparation, step‑wise execution, traffic management, rollback procedures, and practical comparisons, helping practitioners choose the most suitable release strategy for their Kubernetes workloads.