Mise en oeuvre d’un Service Mesh avec MicroStack, Linkerd 2.x et K3S …

Image for post
Image for post

Canonical a récemment publié un article intéressant intitulé “Non, Kubernetes n’est pas le nouvel OpenStack” (dont on peut comprendre les préoccupations commerciales sous-jacentes) pour souligner le fait que le principal facteur qui distingue OpenStack de Kubernetes est :

  • qu’OpenStack a été conçu essentiellement comme une solution permettant de créer des infrastructures multi-tenants

Ils existent pour certaines pratiques visant à la mise en oeuvre du “multi-tenant” dans un cluster Kubernetes via l’isolation au niveau des noeuds ou des namespaces par exemple :

Image for post
Image for post

Quoiqu’il en soit, je profite de la première mouture de MicroStack en version Stein (toujours en Edge) pour initier un service Mesh avec Linkerd. Pour rappel, MicroStack est une version d’OpenStack destinée à être déployée sur un station de travail, dans un contexte d’Edge Computing et d’IoT par exemple :

Image for post
Image for post
Image for post
Image for post

Et ceci simplement via Snap :

Image for post
Image for post

J’en avais parlé dans un ancien article :

Je pars donc pour cette expérience d’une instance Bare Metal de type C2M (16 Go RAM et 100 Go pour le disque) chez Scaleway sous Ubuntu 18.04 LTS :

Image for post
Image for post

L’installation de MicroStack en version Stein est réalisée avec Snap :

$ snap install microstack --edge --classic
Image for post
Image for post

avec une initialisation d’OpenStack en quelques minutes :

$ microstack.init
Image for post
Image for post

Via une redirection de port sous SSH, je me connecte au dashboard Horizon (admin/keystone par défaut pour les identifiants) :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

J‘ai un routeur avec deux réseaux par défaut (public et privé) :

Image for post
Image for post

et ces accès API par défaut :

Image for post
Image for post

Je peux charger une image Ubuntu 18.04 avec Glance qui va me servir à la constitution d’un cluster avec K3S :

$ microstack.openstack image create Ubuntu-18.04-LTS --disk-format qcow2 --container-format bare \
--public --file ./bionic-server-cloudimg-amd64.img
Image for post
Image for post
Image for post
Image for post

Je lance 3 instances Ubuntu en utilisant le réseau privé par défaut (sans besoin du réseau public fourni) via le dashboard :

Image for post
Image for post

avec le déploiement de ZeroTier :

Image for post
Image for post

J’ai au final mes trois instances qui sont accessibles via les adresses IP fournies dans ZeroTier et la paire de clé SSH que j’ai préalablement chargée via le dashboard Horizon :

Image for post
Image for post
Image for post
Image for post

J’ai activé la fonction “Ethernet Bridging” pour chacune de ces instances dans ZeroTier en prévision de l’utilisation de MetalLB :

Image for post
Image for post

Je peux initialiser mon cluster Kubernetes avec K3S en utilisant sa dernière version (v0.9.0) :

Image for post
Image for post

avec ce petit script maintenant bien connu pour le noeud maître :

$ curl -sfL https://get.k3s.io | sh -
Image for post
Image for post

Je relie mes deux noeuds Worker via ce script :

$ curl -sfL https://get.k3s.io | K3S_URL=https://192.168.191.38:6443 K3S_TOKEN=XXX sh -
Image for post
Image for post
Image for post
Image for post

Le cluster est alors prêt :

Image for post
Image for post

Déploiement de MetalLB en se basant sur ZeroTier :

$ kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.1/manifests/metallb.yaml
Image for post
Image for post
Image for post
Image for post

Tout est prêt pour le déploiement d’un Service Mesh avec Linkerd 2.X.

Un Service Mesh est un moyen de contrôler la façon dont différents éléments d’une application partagent des données les uns avec les autres. Contrairement à d’autres systèmes de gestion des communications, un Service Mesh est une couche d’infrastructure dédiée, créée directement dans l’application. Cette couche d’infrastructure visible peut indiquer la manière dont les différents éléments d’une application interagissent entre eux. Il devient dès lors plus facile d’optimiser les communications et d’éviter les temps d’arrêt lorsque l’application évolue. Linkerd a été créé par les co-fondateurs de Buoyant, William Morgan et Oliver Gould, en 2015. S’appuyant sur Finagle (le système RPC extensible pour la JVM développé sur Twitter), Linkerd est utilisé pour construire des applications basées sur les microservices, polyglottes et pour des cas d’utilisation simultanée à plusieurs endroits comme c’est le cas chez Expedia, Monzo, Salesforce ou PayPal.

Le code de Linkerd 2.x (qui fait suite à la dernière version de Conduit) est entièrement open source et disponible sur leur dépôt github :

Linkerd est l’un des nombreux outils extrêmement populaires dédié au “Service Mesh” (avec Istio / Envoy, Cilium ou Consul Connect).

Image for post
Image for post

