English version available

Cet article est le deuxième de la série consacrée à Flagger. En bref, Flagger est un outil de livraison progressive qui automatise le processus de livraison des applications s’exécutant sur Kubernetes. Il réduit le risque d’introduire une nouvelle version logicielle en production en augmentant progressivement le trafic vers la nouvelle version tout en mesurant les métriques et en exécutant des tests de conformité.

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 – Premiers pas avec Istio et Kubernetes.

Dans ce deuxième tutoriel, nous nous concentrerons sur l’installation de Flagger et lancerons plusieurs déploiements canary de l’application Mirror HTTP Server (MHS). N’oubliez pas que cette application très simple peut simuler des réponses valides ou invalides en fonction de la requête en entrée. C’est exactement ce dont nous avons besoin pour tester les capacités de Flagger. Nous couvrirons à la fois les scénarios type « happy path » (rollout) et « unhappy path » (rollback).

Installation de Flagger

Installons Flagger en exécutant ces commandes.

Nous installons Flagger dans son propre namespace flagger-system.

Référence: Installation de Flagger sur Kubernetes
Flagger dépend des métriques fournies par Istio et de Prometheus (dans notre cas, nous supposons qu’Istio est installé dans le namespace istio-system).
Tous les paramètres d’installation sont disponibles dans le fichier readme de Flagger sur GitHub.
Nous ne spécifions pas le numéro de version, ce qui signifie que l’on utilisera la dernière version disponible dans le repository (1.2.0 lorsque j’écris cet article).

Après quelques secondes, vous devriez recevoir un message confirmant que Flagger a été installé. Depuis le Kube dashboard, vérifiez qu’un nouveau namespace flagger-system a bien été créé et que le pod Flagger est en cours d’exécution.

Flagger est déployé dans votre cluster

Expérience 0 – Initialisation avec le déploiement canary de MHS v1.1.1

Mirror HTTP Server est disponible en plusieurs versions. Pour tester la fonctionnalité de déploiement canary de Flagger, nous basculerons entre la version 1.1.1, 1.1.2 et 1.1.3 de MHS (la dernière version lorsque j’écris cet article).

Avant de déployer MHS, créons un nouveau namespace application, nous ne voulons pas utiliser celui par défaut à la racine du cluster (c’est une bonne pratique). Le nom est un peu trop générique, mais suffisant pour ce tutoriel, en général vous utiliserez le nom de l’équipe ou le nom d’un regroupement de fonctionnalités.

N’oublions pas d’activer Istio sur ce nouveau namespace:

Pour déployer MHS via Flagger, j’ai créé un Helm chart.

Ce chart de « type canary » a été créé en se basant sur le chart précédent sans Flagger qui lui-même avait été créé avec la commande helm create mhs-chart, puis adapté. Dans ce chart de « type canary », j’ai fait quelques ajustements supplémentaires pour utiliser 2 répliquas au lieu de 1 pour rendre le déploiement plus réaliste et utiliser la version 1.1.1, j’ai également ajouté la ressource canary où la magie opère.

Clonez le repo contenant le chart:

Et installez MHS:

Après quelques instants, si vous regardez le tableau de bord, vous devriez voir 2 répliquas de MHS dans le namespace application.

MHS 1.1.1 est déployé dans votre cluster

Il est important de noter qu’aucune analyse canary n’a été effectuée et que la version a été automatiquement promue. Ce n’était pas un « vrai » déploiement canary.
Pourquoi? Parce que Flagger a besoin de s’initialiser la première fois que nous faisons un déploiement canary de l’application. Assurez-vous donc que la version que vous déployez avec Flagger la première fois est entièrement testée et fonctionne bien!
Vous pouvez également 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 évidemment une bonne raison, il est important de noter que, même si nous avions une version précédente auparavant (par exemple 1.1.0), la version canary 1.1.1 aurait aussi été automatiquement promue sans analyse.

Vous pouvez quand même consulter les événements canary avec:

Vous devriez avoir une sortie similaire sans analyse canary:

Ou vous pouvez également consulter directement les logs de Flagger:

Si vous regardez de plus près le tableau de bord Kube, vous devriez voir plusieurs ressources mhs et mhs-primary:

