Progressive Delivery with FluxCD

Progressive delivery is a modern software deployment strategy that enables platform engineers to release new features to a subset of users before rolling them out to the entire user base. This approach helps to reduce the risk of deploying new features and allows for faster feedback loops. In this blog post, we will explore how to implement progressive delivery using FluxCD, an open-source GitOps tool for Kubernetes.

Prerequisites

Before we dive into the technical details, let's review the prerequisites for implementing progressive delivery with FluxCD:

1. A Kubernetes cluster with FluxCD installed and configured.
2. A Git repository that contains your application's manifests and configuration files.
3. A tool for traffic management, such as Istio or NGINX.

Implementing Progressive Delivery with FluxCD

To implement progressive delivery with FluxCD, we will use a combination of FluxCD's automated deployment capabilities and a traffic management tool to route traffic to different versions of our application. Here are the steps to follow:

Step 1: Define the Progressive Delivery Strategy

The first step is to define the progressive delivery strategy for your application. This strategy should specify the percentage of users that will receive the new feature and the criteria for promoting the feature to a larger audience. For example, you might decide to release the new feature to 10% of users initially and gradually increase the percentage based on feedback and performance metrics.

Step 2: Create a Canary Deployment

Once you have defined the progressive delivery strategy, the next step is to create a canary deployment. A canary deployment is a deployment of a new version of your application that is used to test the new feature with a small subset of users. To create a canary deployment with FluxCD, you can use the Helm operator to deploy a Helm chart that contains the new version of your application.

Here's an example Helm chart that deploys a canary version of an application:

apiVersion: helm.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: my-app-canary
  namespace: my-namespace
spec:
  releaseName: my-app-canary
  chart:
    repository: https://charts.example.com
    name: my-app
    version: 2.0.0
  values:
    image:
      tag: canary
    replicas: 1

In this example, we are deploying a Helm chart named my-app version 2.0.0 from a chart repository located at https://charts.example.com. We are also specifying a values file that sets the image tag to canary and the number of replicas to 1.

Step 3: Configure Traffic Management

Once the canary deployment is up and running, the next step is to configure traffic management to route traffic to the new version of the application. This can be done using a traffic management tool such as Istio or NGINX.

For example, if you are using Istio, you can create a virtual service that routes traffic to the canary deployment based on the progressive delivery strategy. Here's an example virtual service configuration:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
  namespace: my-namespace
spec:
  hosts:
  - my-app
  http:
  - route:
    - destination:
        host: my-app-canary
        subset: canary
      weight: 10
    - destination:
        host: my-app
      weight: 90

In this example, we are creating a virtual service named my-app in the my-namespace namespace. We are also defining two destinations: one for the canary deployment (my-app-canary) and one for the stable deployment (my-app). We are using the subset field to specify that traffic should be routed to the canary subset of the canary deployment. Finally, we are using the weight field to specify that 10% of traffic should be routed to the canary deployment and 90% of traffic should be routed to the stable deployment.

Step 4: Monitor and Promote the Canary Deployment

Once traffic is being routed to the canary deployment, the next step is to monitor the deployment and gather feedback from users. This can be done using tools such as Prometheus and Grafana for monitoring metrics and logs, and user feedback tools such as UserVoice or Intercom.

If the canary deployment is performing well and users are providing positive feedback, you can promote the canary deployment to a larger audience by increasing the percentage of traffic routed to the canary deployment. This can be done by updating the virtual service configuration to increase the weight of the canary deployment.

Conclusion

In this blog post, we have explored how to implement progressive delivery using FluxCD and a traffic management tool. By following the steps outlined in this guide, platform engineers can reduce the risk of deploying new features and enable faster feedback loops. While this approach requires some additional configuration and tooling, the benefits of progressive delivery make it a valuable addition to any modern software delivery pipeline.