Argo Rollouts, the Kubernetes Progressive Delivery Controller, Reaches 1.0 Milestone

Argo Rollouts, part of the Argo project, recently released their 1.0 version. You can see the changelog and more details on the Github release page.

If you are not familiar with Argo Rollouts, it is a Kubernetes Controller that deploys applications on your cluster. It replaces the default rolling-update strategy of Kubernetes with more advanced deployment methods such as blue/green and canary deployments.

In addition, it supports integration with several metrics providers to automatically promote/roll back your deployment according to live metrics.

We have already covered some example scenarios in previous blog posts:

• Blue/Green deployments with Smoke tests
• Canary deployments with Prometheus

We also have a dedicated documentation page with more scenarios.

New graphical user interface

The most user-visible feature in the 1.0 release is the introduction of a dedicated graphical user interface. Previously, you could monitor the status of a rollout from the command line or see status health with the ArgoCD dashboard.

In this release, Argo Rollouts includes its user interface:

The GUI includes all the information you need about a rollout:

• Current deployment strategy
• Total number of steps and current deployment step
• Current status of the rollout (paused, progressing, degraded, etc.)
• Number of replicas for the previous and current deployment
• Container images for the previous and current deployment

Note that unlike ArgoCD, where the interface is part of the controller, in Argo Rollouts the interface is launched from the CLI and runs on your machine.

You can still use the CLI to monitor deployments as well:

Similar information is offered both ways.

Use existing Kubernetes Deployment objects

Argo Rollouts works by monitoring changes in a Kubernetes custom resource aptly named Rollout.

You can see the full details on the Rollout Specification page. The Rollout resource is compatible with the standard Deployment resource but includes extra fields that define the progressive delivery options.

This means that until recently if you wanted to use Argo Rollouts, you had to convert your existing Deployment objects to Rollouts. The process was not very difficult, but it was challenging for Argo Rollouts to cooperate with other Kubernetes tools that only understand Deployments.

With the 1.0 release, Argo Rollouts also supports an alternative format for Rollouts. You can now keep all Rollout specific information in the custom CRD and just mention an existing deployment:

apiVersion: argoproj.io/v1alpha1               # Create a rollout resource
kind: Rollout
metadata:
  name: rollout-ref-deployment
spec:
  replicas: 5
  workloadRef:                                 # Reference an existing Deployment using workloadRef field
    apiVersion: apps/v1
    kind: Deployment
    name: rollout-ref-deployment
  strategy:
    canary:
      steps:
        - setWeight: 20
        - pause: {duration: 10s}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/instance: rollout-canary
  name: rollout-ref-deployment
spec:
  replicas: 0                                  # Scale down existing deployment
  selector:
    matchLabels:
      app: rollout-ref-deployment
  template:
    metadata:
      labels:
        app: rollout-ref-deployment
    spec:
      containers:
        - name: rollouts-demo
          image: argoproj/rollouts-demo:blue
          imagePullPolicy: Always
          ports:
            - containerPort: 8080

This means that you can still use all your favorite tools with Argo Rollouts, even those that do not understand CRDs.

See the documentation page for more details.

Official container image with the CLI

Codefresh pipelines are based on containers. Each step in a Codefresh pipeline is a docker image that is created either by you or loaded by an existing registry (private or public).

Previously, we had to maintain our container image for Argo Rollouts to integrate with container-based pipelines.

This is no longer necessary because Argo Rollouts released an official container image with the CLI.

You can find all image releases at https://quay.io/repository/argoproj/kubectl-argo-rollouts

Ambassador support for traffic splitting

In the case of canaries, Argo Rollouts supports several networking solutions for splitting live traffic between the previous and current versions in a gradual way.

With the 1.0, Ambassador Edge Stack is now added as an official provider for traffic routing. This means that you can use Ambassador for canary releases in addition to the other already supported solutions.

This feature is also a testament to the fact that Argo Rollouts does not need a full service mesh to gradually shift traffic.

Ambassador Edge Stack of course has several other features that are useful to have on a Kubernetes cluster (ingress services, SSO, external authentication, etc.) on their own.

Start your progressive delivery journey now

The 1.0 release contains several fixes and features. Some highlights are:

• Dedicated status CLI command
• support scaleDownDelaySeconds in canary
• New RolloutCompleted condition
• metric fields can be parameterized
• ARM builds

Get started now by following the installation instructions.