Empaqueter et télé-déployer son cluster Kubernetes et ses applications simplement avec Gravity …

Image for post
Image for post

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.

Image for post
Image for post

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

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

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 :

Image for post
Image for post

avec l’installation préalable du moteur Docker :

Image for post
Image for post

Je récupère le paquet contenant Gravity depuis le site web de Gravitational (qui existe sous une version communautaire ou commerciale) :

Image for post
Image for post

Ce paquet contient les binaires nécessaires au bon fonctionnement de Gravity …

Image for post
Image for post

Je récupère le dépôt Git des exemples relatifs à la solution Gravity …

Image for post
Image for post

qui contient les Charts Helm nécessaires au déploiement de Wordpress :

Image for post
Image for post

mais aussi les manifests YAML comprenant l’installation ou la mise à jour du cluster :

Image for post
Image for post
install.yaml
Image for post
Image for post
upgrade.yaml

On va donc commencer l’empaquetage d’un cluster K8s avec cette solution Wordpress embarquée via cette commande :

Image for post
Image for post

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

Image for post
Image for post
app.yaml

Juste avant cela j’ai arrêté le fonctionnement du moteur Docker local :

Image for post
Image for post

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 :

Image for post
Image for post

Une fois décompaqueté, je peux lancer son installation locale :

Image for post
Image for post

J’obtiens les endpoints nécessaires aux accès à Wordpress et à la gestion du cluster Kubernetes :

Image for post
Image for post

Wordpress avec sa base de données est accessible sur le port TCP 30080 :

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

avec sa console d’administration :

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

et sa page Web par défaut :

Image for post
Image for post

Via la solution Teleport (passerelle SSH / Kubernetes avec RBAC), je crée un utilisateur avec des droits d’administration :

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

Il est alors possible via cet utilisateur d’accéder à la console d’administration et de monitoring fournie par Gravity …

Image for post
Image for post

où je peux visualiser le Droplet que j’ai utilisé pour ce télé-déploiement :

Image for post
Image for post

la partie logs :

Image for post
Image for post

une console SSH :

Image for post
Image for post

et le cluster Kubernetes local :

Image for post
Image for post

sans oublier la partie monitoring fournies par le célèbre duo “Prometheus + Grafana” :

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

Je décide d’ajouter deux nouveaux noeuds externes à ce cluster via deux nouveaux Droplets :

Image for post
Image for post

L’un sera dédié à la partie Front de Wordpress avec les conteneurs correspondants :

Image for post
Image for post

avec la génération de ces scripts d’installation de Gravity :

Image for post
Image for post

que j’exécute dans le Droplet :

Image for post
Image for post

Le noeud apparaît et est actif dans la console d’administration :

Image for post
Image for post

Le second Droplet sera lui logiquement dédié à la partie Base de données avec les conteneurs correspondants :

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

Lancement des deux scripts :

Image for post
Image for post

Les trois noeuds du cluster sont actifs avec Wordpress embarqué :

Image for post
Image for post

Je m’en assure via Teleport et la console SSH sur le noeud maître :

Image for post
Image for post

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 :

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

Lancement du télé-deploiement du cluster Kubernetes avec la solution Wordpress embarquée via ce mode Wizard depuis le Droplet Ubuntu dans DigitalOcean :

Image for post
Image for post

Un endpoint avec une console Web est accessible pour la suite des opérations :

Image for post
Image for post

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

Image for post
Image for post

Et les scripts d’installation à lancer sur ces instances dans Hetzner Cloud sont fournies encore une fois :

Image for post
Image for post

Exécution de ces derniers sur les instances Ubuntu :

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

Adresses IP et Hostname apparaissent au fur et à mesure de l’exécution de ces scripts dans la console Web :

Image for post
Image for post

J’initie alors le processus de télé-déploiement du cluster Kubernetes en mode Web :

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

Après un laps de temps, l’installation se termine …

Image for post
Image for post

Et j’accède au dashboard du cluster offert par Gravity :

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

La solution Wordpress est déployée et active :

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

Ainsi que la partie Monitoring via Grafana + Prometheus :

Image for post
Image for post

Via Teleport, je peux contrôler ce cluster avec le client Kubectl :

Image for post
Image for post

Wordpress est accessible encore une fois par défaut en mode NodePort sur le port TCP 30080 de tous les noeuds du cluster Kubernetes :

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

avec sa page de blog par défaut …

Image for post
Image for post

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 :

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

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 …

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