Agilité, Développement Java, Nouvelles technologies et plus…
  • rss
  • Accueil
  • Management
  • Programmation agile
  • Technologie
  • Linux
  • Evénement
  • App Android
  • Contact
  • A propos de l'auteur
  • English
  • Francais

Flagger – Déploiements Canary sur Kubernetes

Fabian Piau | mardi 19 mai 2020 - 19:56
  • Imprimer
  • Twitter
  • LinkedIn
  • Facebook
  • Pocket

 English version available

Mise à jour
17 Octobre 2020 : Utilisation de versions plus récentes (Helm 3, Kube 18, Istio 1.7, Flagger 1.2).

Logo Flagger

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).

Remarque
Ce guide est un « hands-on » et peut être suivi pas à pas par les utilisateurs sous MacOS. Il nécessitera 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étail donc si vous n’êtes pas familier avec Docker, Kubernetes, Helm ou Istio, je vous conseille fortement de vous documenter avant de poursuivre votre lecture.


Installation de Flagger

Installons Flagger en exécutant ces commandes.

kubectl create ns flagger-system

Nous installons Flagger dans son propre namespace flagger-system.

helm repo add flagger https://flagger.app

kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml

helm upgrade -i flagger flagger/flagger \
--namespace=flagger-system \
--set crd.create=false \
--set meshProvider=istio \
--set metricsServer=http://prometheus.istio-system:9090

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

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.

kubectl create ns application

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

kubectl label namespace application istio-injection=enabled

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:

git clone https://github.com/fabianpiau/mhs-canary-chart.git

Et installez MHS:

cd mhs-canary-chart
helm install --name mhs --namespace application ./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

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:

kubectl -n application describe canary/mhs

Vous devriez avoir une sortie similaire sans analyse canary:

Events:
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

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

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

kubectl -n flagger-system logs $FLAGGER_POD_NAME

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):

curl -I -H Host:mhs.example.com 'http://localhost'

Vous devriez recevoir une réponse HTTP 200 OK:

HTTP/1.1 200 OK
x-powered-by: Express
date: Sun, 17 May 2020 16:47:33 GMT
x-envoy-upstream-service-time: 10
server: istio-envoy
transfer-encoding: chunked

Et:

curl -I -H Host:mhs.example.com -H X-Mirror-Code:500 'http://localhost'

devrait retourner une réponse HTTP 500:

HTTP/1.1 500 Internal Server Error
x-powered-by: Express
date: Sun, 17 May 2020 16:48:09 GMT
x-envoy-upstream-service-time: 12
server: istio-envoy
transfer-encoding: chunked


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:

cd mhs-canary-chart
helm upgrade mhs --namespace application ./mhs

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:

while (true); do curl -I -H Host:mhs.example.com 'http://localhost' ; sleep 0.5 ; done

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

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:

kubectl -n application describe canary/mhs

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

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Synced 30m flagger mhs-primary.application not ready: waiting for rollout to finish: observed deployment generation less then desired generation
Normal Synced 29m (x2 over 30m) flagger all the metrics providers are available!
Normal Synced 29m flagger Initialization done! mhs.application
Normal Synced 10m flagger New revision detected! Scaling up mhs.application
Normal Synced 9m16s flagger Starting canary analysis for mhs.application
Normal Synced 9m16s flagger Advance mhs.application canary weight 10
Normal Synced 8m16s flagger Advance mhs.application canary weight 20
Normal Synced 7m16s flagger Advance mhs.application canary weight 30
Normal Synced 6m16s flagger Advance mhs.application canary weight 40
Normal Synced 5m16s flagger Advance mhs.application canary weight 50
Normal Synced 4m16s flagger Copying mhs.application template spec to mhs-primary.application
Normal Synced 3m16s flagger Routing all traffic to primary
Normal Synced 2m16s flagger (combined from similar events): Promotion completed! Scaling down mhs.application

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

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:

cd mhs-canary-chart
helm upgrade mhs --namespace application ./mhs

Nous générons du trafic artificiel:

