Mastering Canary and Blue‑Green Deployments with Argo Rollouts on Kubernetes

What is Argo Rollouts

Argo Rollouts is a Kubernetes controller and a set of CRDs that provide advanced Deployment capabilities such as canary, blue‑green, experimentation, and progressive delivery.

Supported features include:

Blue‑green update strategy

Canary update strategy

Fine‑grained weighted traffic shifting

Automatic rollback and promotion

Manual judgement

Custom metric queries and business KPI analysis

Ingress integration: NGINX, ALB

Service mesh integration: Istio, Linkerd, SMI

Metric provider integration: Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs

Argo works similarly to a Deployment but adds rollout strategies and traffic control. When the

spec.template

changes, Argo Rollouts creates a new ReplicaSet and gradually scales down the previous one.

Installation

Install according to the official documentation: https://argoproj.github.io/argo-rollouts/installation/#kubectl-plugin-installation

Install Argo Rollouts in the cluster

<code>kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml
</code>

Install the kubectl plugin

<code>curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x ./kubectl-argo-rollouts-linux-amd64
mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts
</code>

Canary Release

Canary release consists of Replica Shifting and Traffic Shifting.

Replica Shifting: version replacement

Traffic Shifting: traffic routing

Example using the official demo:

Deploy the application

<code>kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml
</code>

rollout.yaml content:

<code>apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {}
      - setWeight: 40
      - pause: {duration: 10}
      - setWeight: 60
      - pause: {duration: 10}
      - setWeight: 80
      - pause: {duration: 10}
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollouts-demo
  template:
    metadata:
      labels:
        app: rollouts-demo
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        resources:
          requests:
            memory: 32Mi
            cpu: 5m
</code>

The

strategy

field defines the rollout steps, where

setWeight

sets traffic weight and

pause

pauses (manual if no duration, automatic otherwise).

service.yaml defines a standard Service:

<code>apiVersion: v1
kind: Service
metadata:
  name: rollouts-demo
spec:
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: rollouts-demo
</code>

After applying, five pods are created in the default namespace. Use:

<code>kubectl argo rollouts get rollout rollouts-demo
</code>

to view status. The rollout can be watched with

--watch

.

Update the application

Update the image with:

<code>kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow
</code>

The rollout pauses at the first step (weight 20%). Use

kubectl argo rollouts promote rollouts-demo

to continue, or

kubectl argo rollouts abort rollouts-demo

to abort.

Rollback

Rollback to a previous revision with:

<code>kubectl-argo-rollouts undo rollouts-demo --to-revision=1
</code>

Traffic Shifting

Argo Rollouts integrates with Ingress and Service Mesh for traffic control. The example uses NGINX Ingress.

Deploy with Ingress

<code>kubectl delete -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
kubectl delete -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/nginx/rollout.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/nginx/services.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/nginx/ingress.yaml
</code>

rollout.yaml sets

canaryService

and

stableService

and configures NGINX traffic routing with a weight of 50%.

When the rollout is created, Argo creates an additional canary Ingress that routes traffic to the canary Service.

Updating the image triggers the canary Ingress to add the

nginx.ingress.kubernetes.io/canary-weight

annotation (e.g., "50"). The UI shows the traffic split.

Continue with

kubectl argo rollouts promote rollouts-demo

or abort with

kubectl argo rollouts abort rollouts-demo

.

Conclusion

Argo Rollouts provides richer deployment capabilities than the native Deployment, including canary and blue‑green strategies that are useful for operations. Blue‑green can be enabled by configuring a Rollout with a

blueGreen

strategy.