Learn GitOps with ArgoCD - Progressive Delivery with Argo Rollouts

#Introduction

In episode 18 we built a complete CI/CD pipeline: CI produces an image, manifests are updated in Git, and ArgoCD applies them. But there's one question we haven't answered: how do you release a new version without cutting off the service? Kubernetes' built-in rolling update is indeed downtime-free, but it's blind — it doesn't know whether the new version is slowing responses or triggering 500 errors. In this episode we get into progressive delivery with Argo Rollouts, Argo's answer to intelligent and controlled deployments.

The concept is simple but impactful: instead of swapping all pods at once, we roll out a small portion and observe the metrics; if healthy, the rest follows; if broken, we back out automatically. Argo Rollouts is an official component of the Argo ecosystem, and it's a natural complement to GitOps: rollback is no longer a guess, but an evidence-based decision.

#The Progressive Delivery Concept

Progressive delivery is an umbrella covering several release strategies:

Argo Rollouts manages two main strategies directly — canary and blue-green. A/B testing is done by combining canary Rollouts and header-based traffic splitting in a service mesh (episode 20). Feature flags themselves aren't Rollouts' job; they're a complement that can be triggered by the same metrics.

#Argo Rollouts: CRD and Controller

Argo Rollouts introduces a custom resource called Rollout, a replacement for Deployment on workloads that want progressive delivery. The difference: a Rollout understands promotion steps, traffic routing, and metric analysis. Installation is quite simple:

Installing Argo Rollouts

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
kubectl get pods -n argo-rollouts

The running controller reads every Rollout and manages the Deployment, ReplicaSet, Service, and Ingress or service mesh configuration behind it. For a kubectl-like experience, install the kubectl argo rollouts CLI plugin which provides get, status, promote, and abort.

#The Canary Strategy

Canary is the most popular strategy because it's resource-efficient and based on real traffic. User traffic is split: a small portion goes to the new version, the rest to the stable version.

#Configuring the Canary Strategy

rollout.yaml - gradual canary

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-rollout
spec:
  replicas: 10
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/org/api:v2
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: {duration: 5m}
        - setWeight: 50
        - pause: {duration: 10m}
        - setWeight: 100

The steps sequence above tells the story: raise the new version's traffic to 10 percent, hold for 5 minutes (a chance to watch for errors), then 50 percent, hold for 10 minutes, then 100 percent. Each pause gives humans or systems time to evaluate. Without metric analysis, the promotion still runs on schedule — that's why the analysis below matters.

#Traffic Splitting

Rollouts doesn't split traffic itself; it asks the tool in front of it to do so. Two supported modes:

• Service mode — Rollouts creates two Services (api-stable and api-canary) and manages their weights. Suited to NGINX Ingress, which uses weights across multiple backends.
• Service mesh / gateway mode — Rollouts modifies a VirtualService (Istio), Service (Linkerd), or HTTPRoute (Gateway API) so the split happens at the mesh layer.

For simple Service mode, define two Services in the same manifest and let the Rollout add the weights:

service.yaml - stable dan canary

apiVersion: v1
kind: Service
metadata:
  name: api-stable
spec:
  selector:
    app: api
    # rollout menggunakan label rollouts-pod-template-hash
  ports:
    - port: 80
      targetPort: 8080

#Metric-Based Auto Promote and Rollback

The most valuable part of Rollouts is analysis: promotion stops and evaluates metrics before moving to the next step. This is realized through two resources: an AnalysisTemplate (a reusable definition) and its reference in spec.strategy.canary.analysis:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
    - name: success-rate
      interval: 60s
      count: 5
      successCondition: result[0] >= 0.95
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(http_requests_total{app="api",status!~"5.."}[2m])) /
            sum(rate(http_requests_total{app="api"}[2m]))

successCondition: result[0] >= 0.95 means the rollout only continues if the success ratio is at least 95 percent. If it fails beyond failureLimit: 3, the Rollout automatically aborts — traffic returns 100 percent to the stable version. This is an automatic safety net that a regular Deployment doesn't have.

#The Blue-Green Strategy

Blue-green is chosen when instant rollback matters more than resource efficiency. Two full ReplicaSets run side by side; traffic is switched via a Service.

#Configuring Blue-Green

rollout.yaml - blue-green

  strategy:
    blueGreen:
      activeService: api-active
      previewService: api-preview
      autoPromotionEnabled: false

• activeService: api-active — the Service serving user traffic, always pointing to the currently active version.
• previewService: api-preview — a Service for verifying the new version before it's switched (accessible via a temporary Ingress).
• autoPromotionEnabled: false — promotion requires human approval, either via the UI or the CLI.

#Manual Promotion and Instant Rollback

With autoPromotionEnabled: false, the team runs the promotion explicitly:

kubectl argo rollouts promote api-rollout
kubectl argo rollouts status api-rollout
kubectl argo rollouts abort api-rollout

When a problem arises after promotion, abort moves activeService back to the previous version instantly — the "instant" rollback that is the main reason people choose blue-green.

#Traffic Management

The choice of traffic mechanism determines where Rollouts operates:

For NGINX Ingress, just define the backend with two Services (api-stable and api-canary) and the Rollout will manage their weights while the canary runs. For Istio, Rollouts writes the weights directly on a VirtualService — we'll dissect an example in episode 20.

#Integration with ArgoCD

Because the Rollout, AnalysisTemplate, and Services are all regular Kubernetes manifests, ArgoCD treats them like any other resource: stored in Git, synced, and reconciled. The only special attention: applications using Rollouts must have SyncOptions that respect custom resources. If you use Helm, add the CRDs to the chart; if plain YAML, make sure the apply order doesn't delete the controller's Rollout (don't set --force carelessly).

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api
spec:
  source:
    repoURL: https://github.com/org/manifests.git
    path: apps/api
  destination:
    server: https://kubernetes.default.svc
    namespace: api

When the team bumps the image version in Git, ArgoCD syncs the new Rollout, and then the Rollout controller takes over: canary, metric analysis, and rollback all run outside ArgoCD's intervention.

#Closing

This episode introduced progressive delivery as a complement to GitOps: the canary, blue-green, A/B testing, and feature flags concepts; Argo Rollouts installation and the Rollout resource; the canary strategy with steps, pauses, and traffic splitting; metric analysis via an AnalysisTemplate with Prometheus; the blue-green strategy with active and preview services; and a summary of traffic management options and how ArgoCD manages all those resources from Git.

The points you should take with you:

• Progressive delivery releases new versions gradually with verification at every step.
• Rollout replaces Deployment and is monitored with kubectl argo rollouts.
• AnalysisTemplate enables metric-based auto promote and auto rollback.
• Blue-green gives instant rollback at the cost of doubled resources.
• ArgoCD manages the Rollout resources; the Rollout controller runs their progression.

The traffic splitting mechanism has mentioned service mesh several times. In the next episode 20 we dissect service mesh integration — Istio, Linkerd, VirtualService and DestinationRule, mTLS, and distributed observability — within a GitOps architecture. See you in episode 20!