while (true); do curl -I -H Host:mhs.example.com 'http://localhost' ; curl -I -H Host:mhs.example.com -H X-Mirror-Code:500 'http://localhost' ; sleep 0.5 ; done

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:

kubectl -n application describe canary/mhs

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

Normal Synced 8m23s (x2 over 20m) flagger New revision detected! Scaling up mhs.application
Normal Synced 7m23s (x2 over 19m) flagger Advance mhs.application canary weight 10
Normal Synced 7m23s (x2 over 19m) flagger Starting canary analysis for mhs.application
Warning Synced 6m23s flagger Halt mhs.application advancement success rate 57.14% < 99%
Warning Synced 5m24s flagger Halt mhs.application advancement success rate 0.00% < 99%
Warning Synced 3m24s flagger Halt mhs.application advancement success rate 71.43% < 99%
Warning Synced 2m24s flagger Halt mhs.application advancement success rate 50.00% < 99%
Warning Synced 84s flagger Halt mhs.application advancement success rate 63.64% < 99%
Warning Synced 24s flagger Rolling back mhs.application failed checks threshold reached 5
Warning Synced 24s flagger Canary failed! Scaling down mhs.application

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.

helm delete mhs --namespace application

kubectl delete namespaces application

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:

helm delete flagger --namespace flagger-system

kubectl delete namespaces flagger-system

Supprimer Istio et Prometheus:

kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.7/samples/addons/prometheus.yaml

istioctl manifest generate --set profile=demo | kubectl delete -f -

kubectl delete namespaces istio-system


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.

Articles similaires

kubernetesFlagger – Premiers pas avec Istio et Kubernetes kubernetesFlagger – Monitorer vos déploiements Canary avec Grafana
Commentaires
Pas de Commentaires »
Catégories
Programmation agile
Tags
cloud, docker, flagger, helm, istio, kubernetes
Flux rss des commentaires Flux rss des commentaires

Flagger – Premiers pas avec Istio et Kubernetes

Fabian Piau | samedi 2 mai 2020 - 18:40
  • Imprimer
  • Twitter
  • LinkedIn
  • Facebook
  • Pocket

 English version available

Mise à jour
17 Octobre 2020 : Utilisation de versions plus récentes (Helm 3, Kube 18, Istio 1.7).

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.

Remarque
Ce guide est un « hands-on » et peut être suivi pas à pas par les utilisateurs sous MacOS. Il nécessitera 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étail donc si vous n’êtes pas familier avec Docker, Kubernetes, Helm ou Istio, je vous conseille fortement de vous documenter avant de poursuivre votre lecture.


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:

docker pull eexit/mirror-http-server

Lançons un container qui l’utilise:

docker run -itp 8080:80 eexit/mirror-http-server

Puis testons son bon fonctionnement:

curl -I 'http://localhost:8080'

Vous devriez recevoir une réponse HTTP 200 OK:

HTTP/1.1 200 OK
X-Powered-By: Express
Date: Fri, 01 May 2020 17:57:17 GMT
Connection: keep-alive

Alors que:

curl -I -H X-Mirror-Code:500 'http://localhost:8080'

retournera une réponse HTTP 500:

HTTP/1.1 500 Internal Server Error
X-Powered-By: Express
Date: Fri, 01 May 2020 17:57:45 GMT
Connection: keep-alive

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

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.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.4/aio/deploy/recommended.yaml

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:

kubectl -n kube-system describe secret default | grep token: | awk '{print $2}'

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):

kubectl proxy

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

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:

brew install helm@3

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

helm version

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

version.BuildInfo{Version:"v3.3.4", GitCommit:"a61ce5633af99708171414353ed49547cf05013d", GitTreeState:"dirty", GoVersion:"go1.15.2"}


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

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:

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.7.3 sh -

cd istio-1.7.3

Ajoutez le client istioctl à votre path:

export PATH=$PWD/bin:$PATH

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

istioctl install --set profile=demo

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:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.7/samples/addons/prometheus.yaml

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

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.

kubectl create ns application

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

kubectl label namespace application istio-injection=enabled

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:

git clone https://github.com/fabianpiau/mhs-chart.git