• mhs-primary sont les instances principales (c.-à-d. non canary). Flagger ajoute automatiquement le suffixe -primary pour les différencier des instances canary.
• mhs sont les instances canary. Elles n’existent que pendant le déploiement et disparaîtront une fois le déploiement canary terminé. C’est pourquoi, dans la capture d’écran ci-dessus, vous ne voyez pas de pod mhs canary (c.-à-d. 0/0 pod).

Pourquoi cette convention de nommage? J’ai demandé directement à l’équipe de Flagger et il y a une contrainte technique.

Flagger est maintenant correctement initialisé et MHS est déployé sur votre cluster. Vous pouvez utiliser le terminal pour confirmer que MHS est accessible (grâce à la Passerelle Istio):

Vous devriez recevoir une réponse HTTP 200 OK:

Et:

devrait retourner une réponse HTTP 500:

Expérience 1 – Déploiement canary de MHS v1.1.2

Nous allons installer une version plus récente 1.1.2. Vous devez éditer manuellement le fichier mhs-canary-chart/mhs/values.yaml et remplacer tag: 1.1.1 par tag: 1.1.2 (cette ligne).

Ensuite:

Alors que le déploiement canary est en cours, il est très important de générer du trafic vers MHS. Sans trafic, Flagger considérera que quelque chose s’est mal passé avec la nouvelle version et fera un rollback automatique pour retourner à la précédente version. Evidemment, vous n’aurez pas besoin de cette étape supplémentaire dans un environnement de production qui reçoit en permanence du trafic réel.

Exécutez cette commande dans un autre terminal pour générer ce trafic artificiel:

Vérifiez le Kube dashboard, vous devriez voir le pod canary avec la nouvelle version 1.1.2 à un moment donné:

MHS 1.1.2 en cours de déploiement canary dans votre cluster

Vérifiez les événements canary avec la même commande que précédemment:

Après un certain temps (environ 6 minutes), vous devriez avoir une sortie d’événements similaire:

La livraison canary s’est déroulée avec succès. Vous avez maintenant la version 1.1.2 installée sur tous les pods primary et le pod canary a été supprimé.

MHS 1.1.2 est déployé dans votre cluster

Pourquoi ce déploiement a-t-il duré environ 6 minutes? Parce qu’il inclut une analyse canary de 5 minutes. Au cours de cette analyse, le trafic a été augmenté de manière progressive vers le pod canary. Le trafic canary a augmenté de 10% toutes les 1 minute jusqu’à atteindre 50% du trafic global. L’analyse est configurable et définie dans le fichier canary.yaml qui a été ajouté au chart.

Voici la configuration de l’analyse:

  analysis:
    # intervalle entre chaque incrémentation de trafic et prises des mesures
    interval: 1m
    # pourcentage de trafic max routé vers le canary - pourcentage (0-100)
    maxWeight: 50
    # pas d'incrément canary - pourcentage (0-100)
    stepWeight: 10
    # nombre maximum d'échecs de vérification des métriques avant un rollback (global pour toutes les prises de mesures)
    threshold: 5
    metrics:
      - name: request-success-rate
        # pourcentage avant que le taux de réussite soit considéré comme ayant échoué (0-100)
        thresholdRange:
          min: 99
        # intervalle entre chaque prise de mesure de la métrique taux de réussite
        interval: 30s
      - name: request-duration
        # durée maximale P99 en millisecondes avant que le temps de réponse soit considéré comme ayant échoué
        thresholdRange:
          max: 500
        # intervalle entre chaque prise de mesure de la métrique temps de réponse
        interval: 30s

Notre analyse canary utilise les 2 métriques de base fournies par Istio / Prometheus (taux de réussite + temps de réponse). Il est possible de définir vos propres métriques personnalisées. Dans ce cas, elles devront être fournies par votre application. Votre application devra exposer un endpoint Prometheus qui inclura vos métriques personnalisées. Et vous pourrez mettre à jour la configuration de l’analyse de Flagger pour les utiliser avec votre propre requête PromQL. Notez que cela va au-delà de ce guide qui utilise uniquement les métriques de base.

Expérience 2 – Déploiement canary de MHS version v1.1.3

