Argo Rollouts

Rolls out new versions gradually, canary or blue-green, instead of all at once

Argo Rollouts replaces the Deployment rollout strategy for services that need it: new revisions shift traffic gradually (canary steps) or switch over atomically (blue-green), with analysis in between. The strategy lives next to the app in Git.

ArgoCD configuration

Excerpt from argocd-apps/values.yaml in the argocd-apps chart, with annotations added for this site: 

argo-rollouts:
  application: true
  project: cluster-services
  # false
  autoSync: false

Chart values

The full argo-rollouts/values.yaml from the service's own chart: 

argo-rollouts:
  installCRDs: true
  keepCRDs: true

  clusterInstall: true

  createClusterAggregateRoles: true

  serviceAccount:
    create: true
    name: "argo-rollouts-service-account"

  controller:
    replicas: 1
    # Monitoring: expose the rollouts controller Prometheus metrics on
    # argo-rollouts-metrics:8090 (scraped by the `monitoring` Alloy
    # DaemonSet → New Relic).
    metrics:
      enabled: true
    trafficRouterPlugins:
      - name: "argoproj-labs/gatewayAPI"
        location: "https://github.com/argoproj-labs/rollouts-plugin-trafficrouter-gatew\
          ayapi/releases/download/v0.11.0/gatewayapi-plugin-linux-arm64"
  containerSecurityContext:
    allowPrivilegeEscalation: false
    capabilities:
      drop:
        - ALL
    readOnlyRootFilesystem: true
    seccompProfile:
      type: RuntimeDefault

  providerRBAC:
    enabled: true
    providers:
      istio: false
      smi: false
      ambassador: false
      awsLoadBalancerController: false
      awsAppMesh: false
      traefik: false
      apisix: false
      contour: false
      glooPlatform: false
      gatewayAPI: true

  dashboard:
    enabled: true
    readonly: false
    component: rollouts-dashboard
    createClusterRole: true

    replicas: 1
    image:
      registry: quay.io
      repository: argoproj/kubectl-argo-rollouts
      tag: ""
      pullPolicy: IfNotPresent
    service:
      type: ClusterIP
      portName: dashboard
      port: 3100
      targetPort: 3100
    serviceAccount:
      create: true
      name: "dasboard-argo-rollouts-sa"

    ingress:
      enabled: false
      annotations:
        istio.ingress.kubernetes.io/router.entrypoints: websecure
      ingressClassName: istio
      hosts:
        - argo-rollouts.opi5cluster.co.uk
      paths:
        - /
      pathType: Prefix
      tls:
        - secretName: opi5cluster-co-uk-domain-secret
          hosts:
            - argo-rollouts.opi5cluster.co.uk

  notifications:
    configmap:
      create: true

Manifests & templates

templates/http-route.yaml

Gateway API HTTPRoute exposing the service through the Istio gateway under opi5cluster.co.uk.

Show manifest 
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: {{ .Release.Namespace }}-httproute
  namespace: {{ .Release.Namespace }}
  annotations:
    link.argocd.argoproj.io/external-link: "https://argo-rollouts.opi5cluster.co.uk"
spec:
  parentRefs:
    - name: istio-gateway
      namespace: istio
      sectionName: websecure
  hostnames:
    - argo-rollouts.opi5cluster.co.uk
  rules:
    - backendRefs:
        - name: argo-rollouts-dashboard
          port: 3100

Trade-offs

Decision. Rollouts for services that need progressive delivery

Alternative. Plain rollingUpdate Deployments everywhere

Why. A canary catches a bad release before every replica gets it, at the cost of one CRD to learn.

← Back to GitOps & Delivery · All service groups