Et installez MHS:

cd mhs-chart
helm install --name mhs --namespace application ./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

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:

curl -I -H Host:mhs.example.com 'http://localhost'

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

HTTP/1.1 200 OK
x-powered-by: Express
date: Fri, 01 May 2020 17:37:19 GMT
x-envoy-upstream-service-time: 17
server: istio-envoy
transfer-encoding: chunked

Et:

curl -I -H Host:mhs.example.com -H X-Mirror-Code:500 'http://localhost'

devrait retourner une réponse HTTP 500:

HTTP/1.1 500 Internal Server Error
x-powered-by: Express
date: Fri, 01 May 2020 17:38:34 GMT
x-envoy-upstream-service-time: 2
server: istio-envoy
transfer-encoding: chunked

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.

helm delete mhs --namespace application

kubectl delete namespaces application

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:

kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.7/samples/addons/prometheus.yaml

istioctl manifest generate --set profile=demo | kubectl delete -f -

kubectl delete namespaces istio-system


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.

Articles similaires

kubernetesFlagger – Déploiements Canary sur Kubernetes kubernetesFlagger – Monitorer vos déploiements Canary avec Grafana hostingChoisir la solution d’hébergement web qui correspond à vos besoins devoxxDevoxx UK 2018 – Jour 2
Commentaires
Pas de Commentaires »
Catégories
Programmation agile
Tags
cloud, docker, flagger, helm, istio, kubernetes
Flux rss des commentaires Flux rss des commentaires
Page 1 sur 11
Télécharger l'app CarmaBlog

Flux RSS

  • Flux RSS RSS - Articles
  • Flux RSS RSS - Commentaires

Articles les plus vus

  • Changer la langue de Firefox - 116 367 vues
  • Réaliser un sondage en ligne avec Google Forms / Drive / Docs - 64 389 vues
  • FAQ – Sondage en ligne avec Google Forms / Drive / Docs - 56 217 vues
  • Personnaliser Gnome 3 (Shell) - 30 802 vues
  • La signification d’URL, URI et URN - 18 401 vues
  • Java EE & CDI vs. Spring - 15 983 vues
  • Open Street Map, une meilleure carte que Google Maps? - 15 789 vues
  • Comparaison NoSQL: Couchbase et MongoDB - 14 688 vues
  • API, REST, JSON, XML, HTTP, URI… Vous parlez quelle langue en fait? - 13 726 vues
  • Une première approche du Camel d’Apache - 13 584 vues

Commentaires récents

  • Fabian Piau sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsOui, dans Google Forms, vous pouvez empêcher les p…
  • BENECH Fabien sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsBonjour, J'ai crée 1 questionnaire via Forms,…
  • SANKARA TIDIANE sur Formation en ligne gratuite sur MongoDBJ'aimerai suivre
  • Pauline sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsMerci Fabian, mais le but étant que nos clients pu…
  • Fabian Piau sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsProbablement mais ces options sont en général paya…

Articles récents

  • Comment écrire un article de blog? En tout cas à ma façon! - Il y a 2 ans et 5 mois
  • Attaques de robots: vous n’êtes pas seul… - Il y a 4 ans et 3 semaines
  • Flagger – Monitorer vos déploiements Canary avec Grafana - Il y a 4 ans et 10 mois
  • Flagger – Déploiements Canary sur Kubernetes - Il y a 4 ans et 11 mois
  • Flagger – Premiers pas avec Istio et Kubernetes - Il y a 5 ans et 1 semaine
  • CoderDojo Expedia à Londres - Il y a 5 ans et 9 mois
  • Etre bénévole à Devoxx4Kids - Il y a 6 ans et 1 semaine
  • Une migration Java 11 réussie - Il y a 6 ans et 4 mois
  • Conseils pour sécuriser votre site WordPress - Il y a 6 ans et 7 mois
  • Devoxx UK 2018 – Jour 2 - Il y a 6 ans et 11 mois
  • Devoxx UK 2018 – Jour 1 - Il y a 6 ans et 11 mois
  • Wise, Revolut et Monzo, une petite révolution dans le monde des expatriés et voyageurs - Il y a 7 ans et 3 mois
  • Autocomplétion pour Git - Il y a 7 ans et 11 mois
  • Swagger, la documentation API automatisée - Il y a 8 ans et 2 mois
  • Architecture Microservices – Les bonnes pratiques - Il y a 8 ans et 7 mois
