{"id":5131,"date":"2020-05-19T19:56:08","date_gmt":"2020-05-19T18:56:08","guid":{"rendered":"https:\/\/blog.fabianpiau.com\/?p=5131"},"modified":"2021-01-14T14:58:54","modified_gmt":"2021-01-14T14:58:54","slug":"flagger-canary-deployments-on-kubernetes","status":"publish","type":"post","link":"https:\/\/blog.fabianpiau.com\/en\/2020\/05\/19\/flagger-canary-deployments-on-kubernetes\/","title":{"rendered":"Flagger – Canary deployments on Kubernetes"},"content":{"rendered":"

 <\/span>Version fran\u00e7aise disponible<\/strong><\/a><\/p>\n

Update<\/strong>
\nOctober, 17th, 2020 : <\/strong> Use newer versions (Helm 3, Kube 18, Istio 1.7, Flagger 1.2).\n<\/div>\n

\"Flagger<\/a><\/p>\n

This article is the second one of the series dedicated to Flagger<\/a>. In a nutshell, Flagger is a progressive delivery tool that automates the release process for applications running on Kubernetes. It reduces the risk of introducing a new software version in production by gradually shifting traffic to the new version while measuring metrics and running conformance tests.<\/p>\n

Make sure you have a local Kubernetes cluster running with the service mesh Istio. If you don’t, read the first article: Flagger \u2013 Get Started with Istio and Kubernetes<\/a>.<\/p>\n

In this second guide, we will focus on the installation of Flagger and run multiple canary deployments of the application Mirror HTTP Server<\/a> (MHS). Remember that this dummy application can simulate valid and invalid responses based on the request. This is exactly what we need to test the capabilities of Flagger. We will cover both happy (rollout) and unhappy (rollback) scenarios.<\/p>\n

Note<\/strong>
\nThis is a hands-on guide and can be followed step by step on MacOS. It will require some adjustments if you are using a Windows or Linux PC. It is important to note that this article will not go into details and only grasp the concepts & technologies so if you are not familiar with Docker, Kubernetes, Helm or Istio, I strongly advise you to check some documentation yourself before continuing reading.\n<\/div>\n


<\/p>\n

Installing Flagger<\/h4>\n

Let’s install Flagger by running these commands.<\/p>\n\n

<\/span> kubectl<\/span> create ns flagger-system
<\/div>\n\n

We install Flagger in its own namespace flagger-system<\/code>.<\/p>\n\n

<\/span> helm<\/span> repo add flagger https:\/\/flagger.app
<\/span>
<\/span> kubectl<\/span> apply -f https:\/\/raw.githubusercontent.com\/weaveworks\/flagger\/master\/artifacts\/flagger\/crd.yaml
<\/span>
<\/span> helm<\/span> upgrade -i flagger flagger\/flagger \\
--namespace=flagger-system \\
--set crd.create=false \\
--set meshProvider=istio \\
--set metricsServer=http:\/\/prometheus.istio-system:9090
<\/div>\n\n

\nReference: Flagger Install on Kubernetes<\/a>
\nFlagger depends on Istio telemetry and Prometheus (in that case, we assume Istio is installed in the istio-system<\/code> namespace).
\nAll parameters are available on the Flagger readme file on GitHub<\/a>.
\nWe don’t specify a version for Flagger, which means it will use the latest available in the repo (1.2.0<\/code> at the time of writing).\n<\/p><\/blockquote>\n

After a few seconds, you should get a message confirming that Flagger has been installed. From the Kube dashboard, verify that a new namespace has been created flagger-system<\/code> and the Flagger pod is running.<\/p>\n

\"Flagger<\/a>

Flagger is deployed in your cluster<\/p><\/div>\n


<\/p>\n

Experiment 0 – Initialize Flagger with MHS v1.1.1<\/h4>\n

Mirror HTTP Server has multiple versions available<\/a>. To play with Flagger canary deployment feature, we will switch between version 1.1.1<\/code>, 1.1.2<\/code> and 1.1.3<\/code> of MHS (the latest version at the time of writing).<\/p>\n

Before deploying MHS, let’s create a new namespace application<\/code>, we don’t want to use the default one at the root of the cluster (this is good practice). The name is too generic, but sufficient for this tutorial, in general you will use the name of the team or the name of a group of features.<\/p>\n\n

<\/span> kubectl<\/span> create ns application
<\/div>\n\n

Do not forget to activate Istio on this new namespace:<\/p>\n\n

<\/span> kubectl<\/span> label namespace application istio-injection=enabled
<\/div>\n\n

To deploy MHS via Flagger, I created a Helm chart<\/a>.<\/p>\n

This “canary flavored” chart<\/a> was created based on the previous chart without Flagger<\/a> which itself was created with the helm create mhs-chart<\/code> command, then adapted. In this “canary flavored” chart, I did some extra adaptation to use 2 replicas instead of 1 to make it more realistic and use a fixed version to 1.1.1<\/code><\/a>, I also added the canary resource<\/a> where the magic happens.<\/p>\n

Clone the chart repo:<\/p>\n\n

<\/span> git<\/span> clone https:\/\/github.com\/fabianpiau\/mhs-canary-chart.git
<\/div>\n\n

And install MHS:<\/p>\n\n

<\/span> cd<\/span> mhs-canary-chart
helm install --name mhs --namespace application .\/mhs
<\/div>\n\n

After a few moments, if you look at the dashboard, you should see 2 replicas of MHS in the namespace application<\/code>.<\/p>\n

\"MHS<\/a>

MHS 1.1.1 is deployed in your cluster<\/p><\/div>\n

\nIt is important to note that no canary analysis has been performed and the version has been automatically promoted. It was not a “real” canary release.
\nWhy? Because Flagger needs to initialize itself the first time we do a canary deployment of the application. So make sure the version you are deploying with Flagger the first time is fully tested and works well!
\nYou could also guess this auto-promotion happened because there was no initial version of the application in the cluster. Although this is obviously a good reason, it’s important to note that, even if we had a previous version before (e.g. 1.1.0<\/code>), the canary version 1.1.1<\/code> would have still been automatically promoted without analysis.\n<\/p><\/blockquote>\n

You can still check the canary events with:<\/p>\n\n

<\/span> kubectl<\/span> -n application describe canary\/mhs
<\/div>\n\n

You should have a similar output without a canary analysis:<\/p>\n\n

<\/span> Events<\/span>:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Synced 2m29s flagger mhs-primary.application not ready: waiting for rollout to finish: observed deployment generation less then desired generation
Normal Synced 92s (x2 over 2m30s) flagger all the metrics providers are available!
Normal Synced 92s flagger Initialization done! mhs.application
<\/div>\n\n

Or you can also directly check the log from Flagger:<\/p>\n\n

<\/span> export<\/span> FLAGGER_POD_NAME=$(kubectl<\/span> get pods --namespace flagger-system -l \"app.kubernetes.io\/name=flagger,app.kubernetes.io\/instance=flagger\"<\/span> -o jsonpath=\"{.items[0<\/span>].metadata.name}\")
<\/span>
<\/span> kubectl<\/span> -n flagger-system logs $FLAGGER_POD_NAME<\/span>
<\/div>\n\n

If you take a closer look at the Kube dashboard, you should see some mhs<\/code> and mhs-primary<\/code> resources:<\/p>\n