Linkerd se compose d’un plan de contrôle et d’un plan de données :

  • Le plan de contrôle est un ensemble de services qui s’exécutent dans un namespace dédié. Ces services accomplissent diverses choses : agrégation des données de télémétrie, fourniture d’API orienté utilisateur, fourniture de données de contrôle aux proxies du plan de données, etc … Ensemble, ils déterminent le comportement du plan de données.
Image for post
Image for post

Et cela passe comme on va le voir avec l’utilisation conjointe de Prometheus et Grafana :

Image for post
Image for post

Je récupère l’interface en ligne de commande (CLI) qui va interagir avec Linkerd, y compris au niveau de l’installation du plan de contrôle sur le cluster Kubernetes :

$ curl -sL https://run.linkerd.io/install | sh
Image for post
Image for post

Je vérifie que le binaire linkerd est installé et fonctionne correctement :

$ export PATH=$PATH:$HOME/.linkerd2/bin$ linkerd version

et que le cluster Kubernetes est configuré correctement afin d’installer le plan de contrôle de Linkerd :

$ linkerd check --pre
Image for post
Image for post

Il est temps d’installer le plan de contrôle dans son propre namespace (nommé par défaut, linkerd) : la commande linkerd install génère un manifest Kubernetes avec toutes les ressources nécessaires au plan de contrôle …

$ linkerd install | kubectl apply -f -
Image for post
Image for post

Je vérifie que le déploiement s’est bien déroulé :

$ linkerd check$ kubectl -n linkerd get deploy
Image for post
Image for post

Avec le plan de contrôle installé et en cours d’exécution, on peut acceder au tableau de bord présent avec Linkerd via cette commande et Serveo :

$ linkerd dashboard &$ ssh -R linkerd:80:localhost:50750 serveo.net
Image for post
Image for post

Serveo me retourne l’URL du tableau de bord :

Image for post
Image for post
Image for post
Image for post

On peut déjà observer le trafic que l’on génère en regardant le tableau de bord lui-même !

$ linkerd -n linkerd top deploy/linkerd-web
Image for post
Image for post
Image for post
Image for post

Pour avoir une idée de la façon dont Linkerd fonctionne, j’installe l’application autonome “emojivoto” pour Kubernetes qui utilise un mélange d’appels gRPC et HTTP pour permettre aux utilisateurs de voter sur leurs émojis favoris via cette commande :

$ curl -sL https://run.linkerd.io/emojivoto.yml \
| kubectl apply -f -
Image for post
Image for post

MetalLB me retourne une adresse IP du segment configuré auparavant pour accéder à cette application :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

J’ajoute Linkerd à cette application emojivoto. Ceci par l’exécution d’une commande qui récupère tous les déploiements en cours dans le namespace emojivoto, exécute le manifeste par linkerd inject, puis l’applique de nouveau au cluster. La commande linkerd inject ajoute des annotations à la spécification du pod en demandant à Linkerd d’ajouter (“injecter”) le proxy du plan de données :

$ kubectl get -n emojivoto deploy -o yaml \
| linkerd inject - \
| kubectl apply -f -
Image for post
Image for post

L’application Emojivoto est visualisable sur le tableau de bord de Linkerd :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Puisque cette application de démonstration est livrée avec un générateur de charge, ont peut voir les mesures de trafic en temps réel avec ces commandes :

$ linkerd -n emojivoto stat deploy$ linkerd -n emojivoto top deploy$ linkerd -n emojivoto check --proxy
Image for post
Image for post

ou directement via les tableaux de bord fournis dans Grafana (avec en backend Prometheus) :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Je génére de la charge sur la page web de l’application (avec 20 appels par seconde) via ce script :

$ curl -L https://goo.gl/S1Dc3R | bash -s 20 "http://192.168.191.11"
Image for post
Image for post

avec ces changements dans Grafana :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Je recommence l’opération avec le traditionnel démonstrateur FC (ici composée d’une seul brique) :

Image for post
Image for post
Image for post
Image for post

J’ai une adresse IP retournée par MetalLB pour le démonstrateur FC :

Image for post
Image for post

Avec linkerd inject, le démonstrateur FC est traçable dans le tableau de bord de Linkerd :

Image for post
Image for post
Image for post
Image for post

Je réutilise le script générateur de charge (avec ici 30 appels par seconde) vers l’adresse IP du démonstrateur FC :

Image for post
Image for post

et obtention de métriques en temps-réel :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Pour suivre l’état de MicroStack, j’utilise ici Dynatrace OneAgent :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

avec un focus sur le noeud maître du cluster K3S :

Image for post
Image for post
Image for post
Image for post

ou simplement via htop :

Image for post
Image for post

Un exemple de Service Mesh avec K3S dans MicroStack mais qui dans le contexte de montée en puissance de l’Edge Computing, aurait pû être mené en utilisant par exemple le projet StarlingX :

Image for post
Image for post
Image for post
Image for post

qui pourrait être déployé sur une seule instance Bare Metal avec les trois fonctions (contrôleur, calcul et stockage le tout en lien avec des services IoT) même si en backend on retrouve déjà un cluster Kubernetes sur lequel sera déployé les briques OpenStack containerisées :

Image for post
Image for post

A suivre ! …

Image for post
Image for post

Above the clouds, the sky is always blue ...

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store