Gravity (de la société Gravitational) est un outil open source permettant aux développeurs de regrouper plusieurs applications dans Kubernetes au sein d’une archive au format .tar facilement distribuable appelée «image de cluster».
Une image de cluster contient tout ce dont une application a besoin et peut être utilisée pour créer rapidement des clusters Kubernetes préchargés avec des applications à partir de zéro.
Ou pour charger des applications contenues dans une image dans un cluster Kubernetes existant comme OpenShift ou GKE par exemple.
Gravity peut être utilisé par les organisations qui ont besoin de déployer leurs applications sous Kubernetes dans des «territoires inexplorés» tels que l’infrastructure de leurs clients (cloud ou sur site), dans un contexte d’Edge Computing ou pour empaqueter des applications pour une distribution interne facilement sur différents clouds …
Elle est présente dans le fameux paysage de la CNCF (Cloud Native Computing Foundation).
La récente version 7.0 a apporté la faculté de :
- Déployer des “images de cluster” avec Gravity dans des clusters Kubernetes existants (avec des noeuds protégés notamment par SELinux).
- Faciliter l’exécution des clusters Gravity dans des environnements où la sécurité et la conformité sont primordiales (via notamment Teleport, une passerelle “SSH / Kubernetes” intégrée pour synchroniser le contrôle d’accès basé sur les rôles pour les deux protocoles et fournir une authentification unifiée).
Lancement pour ce nouveau test d’un droplet sous Ubuntu 20.04 LTS dans DigitalOcean :
avec l’installation préalable du moteur Docker :
Je récupère le paquet contenant Gravity depuis le site web de Gravitational (qui existe sous une version communautaire ou commerciale) :
Ce paquet contient les binaires nécessaires au bon fonctionnement de Gravity …
Je récupère le dépôt Git des exemples relatifs à la solution Gravity …
qui contient les Charts Helm nécessaires au déploiement de Wordpress :
mais aussi les manifests YAML comprenant l’installation ou la mise à jour du cluster :
On va donc commencer l’empaquetage d’un cluster K8s avec cette solution Wordpress embarquée via cette commande :
J’obtiens un paquet global d’environ 2,7 Go. J’ai donc fait appel à ce fichier YAML décrivant tout le processus de déploiement du cluster Kubernetes avec Wordpress (j’ai choisi le mode à un noeud pour le cluster et il est possible dans ce cas d’opter pour un cluster médian à 3 noeuds ou en haute-disponibilité avec 6 noeuds) :
Juste avant cela j’ai arrêté le fonctionnement du moteur Docker local :
Lorsque Gravity crée un cluster Kubernetes à partir d’une image de cluster, il installe un conteneur système spécial ou “Master Container” sur chaque hôte. Ce conteneur est appelé “planète” et est visible en tant que démon pour Gravity.
Le conteneur principal contient tous les services de Kubernetes, en assure la gestion automatique et les isole des autres démons préexistants fonctionnant sur les hôtes du cluster.
La planète est une image Docker maintenue par Gravitational. Pour le moment, l’image de la planète est basée sur Debian 9.
L’image de base de la planète est publiée dans un Docker Registry public à l’adresse quay.io/gravitational/planet (afin qu’il soit possible de personnaliser l’environnement de la planète pour ses Clusters en utilisant l’image de Gravitational comme base).
Je vais me servir de ce Droplet pour décompacter localement ce paquet et déployer mon cluster Kubernetes :
Une fois décompaqueté, je peux lancer son installation locale :
J’obtiens les endpoints nécessaires aux accès à Wordpress et à la gestion du cluster Kubernetes :
Wordpress avec sa base de données est accessible sur le port TCP 30080 :
avec sa console d’administration :
et sa page Web par défaut :
Via la solution Teleport (passerelle SSH / Kubernetes avec RBAC), je crée un utilisateur avec des droits d’administration :
Il est alors possible via cet utilisateur d’accéder à la console d’administration et de monitoring fournie par Gravity …
où je peux visualiser le Droplet que j’ai utilisé pour ce télé-déploiement :
la partie logs :
une console SSH :
et le cluster Kubernetes local :
sans oublier la partie monitoring fournies par le célèbre duo “Prometheus + Grafana” :
Je décide d’ajouter deux nouveaux noeuds externes à ce cluster via deux nouveaux Droplets :
L’un sera dédié à la partie Front de Wordpress avec les conteneurs correspondants :
avec la génération de ces scripts d’installation de Gravity :
que j’exécute dans le Droplet :
Le noeud apparaît et est actif dans la console d’administration :
Le second Droplet sera lui logiquement dédié à la partie Base de données avec les conteneurs correspondants :
Lancement des deux scripts :
Les trois noeuds du cluster sont actifs avec Wordpress embarqué :
Je m’en assure via Teleport et la console SSH sur le noeud maître :
Il existe un modèle en pur déploiement web via un mode “Wizard”. Test de ce dernier avec toujours Wordpress en backend via la réutilisation de l’archive .tar précédemment générée.
Je pars ici de trois instances Ubuntu 20.04 LTS dans Hetzner Cloud qui propose depuis peu des instances avec processeurs AMD EPYC et d’un Droplet dans DigitalOcean qui contient l’archive :
Lancement du télé-deploiement du cluster Kubernetes avec la solution Wordpress embarquée via ce mode Wizard depuis le Droplet Ubuntu dans DigitalOcean :
Un endpoint avec une console Web est accessible pour la suite des opérations :
Comme l’utilisation d’un FQDN est préconisé par Gravitational pour le nom de ce futur cluster Kubernetes, j’en choisis un en domaine Wildcard.
Puis je choisis une architecture classique à trois noeuds pour le cluster Kubernetes (un noeud maître généraliste et deux noeuds Worker avec l’un dédié comme précedemment à la partie Front de Wordpress et le second à la partie Base de données) :
Et les scripts d’installation à lancer sur ces instances dans Hetzner Cloud sont fournies encore une fois :
Exécution de ces derniers sur les instances Ubuntu :
Adresses IP et Hostname apparaissent au fur et à mesure de l’exécution de ces scripts dans la console Web :
J’initie alors le processus de télé-déploiement du cluster Kubernetes en mode Web :
Après un laps de temps, l’installation se termine …
Et j’accède au dashboard du cluster offert par Gravity :
La solution Wordpress est déployée et active :
Ainsi que la partie Monitoring via Grafana + Prometheus :
Via Teleport, je peux contrôler ce cluster avec le client Kubectl :
Wordpress est accessible encore une fois par défaut en mode NodePort sur le port TCP 30080 de tous les noeuds du cluster Kubernetes :
avec sa page de blog par défaut …
Je peux tester en mode Beta l’accès à cette page depuis le port 80 via l’utilisation du nouveau service de Load Balancing offert par Hetzner Cloud :
Les clusters Kubernetes créés avec Gravity sont désormais automatiquement configurés pour exécuter OpenEBS . Cela facilite considérablement le package de bases de données et d’autres services avec état dans des images de cluster Gravity.
Gravity a inclus la commande ‘gravity status’, qui explique bien ce qui ne va pas le cas échéant avec son cluster K8s. Et offre également une «vue chronologique» qui vous permet de voir comment l’état d’un cluster a changé au fil du temps.
La version commerciale de Gravity offrant la possibilité d’acquerir un Gravity Hub pour “récupérer ou pousser” son cluster Kubernetes et ses applications comme on le ferait avec des conteneurs …
Très récemment, c’est la passerelle Teleport qui a bénéficié d’une amélioration de son interface utilisateur …
Il y a encore plein de choses passionnantes à découvrir vis à vis de la feuille de route de Gravity …
À suivre !