Encore une fois, vous devez éditer manuellement le fichier mhs-canary-chart/mhs/values.yaml et remplacer la ligne tag: 1.1.2 par tag: 1.1.3.

Ensuite:

Nous générons du trafic artificiel:

Cette fois, nous générons également du trafic non valide pour nous assurer que le taux de réussite des requêtes diminue!

Vérifiez les événements canary avec la même commande que précédemment:

Après un certain temps (environ 6 minutes), vous devriez avoir une sortie d’événements similaire:

Et vous êtes toujours sur la version 1.1.2.

Flagger a décidé de stopper et ne pas propager la version 1.1.3 car il n’a pas pu effectuer une analyse canary réussie et le seuil d’erreur a était atteint, 5 fois (en effet, à chaque fois, environ 50% des requêtes se sont terminées par une réponse HTTP 500). Flagger a simplement redirigé tout le trafic vers les instances primary et supprimé le pod canary.

Félicitations, vous êtes arrivé à la fin de ce deuxième tutoriel!

Observations

Avant de faire du nettoyage dans notre cluster, terminons par une liste d’observations:

• La suppression d’un déploiement supprimera tous les pods (canary / primary). Et nous ne nous retrouvons pas avec des ressources orphelines.
• Prometheus est un prérequis. Sans lui, l’analyse canary ne fonctionnera pas.
• Il n’est pas possible de relancer un déploiement canary sur la même version s’il vient d’échouer. Cela vous oblige à changer et incrémenter la version (même s’il s’agissait d’un problème de configuration et non d’un problème de code).
• Le processus de désactivation de Flagger n’est pas aussi simple que de supprimer la ressource canary du chart et de déployer une nouvelle version. Si vous supprimez la ressource canary, Flagger ne déclenchera pas le processus canary, il changera la version dans mhs et supprimera mhs-primary mais, mhs a 0 pod, ce qui rendra votre service indisponible! Vous devez être prudent et adopter un processus de désactivation manuelle approprié. Récement, l’équipe Flagger a ajouté une propriété revertOnDeletion que vous pouvez activer pour pallier à ce problème. Vous pouvez vous référer à la doc pour plus de détail sur ce canary finalizer.
• Après plusieurs déploiements, il semble que certains événements peuvent manquer, la commande Kubernetes describe les accumule (x<int> over <int>m) et parfois, l’ordre n’est pas conservé et/ou certains événements ne s’affichent pas. Vous pouvez consulter le statut Flagger concernant la phase du canary (les états finis sont Initialized, Succeeded ou Failed). Le mieux est de regarder directement les logs sur le pod Flagger, car elles sont toujours plus précises et complètes.
• L’analyse canary doit être configurée pour s’exécuter sur une courte période (c.-à-d. pas plus de 30 minutes) pour tirer profit d’un véritable déploiement continu et éviter de publier une nouvelle version alors qu’un déploiement canary pour la précédente est toujours en cours. Dans le cas où vous souhaitez tester une version canary sur plusieurs heures ou même jours, vous devriez peut-être repenser votre cas d’utilisation et Flagger pourrait ne pas être le meilleur choix.
• Nous l’avons déjà mentionné, mais c’est important: la première fois que vous déployez avec Flagger (comme avec l’expérience 0), l’outil doit s’initialiser (statut Initialized) et n’effectuera aucune analyse.

Nettoyage des ressources

Vous pouvez supprimer l’application MHS et son namespace.

Nous vous recommandons de laisser Flagger et Istio en place pour gagner du temps dans le prochain tutoriel. Si toutefois vous souhaitez tout supprimer maintenant, vous pouvez exécuter les commandes suivantes.

Supprimer Flagger:

Supprimer Istio et Prometheus:

Et après?

Le prochain article se concentrera sur le Tableau de bord Grafana fourni prêt à l’emploi par Flagger qui est un ajout intéressant. Il vous fera gagner du temps, car vous n’aurez pas besoin d’exécuter manuellement des commandes kuberctl pour vérifier le résultat de vos déploiements canary. Stay tuned! En attendant, vous pouvez arrêter le cluster Kubernetes en décochant la case et redémarrant Docker Desktop. Votre ordinateur peut prendre une pause bien méritée.

 English version available