Offre moi un café

Langue

  • Français
  • English

Suivez-moi!

Suivez-moi sur Linkedin
Suivez-moi sur Twitter
Suivez-moi sur Stackoverflow
Suivez-moi sur Github
Suivez-moi sur Rss
Link to my Contact

Abonnement email

Saisissez votre adresse email pour être informé des nouveaux articles.

Étiquettes

.net agile agilité android bash blog bonnes pratiques cache cloud conférence css devoxx docker développeur eclipse extreme programming firefox flagger google helm hibernate informatique intégration continue istio java jug kubernetes londres mobilité informatique métier outil panorama partage performance plugin programmeur script société spring sécurité tdd test ubuntu windows wordpress

Liens

  • Blog Ippon Technologies
  • Blog Publicis Sapient
  • Blog Zenika
  • Classpert
  • CommitStrip
  • Coursera
  • Le Touilleur Express
  • Les Cast Codeurs Podcast
  • OCTO talks !
  • The Twelve-Factor App

Catégories

  • Evénement (15)
  • Linux (3)
  • Management (8)
  • Programmation agile (29)
  • Technologie (45)

Archives

  • décembre 2022 (1)
  • avril 2021 (1)
  • juin 2020 (1)
  • mai 2020 (2)
  • juillet 2019 (1)
  • mai 2019 (1)
  • décembre 2018 (1)
  • octobre 2018 (1)
  • juin 2018 (1)
  • mai 2018 (1)
  • janvier 2018 (1)
  • mai 2017 (1)
  • mars 2017 (1)
  • octobre 2016 (1)
  • avril 2016 (2)
  • mars 2016 (1)
  • novembre 2015 (1)
  • mai 2015 (1)
  • février 2015 (1)
  • décembre 2014 (1)
  • novembre 2014 (1)
  • septembre 2014 (2)
  • août 2014 (1)
  • juillet 2014 (2)
  • juin 2014 (1)
  • avril 2014 (1)
  • mars 2014 (1)
  • février 2014 (2)
  • janvier 2014 (1)
  • décembre 2013 (1)
  • novembre 2013 (1)
  • octobre 2013 (3)
  • septembre 2013 (5)
  • juillet 2013 (1)
  • juin 2013 (1)
  • mai 2013 (1)
  • avril 2013 (1)
  • mars 2013 (2)
  • février 2013 (1)
  • janvier 2013 (2)
  • décembre 2012 (2)
  • octobre 2012 (1)
  • septembre 2012 (1)
  • juillet 2012 (1)
  • mai 2012 (1)
  • avril 2012 (1)
  • mars 2012 (1)
  • février 2012 (1)
  • janvier 2012 (2)
  • décembre 2011 (1)
  • novembre 2011 (2)
  • octobre 2011 (2)
  • septembre 2011 (1)
  • juillet 2011 (1)
  • juin 2011 (2)
  • avril 2011 (1)
  • mars 2011 (1)
  • février 2011 (1)
  • janvier 2011 (2)
  • novembre 2010 (2)
  • septembre 2010 (1)
  • août 2010 (1)
  • juillet 2010 (1)
  • juin 2010 (1)
  • mai 2010 (1)
  • avril 2010 (1)
  • mars 2010 (1)
  • février 2010 (1)
  • décembre 2009 (1)
  • novembre 2009 (1)
  • octobre 2009 (2)
  • septembre 2009 (2)
  • août 2009 (3)
  • juillet 2009 (1)
  • juin 2009 (2)
Suivez-moi sur Twitter
Suivez-moi sur Linkedin
Suivez-moi sur Stackoverflow
Suivez-moi sur Rss
Link to my Contact
Suivez-moi sur Github
 
Fabian Piau | © 2009 - 2025
Tous droits réservés | Haut ↑