{"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\/fr\/2020\/05\/19\/flagger-canary-deployments-on-kubernetes\/","title":{"rendered":"Flagger – D\u00e9ploiements Canary sur Kubernetes"},"content":{"rendered":"

 <\/span>English version available<\/strong><\/a><\/p>\n

Mise \u00e0 jour<\/strong>
\n17 Octobre 2020 : <\/strong> Utilisation de versions plus r\u00e9centes (Helm 3, Kube 18, Istio 1.7, Flagger 1.2).\n<\/div>\n

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

Cet article est le deuxi\u00e8me de la s\u00e9rie consacr\u00e9e \u00e0 Flagger<\/a>. En bref, Flagger est un outil de livraison progressive qui automatise le processus de livraison des applications s’ex\u00e9cutant sur Kubernetes. Il r\u00e9duit le risque d’introduire une nouvelle version logicielle en production en augmentant progressivement le trafic vers la nouvelle version tout en mesurant les m\u00e9triques et en ex\u00e9cutant des tests de conformit\u00e9.<\/p>\n

Assurez-vous d’avoir un cluster Kubernetes avec le service mesh Istio qui tourne sur votre machine en local. Sinon, lisez le premier article: Flagger \u2013 Premiers pas avec Istio et Kubernetes<\/a>.<\/p>\n

Dans ce deuxi\u00e8me tutoriel, nous nous concentrerons sur l’installation de Flagger et lancerons plusieurs d\u00e9ploiements canary de l’application Mirror HTTP Server<\/a> (MHS). N’oubliez pas que cette application tr\u00e8s simple peut simuler des r\u00e9ponses valides ou invalides en fonction de la requ\u00eate en entr\u00e9e. C’est exactement ce dont nous avons besoin pour tester les capacit\u00e9s de Flagger. Nous couvrirons \u00e0 la fois les sc\u00e9narios type \u00ab\u00a0happy path\u00a0\u00bb (rollout) et \u00ab\u00a0unhappy path\u00a0\u00bb (rollback).<\/p>\n

Remarque<\/strong>
\nCe guide est un \u00ab\u00a0hands-on\u00a0\u00bb et peut \u00eatre suivi pas \u00e0 pas par les utilisateurs sous MacOS. Il n\u00e9cessitera quelques ajustements si vous utilisez un PC sous Windows ou Linux. Il est important de signaler que cet article ne s’attardera pas sur les concepts et technologies en d\u00e9tail donc si vous n’\u00eates pas familier avec Docker, Kubernetes, Helm ou Istio, je vous conseille fortement de vous documenter avant de poursuivre votre lecture.\n<\/div>\n


<\/p>\n

Installation de Flagger<\/h4>\n

Installons Flagger en ex\u00e9cutant ces commandes.<\/p>\n\n

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

Nous installons Flagger dans son propre 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

\nR\u00e9f\u00e9rence: Installation de Flagger sur Kubernetes<\/a>
\nFlagger d\u00e9pend des m\u00e9triques fournies par Istio et de Prometheus (dans notre cas, nous supposons qu’Istio est install\u00e9 dans le namespace istio-system<\/code>).
\nTous les param\u00e8tres d’installation sont disponibles dans le fichier readme de Flagger sur GitHub<\/a>.
\nNous ne sp\u00e9cifions pas le num\u00e9ro de version, ce qui signifie que l’on utilisera la derni\u00e8re version disponible dans le repository (1.2.0<\/code> lorsque j’\u00e9cris cet article).\n<\/p><\/blockquote>\n

Apr\u00e8s quelques secondes, vous devriez recevoir un message confirmant que Flagger a \u00e9t\u00e9 install\u00e9. Depuis le Kube dashboard, v\u00e9rifiez qu’un nouveau namespace flagger-system<\/code> a bien \u00e9t\u00e9 cr\u00e9\u00e9 et que le pod Flagger est en cours d’ex\u00e9cution.<\/p>\n

\"Flagger<\/a>

Flagger est d\u00e9ploy\u00e9 dans votre cluster<\/p><\/div>\n


<\/p>\n

Exp\u00e9rience 0 – Initialisation avec le d\u00e9ploiement canary de MHS v1.1.1<\/h4>\n

Mirror HTTP Server est disponible en plusieurs versions<\/a>. Pour tester la fonctionnalit\u00e9 de d\u00e9ploiement canary de Flagger, nous basculerons entre la version 1.1.1<\/code>, 1.1.2<\/code> et 1.1.3<\/code> de MHS (la derni\u00e8re version lorsque j’\u00e9cris cet article).<\/p>\n

Avant de d\u00e9ployer MHS, cr\u00e9ons un nouveau namespace application<\/code>, nous ne voulons pas utiliser celui par d\u00e9faut \u00e0 la racine du cluster (c’est une bonne pratique). Le nom est un peu trop g\u00e9n\u00e9rique, mais suffisant pour ce tutoriel, en g\u00e9n\u00e9ral vous utiliserez le nom de l’\u00e9quipe ou le nom d’un regroupement de fonctionnalit\u00e9s.<\/p>\n\n

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

N’oublions pas d’activer Istio sur ce nouveau namespace:<\/p>\n\n

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

Pour d\u00e9ployer MHS via Flagger, j’ai cr\u00e9\u00e9 un Helm chart<\/a>.<\/p>\n

Ce chart de \u00ab\u00a0type canary\u00a0\u00bb<\/a> a \u00e9t\u00e9 cr\u00e9\u00e9 en se basant sur le chart pr\u00e9c\u00e9dent sans Flagger<\/a> qui lui-m\u00eame avait \u00e9t\u00e9 cr\u00e9\u00e9 avec la commande helm create mhs-chart<\/code>, puis adapt\u00e9. Dans ce chart de \u00ab\u00a0type canary\u00a0\u00bb, j’ai fait quelques ajustements suppl\u00e9mentaires pour utiliser 2 r\u00e9pliquas au lieu de 1 pour rendre le d\u00e9ploiement plus r\u00e9aliste et utiliser la version 1.1.1<\/code><\/a>, j’ai \u00e9galement ajout\u00e9 la ressource canary<\/a> o\u00f9 la magie op\u00e8re.<\/p>\n

Clonez le repo contenant le chart:<\/p>\n\n

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

Et installez MHS:<\/p>\n\n

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

Apr\u00e8s quelques instants, si vous regardez le tableau de bord, vous devriez voir 2 r\u00e9pliquas de MHS dans le namespace application<\/code>.<\/p>\n

\"MHS<\/a>

MHS 1.1.1 est d\u00e9ploy\u00e9 dans votre cluster<\/p><\/div>\n

\nIl est important de noter qu’aucune analyse canary n’a \u00e9t\u00e9 effectu\u00e9e et que la version a \u00e9t\u00e9 automatiquement promue. Ce n’\u00e9tait pas un \u00ab\u00a0vrai\u00a0\u00bb d\u00e9ploiement canary.
\nPourquoi? Parce que Flagger a besoin de s’initialiser la premi\u00e8re fois que nous faisons un d\u00e9ploiement canary de l’application. Assurez-vous donc que la version que vous d\u00e9ployez avec Flagger la premi\u00e8re fois est enti\u00e8rement test\u00e9e et fonctionne bien!
\nVous pouvez \u00e9galement penser que cette promotion automatique s’est produite, car il n’y avait pas de version initiale de l’application dans le cluster. Bien que ce soit \u00e9videmment une bonne raison, il est important de noter que, m\u00eame si nous avions une version pr\u00e9c\u00e9dente auparavant (par exemple 1.1.0<\/code>), la version canary 1.1.1<\/code> aurait aussi \u00e9t\u00e9 automatiquement promue sans analyse.\n<\/p><\/blockquote>\n

Vous pouvez quand m\u00eame consulter les \u00e9v\u00e9nements canary avec:<\/p>\n\n

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

Vous devriez avoir une sortie similaire sans analyse canary:<\/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

Ou vous pouvez \u00e9galement consulter directement les logs de 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

Si vous regardez de plus pr\u00e8s le tableau de bord Kube, vous devriez voir plusieurs ressources mhs<\/code> et mhs-primary<\/code>:<\/p>\n