Cette série d’articles est consacrée à Flagger, un outil qui s’intègre à l’écosystème de la plateforme d’orchestration de container Kubernetes pour faire des déploiements automatisés et sera un pas de plus en direction d’un processus de déploiement continu.

Cet article est le premier de la série et aussi celui qui aborde le moins Flagger… Il vous permettra de prendre en main Kubernetes sur votre environnement local en déployant une application qui sera accessible par l’intermédiaire d’une passerelle Istio.

Docker

Installez Docker en installant l’application Docker Desktop for Mac, vous pouvez vous référer au guide officiel d’installation. Pour les utilisateurs de Windows, l’application équivalente « Docker for Windows » existe.

Pour la suite, nous allons également utiliser Docker for Mac pour mettre en place le cluster Kubernetes en local. Notez que ce tutoriel a été testé avec Docker for Mac 2.4.0.0 qui embarque un cluster Kubernetes en version 1.18.8.

Si vous utilisez une version différente, la technologie évolue rapidement et je ne peux donc pas garantir que les commandes utilisées dans cette série d’articles fonctionneront sans ajustement.

Mirror HTTP Server

Quelques mots sur l’application Mirror HTTP Server que nous allons utiliser dans cette série d’articles.

MHS est une application JavaScript basée sur Node.js utilisant le framework Express très simple qui permet de personnaliser la réponse HTTP reçue en spécifiant des headers HTTP dans la requête. L’image Docker est disponible publiquement sur le Docker Hub. Vous pouvez consulter le repo Github du projet pour en savoir plus, notez que je n’en suis pas l’auteur.

Cette mini application est exactement ce dont nous avons besoin pour tester les capacités de Flagger pour simuler des réponses 200 OK et des réponses 500 Internal Server Error.

Récupérons l’image Docker:

Lançons un container qui l’utilise:

Puis testons son bon fonctionnement:

Vous devriez recevoir une réponse HTTP 200 OK:

Alors que:

retournera une réponse HTTP 500:

Pour plus de simplicité, nous utilisons la commande curl, mais vous pouvez utiliser votre outil préféré comme Postman.

Kubernetes

Maintenant que vous avez installé Docker for Mac, avoir un cluster Kubernetes qui tourne en local ne sera qu’une simple formalité. Il vous suffit de cocher une case!

Activer Kubernetes avec Docker for Mac

Si la lumière est verte, alors votre cluster Kubernetes a démarré avec succès. Attention, cela prend pas mal de ressources donc ne vous affolez pas si le ventilateur tourne à plein régime et que cela prend un peu de temps pour démarrer…

Kube dashboard

Nous allons installer notre première application dans notre cluster Kubernetes.

Kubernetes via Docker ne fournit pas Kube dashboard par défaut, vous devez l’installer vous-même. Ce tableau de bord est très pratique et donne une vision graphique de ce que se passe dans votre cluster et vous évitera d’avoir à saisir des commandes kubectl.

Le tableau de bord est protégé, mais vous pouvez utiliser l’utilisateur par défaut pour y accéder. Générez un token pour cet utilisateur:

Copiez le token.

Vous devrez réutiliser cette commande et / ou le token copié si votre session a expiré, cela se produit lorsque vous n’interagissez pas avec le tableau de bord pendant un petit moment.

Enfin, créer un proxy pour accéder au tableau de bord à partir du navigateur (cette commande devra s’exécuter indéfiniment):

Si vous accédez à http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/login et utilisez le token que vous avez copié pour vous authentifier, vous devriez voir cet écran.

Tableau de bord Kubernetes

Helm

Nous utilisons Homebrew pour l’installation de Helm. Homebrew est un gestionnaire de paquets très pratique disponible pour Mac.

Nous allons utiliser Helm pour installer Istio et l’application MHS dans notre cluster. Helm est un peu l’équivalent de Homebrew, mais pour Kubernetes. Nous utilisons la version 3. Helm vous évitera d’avoir à saisir de nombreuses commandes kubectl apply.

Installons Helm 3 avec:

Pour vérifier que Helm a bien été installé:

Vous devriez avoir en sortie (notez que Helm 3.3.4 est la dernière version au moment de la rédaction):

Istio & Prometheus

Maintenant, installons le Service Mesh Istio. Pour des explications et les avantages à utiliser un Service Mesh, je vous invite à lire la documentation officielle.

