A simple and secure way to automate canary deployments with Helm

Canary deployment is a very efficient way to test new code on a subset of users. It greatly reduces the traffic load that can be problematic during the deployment process, as it only occurs within a certain subgroup. This note is about how to organize such a deployment using Kubernetes and deployment automation. This assumes you have some knowledge of Helm and Kubernetes resources..



A simple canary deployment to Kubernetes includes two key resources: the service itself and the deployment tool. Canary deployment works through a single service that communicates with two different resources serving update traffic. One of these resources will work with the "canary" version, and the second - with the stable one. In this situation, we can adjust the number of canary versions in order to reduce the amount of traffic required for maintenance. If, for example, you prefer to use Yaml, then it would look like this in Kubernetes:

kind: Deployment
metadata:
  name: app-canary
  labels:
    app: app
spec:
  replicas: 1
  ...
    image: myapp:canary
---
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  replicas: 5
  ...
    image: myapp:stable
---
kind: Service
selector:
  app: app # Selector will route traffic to both deployments.

It is even easier to imagine such an option on kubectl, and in documentation for Kubernetes there is even a full tutorial on this scenario. But the main question of this post is how we are going to automate this process using Helm.

Canary Deployment Automation

First of all, we need a Helm chart map, which already contains the resources discussed above. It should look something like this:

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

The basis of the Helm concept is the management of multiversion releases. The stable version is our main stable code branch for the project. But with the help of Helm, we can deploy the canary release with our experimental code. The main thing is to keep the traffic exchange between the stable version and the canary release. We will manage all this using a special selector:

selector:
  app.kubernetes.io/name: myapp

Our both "canary" and stable deployment resources will indicate this label on the modules. If everything is configured correctly, then during the deployment of the canary version of our Helm chart map, we will see that the traffic will be directed to the freshly deployed modules. The stable version of this command would look like this:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v1       # Goes into app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Now let's check out our canary release. To deploy the canary version, we need to remember two things. The name of the release must be different so that we do not update the current stable version. The version and tag must also be different so that we can deploy other code and identify differences in resource tags.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v2       # Goes into app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

That, in fact, is all! If you ping the service, you can see that the canary update only routes traffic part of the time.

If you are looking for deployment automation tools that include the described logic, then take a look at deliverybot and Helm automation tools on GitHub. The Helm charts used to implement the method described above are on Github, here. In general, it was a theoretical overview of how to implement deployment automation of canary versions in practice, with specific concepts and examples.

Source: habr.com