Deploying Argo Rollouts with Ambassador for Canary Releases on Kubernetes

Ambassador API Gateway integrates with Argo

Canary releases are a powerful strategy for reducing production risk by incrementally releasing a new version of software to subsets of a users. Imagine you roll out a v1.1 of your service, and it has a bug. Instead of exposing it to 100% of your traffic right away, you start the release process by exposing v1.1 to a subset of your traffic, e.g., 5%. Over time, you gradually ramp up the traffic up to 100%. During this period, any bugs that are exposed are limited to a subset of your users.

While simple in theory, utilizing canary releases in practice requires integrating your CI pipeline with a continuous deployment workflow such as Argo, along with an API Gateway to manage the flow of traffic to your services.

Ambassador API Gateway

Ambassador is an open source Kubernetes-native API Gateway and ingress controller built on Envoy Proxy. Common use cases for Ambassador include routing gRPC traffic, authentication, and rate limiting. While Ambassador supports the standard ingress class, most users use Ambassador mapping resources. Mapping resources define routes and support a broad set of attributes beyond the standard set supported in ingress. Here’s an example mapping:

apiVersion: getambassador.io/v2
kind:  Mapping
metadata:
  name:  echo
spec:
  prefix: /echo
  rewrite: /echo
  service: echo-stable:80

Canary Releases on Kubernetes

We’ve built a native integration (code) between Argo Rollouts and Ambassador. You can now create a Rollout resource that references an Ambassador mapping :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: echo-rollout
  annotations:
spec:
  replicas: 5
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
        - image: hashicorp/http-echo
          args:
            - "-text=VERSION 137"
            - -listen=:8080
          imagePullPolicy: Always
          name: echo-v1
          ports:
            - containerPort: 8080
  strategy:
    canary:
      stableService: echo-stable
      canaryService: echo-canary
      trafficRouting:
        ambassador:
          mapping: 
            - echo
      steps:
      - setWeight: 20
      - pause: {duration: 10s}
      - setWeight: 50
      - pause: {duration: 10s}
      - setWeight: 100
      - pause: {duration: 10}

Note the bolded section above, which references the Ambassador mapping resource named echo defined above. Applying these configurations to your cluster will start a rollout of the echo-canary service that will route 20% of traffic to the canary for 10 seconds, then ramp up to 50 seconds for 10 seconds, before ramping to 100%.

Getting Started

We’ve published a tutorial on how to deploy Argo Rollouts with Edge Stack. For now, this tutorial relies on an Ambassador version of Argo Rollouts. If you’re interested in tracking our progress in merging this functionality into upstream, you can check out the pull request. Please give it a try and let us know on Twitter or Slack how it works for you!