Tout d’abord, vous devez augmenter les limites de mémoire de votre Kubernetes via Docker, sinon vous allez rencontrer des problèmes de déploiement. Vos ventilateurs vont s’en remettre, ne vous inquiétez pas…

Voici ma configuration:

Configuration Kubernetes de Docker for Mac pour Istio

J’ai suivi les recommandations Docker Desktop pour Istio.

Passons à l’installation d’Istio 1.7.3 (la dernière version au moment de la rédaction). Tout d’abord, téléchargez les sources:

Ajoutez le client istioctl à votre path:

Installez Istio avec le client fourni, on utilise le profil de démo:

Après quelques minutes, vous devriez avoir un message confirmant qu’Istio a bien été installé. Et voilà!

Pour installer la dernière version d’Istio, vous pouvez simplement remplacer la première ligne par curl -L https://istio.io/downloadIstio | sh -.

Ajoutez Prometheus car c’est un prérequis pour Flagger:

A partir du tableau de bord Kube, vérifiez qu’un nouveau namespace a été créé istio-system et qu’il contient les outils Istio dont Prometheus.

Istio est déployé dans votre cluster

Pourquoi Prometheus est-il important? Car c’est un composant indispensable pour Flagger qui fournira les métriques pour montrer si la nouvelle version de votre application est en bonne santé ou non et ainsi la promouvoir ou au contraire faire un rollback. Je reviendrais en détail sur tout cela dans le prochain article.

Déploiement de Mirror HTTP Server

Avant de déployer MHS, créons un nouveau namespace application, nous ne voulons pas utiliser celui par défaut à la racine du cluster (c’est une bonne pratique). Le nom est un peu trop générique, mais suffisant pour ce tutoriel, en général vous utiliserez le nom de l’équipe ou le nom d’un regroupement de fonctionnalités.

N’oublions pas d’activer Istio sur ce nouveau namespace:

Pour déployer MHS, j’ai créé un Helm chart.

Ce chart a été créé avec la commande helm create mhs-chart, que j’ai ensuite adapté pour récupérer la dernière image de MHS. J’ai également ajouté un fichier gateway.yaml pour la configuration de la passerelle Istio afin que l’application soit accessible en dehors du cluster.

Clonez le repo contenant le chart:

Et installez MHS:

Après quelques instants, si vous regardez le tableau de bord, vous devriez voir 1 replica de MHS dans le namespace application.

MHS est déployé dans votre cluster

Vous avez maintenant 1 pod de MHS en cours d’exécution dans votre cluster Kubernetes. Le pod est exposé au monde extérieur via une passerelle Istio.

Pour tester, utilisons les commandes similaires précédemment utilisées contre le container docker:

Vous devriez recevoir une réponse HTTP 200 OK qui a été manipulé par le composant Envoy, le proxy utilisé par Istio:

Et:

devrait retourner une réponse HTTP 500:

Félicitations, vous êtes arrivé à la fin de ce premier tutoriel!

Pour information, vous pouvez également accéder à MHS avec votre navigateur préféré si vous exécutez d’abord une commande proxy pour exposer le pod:

export POD_NAME=$(kubectl get pods --namespace application -l "app.kubernetes.io/name=mhs,app.kubernetes.io/instance=mhs" -o jsonpath="{.items[0].metadata.name}")

kubectl port-forward --namespace application $POD_NAME 8080:80

Ensuite, accédez à http://localhost:8080/.

Vous devriez voir une… page blanche. C’est normal, MHS ne renvoie aucun body dans la réponse, il n’y a aucune sortie HTML!

Nettoyage des ressources

Vous pouvez supprimer l’application MHS et son namespace.

Nous ne supprimons pas Istio / Prometheus car nous en aurons besoin dans le prochain article, mais si vous souhaitez libérer des ressources, vous pouvez utiliser ces commandes:

Et après?

Le prochain article détaillera l’installation de Flagger et son utilisation via des déployments de type « canary release » de différentes versions de MHS. Stay tuned! En attendant, vous pouvez arrêter le cluster Kubernetes en décochant la case et redémarrant Docker Desktop. Votre ordinateur peut prendre une pause méritée.