Introduction

La solution type est l’aboutissement des nombreuses leçons que l’organisation a tirées lorsqu’elle s’est servie de Kubernetes pour élaborer puis déployer des logiciels. Ces enseignements et l’expérience acquise après consultation de nombreuses PME au sujet de la plateforme IT de Kubernetes ont été synthétisés sous la forme d’un code et de documents, ce qui a donné la trousse KAT. Nous espérons que cette ressource, c.-à-d. la solution type et le code de lancement, vous procurera les outils essentiels pour mener avec brio vos propres projets Kubernetes et initiatives « cloud-native ».

Remarque : nous recommandons vivement que vous commenciez par prendre connaissance de la documentation la plus récente concernant la trousse KAT sur notre dépôt GitHub afin de vous familiariser avec les nombreux concepts mentionnés dans la solution type.

Aperçu

Au cœur de la solution type figure une application complète (sous forme de code et de documentation) élaborée et déployée sur la plateforme Kubernetes. Cette solution consiste en l’API d’un microservice et en une application correspondant à un aide-mémoire d’une page appelée « todos » (cadriciel Django en Python pour l’API et application frontale en Vue.js), déployées au moyen d’une grappe Kubernetes dans le nuage de l’ATIR. L’application complète et les sous-systèmes qui la supportent peuvent être déployés sur une seule machine virtuelle (MV). Nous y avons ajouté des outils avec lesquels le développeur pourra installer KAT sur un PC de développement modérément puissant afin qu’il voie comment intégrer la trousse au flux de tâches du développement. L’application todos (liste de choses à faire), offerte à titre d’exemple, fonctionne également avec la plateforme Docker usuelle, ce qui permet de comparer les deux approches.

Outre le code source, la solution type comprend une infrastructure en tant que code qui configure les ressources Kubernetes soutenant l’application. La grappe Kubernetes est configurée avec Microk8s en vue de l’installation d’un seul nœud Kubernetes sur la MV. On trouvera ci-dessous une brève description des sous-systèmes de soutien de Kubernetes.

Sous-système	Description
Stockage/État	Ce sous-système montre comment déployer un composant vérifiable; dans l’exemple, la base de données Postgres hébergée dans la grappe Kubernetes utilise les abstractions du volume de stockage persistant de Kubernetes.
Point d’entrée et services	Ces sous-systèmes expliquent comment le trafic externe (nord-sud) de l’application est acheminé dans la grappe Kubernetes, jusqu’aux applications qui y ont été déployées.
Espace de nommage	En séparant les composants en espaces de nommage, on montre comment séparer la grappe Kubernetes sans danger entre de nombreux microservices.
Gestion des secrets	Ce sous-système illustre comment stocker les mots de passe et d’autres informations délicates.
Déploiement	Le déploiement joue un grand rôle dans le processus d’intégration et d’exécution continues (CI-CD) de Kubernetes; nous installerons l’application comme si on la déployait en vue d’y greffer des tâches supplémentaires comme la reprise au point de contrôle, une disponibilité élevée, etc.
Versionnage	Les versions du logiciel et leurs fonctionnalités comme la reprise au point de contrôle servent à illustrer certains aspects opérationnels importants de Kubernetes. Nous nous servirons de Helm à cette fin.
Surveillance	La pile de contrôle Prometheus/Grafana habituelle sert à surveiller Kubernetes et les applications.
Mise à l’échelle automatique	Horizontal Pod Autoscaler montrera à l’utilisateur comment Kubernetes gère la mise à l’échelle automatique.
Limitation des ressources	Kubernetes autorise l’isolement des services selon des groupes de contrôle (cgroups) afin que les bogues comme une fuite de mémoire n’affectent pas les autres services hébergés sur le nœud de travail. Nous montrerons comment Kubernetes y parvient en restreignant les ressources.

Les sous-systèmes qui précèdent seront tous configurés au moyen des formules Helm (Charts) de Kubernetes. Nous verrons comment utiliser Skaffold pour déployer les formules Helm de l’application.

Fig. 1 Solution type. Le développeur bâtit le logiciel (grand rectangle blanc sur l’illustration) avec Vue.js (application frontale d’une page), avec le cadriciel en Python Django (API dorsale) et avec une base de données Postgres. Le Propulseur fournit le code nécessaire et la méthode pour créer les images Docker des applications dorsale et frontale. Ces images seront stockées dans un registre avec l’outil Skaffold.

Description

Le tableau que voici donne une idée des composants que regroupe la solution.

Composant	Description
Infrastructure en tant que code Kubernetes	Code Helm spécifique à l’application et manifestes Kubernetes employés pour lancer et actualiser le déploiement de l’application, configmaps et gestion des secrets, Horizontal Pod Autoscaler pour chaque composant, infrastructure de soutien comme le stockage Kubernetes de la base de données, ressources de surveillance et de point d’entrée, ainsi que questions de nature opérationnelle comme la limitation des ressources et l’espace de nommage
Grappe Microk8s de Kubernetes	Installation de Kubernetes sur un simple nœud de la machine virtuelle, dans le nuage de l’ATIR
Application Web moderne	Application représentative du genre « liste de choses à faire » (To-Dos) avec partie frontale (Vue.js), partie dorsale (cadre REST sur Django) et base de données PostgreSQL
Composant d’entrée NGINX	Composant NGINX pour l’arrivée du trafic dans Kubernetes avec L7 capacités de routage  https://GitHub.com/kubernetes/ingress-NGINX
Gestionnaire Helm	On se servira des formules Helm (Charts) usuelles pour PostgreSQL, Prometheus, Grafana et Python, ainsi que de formules spéciales pour déployer et gérer la pile d’applications https://Helm.sh/
Dépôt d’infrastructure en tant que code (IaC) de GitHub	Dépôt Git public hébergeant l’application et l’IaC de Kubernetes
Grafana + Prometheus	Système moderne de surveillance et d’alerte utilisable avec Kubernetes

Démonstration de la technologie

Le graphique ci-dessous montre comment les éléments de l’application sont déployés dans la grappe Kubernetes. Le tableau qui le suit en donne une description succincte, avec un lien menant à la documentation complète. Encore une fois, nous vous incitons à prendre connaissance des documents et du code à jour dans le dépôt KAT de GitHub, afin de mieux comprendre comment fonctionne la solution.

Étiquette	Description	Commandes	Lien vers le code
1(a)	API du service dorsal todos dans Kubernetes. Ce composant équilibre la charge des demandes parvenant au point terminal /djangoapi/ entre les deux unités d’exécution (pod) dorsales indiquées sur l’illustration. Service de type ClusterIP.	kubectl -n be describe service	Modèle de l’API dans la formule Helm
1(b)	Le déploiement de l’API dorsale todos a créé une réplique qui a elle-même défini deux pods pour l’API Django.	kubectl -n be get po -o wide	Modèle du déploiement de l’API dans la formule Helm
2(a)	Service de base de données todos. Remarque : le service ClusterIP « interne » et les pods de l’API Django 1(b) s’y connectent pour ouvrir le port 5432.	kubectl -n pg describe svc	Formule Helm de Postgres, fichier des valeurs Postgres de KAT
2(b)	Pod de la base de données postgres. Il utilise un volume persistant pour maintenir la base de données.	kubectl -n pg describe po	Formule Helm de Postgres, fichier des valeurs Postgres de KAT
3(a)	Application frontale d’une page Vue.js du service todos. Ce composant équilibre la charge des demandes au point terminal frontal entre les deux pods frontaux qui desservent les fichiers Vue.js sur l’illustration. Service de type ClusterIP.	kubectl -n fe describe svc	Modèle du service frontal employé pour restituer un manifeste YAML de Kubernetes d’après les valeurs transmises à Helm
3(b)	Pods frontaux – ces unités d’exécution NGINX desservent les fichiers de code de Vue.js. Application non vérifiable puisqu’elle n’est pas raccordée à l’API dorsale; le client charge l’application sur son navigateur puis s’adresse directement à l’API dorsale sur /djangoapi/.	kubectl -n fe describe deploy; kubectl -n fe get po -o wide	Modèle de service frontal employé pour restituer un manifeste YAML de Kubernetes d’après les valeurs transmises à Helm
4(a)	Tableau de bord Kubernetes; il envoie les demandes reçues au pod du tableau de bord.	kubectl -n dashboard describe svc; kubectl -n dashboard describe endpoints	Formule Helm du tableau de bord; fichier des valeurs du tableau de bord KAT
4(b)	Pod du tableau de bord Kubernetes. Remarque : ce service n’est pas très disponible car il n’est pas répliqué.	kubectl -n dashboard describe po	Formule Helm du tableau de bord; fichier des valeurs du tableau de bord KAT
5(a)	Tableau de bord Grafana	kubectl -n monitoring describe service grafana	Formule Helm de la pile Prometheus, fichier KAT des valeurs de la pile Prometheus pour Helm.
5(b)	Pod de Grafana	kubectl -n monitoring describe po grafana	Formule Helm de la pile Prometheus, fichier KAT des valeurs de la pile Prometheus pour Helm.
6(a)	Service du serveur de mesure chronologique de Prometheus. Remarque : il n’est pas exposé à l’extérieur par le composant d’entrée; service interne utilisé par Grafana.	kubectl -n monitoring describe pod Prometheus-server	Formule Helm de la pile Prometheus, fichier KAT des valeurs de la pile Prometheus pour Helm.
6(b)	Pod du serveur Prometheus. Remarque : utilise un volume persistant pour stocker les données.	kubectl -n monitoring get po -o wide; kubectl get pv; kubectl -n monitoring get pvc	Formule Helm de la pile Prometheus, fichier KAT des valeurs de la pile Prometheus pour Helm.
7	Composant d’entrée. Toutes les demandes HTTP le traversent pour pénétrer dans la grappe Kubernetes, puis sont acheminées vers l’API frontale, l’APÎ de Django, le tableau de bord ou le module de surveillance Grafana selon le cas. C’est ici que se terminerait le SSL sur la plateforme de production ou l’interface avec l’équilibreur de charge du fournisseur de services d’infonuagique. Donc, le composant d’entrée est habituellement un élément très important de la configuration de l’application dans Kubernetes.	kubectl get ingress –all-namespaces -o wide	Documentation sur le composant d’entrée NGINX

 

Prêt à décoller?

Déploiement de la Solution type

Avant de déployer la solution, vous devrez avoir pris les mesures qui suivent sur votre compte du Nuage de l’ATIR :

1. vous avez créé un groupe de sécurité vous donnant accès aux MV établies dans le Nuage de l’ATIR par le protocole SSH (port 22 du protocole TCP) à partir de l’adresse IP utilisée pour accéder à cette MV;
2. vous avez configuré votre paire de clés SSH pour accéder aux MV dans l’ATIR.

Vous devez pouvoir créer une MV Linux dans le Nuage de l’ATIR et vous y connecter avec le protocole SSH avant d’aller plus loin.

Déploiement de la Solution type KAT dans le Nuage de l’ATIR

1. Ouvrez une séance sur votre compte ATIR d’AWS en suivant les instructions que vous a procurées l’équipe de l’ATIR.
2. Cliquez DÉPLOYER pour lancer le Propulseur avec la pile CloudFormation d’AWS.
3. Vous trouverez aussi un lien DÉPLOYER pour chaque Solution type dans le Catalogue des Propulseurs.

Cliquez Suivant pour passer à la deuxième étape de CloudFormation puis remplissez le formulaire de configuration. Dans le champ « InstanceName », donnez un nom unique à l’instance du serveur de l’application et complétez le formulaire au moyen des menus déroulants. Veuillez noter que les autres paramètres comme « ApplicationImage » ou « InstanceType » ont déjà été configurés et ne peuvent être modifiés.

Cela fait, cliquez SUIVANT pour passer à la troisième étape. Cette partie permet de configurer d’autres options, plus avancées, mais inutiles dans le cas qui nous intéresse. Cliquez simplement SUIVANT, au bas de la page, pour passer à la quatrième et dernière étape.

La dernière partie vous permet de vérifier la configuration du Propulseur et d’y apporter des changements avec le bouton « Modifier », si besoin est. Une fois que la configuration vous convient, cliquez « Soumettre », au bas de la page, pour déployer le Propulseur.

Le déploiement commence par la création d’une nouvelle instance. Le reste est automatique. Suivre le développement de l’instance n’est possible qu’avec les ongles « Événements » et « Ressources » de la console CloudFormation. Ensuite, vous devrez vous connecter au serveur de l’application pour vérifier si la solution s’est bien déployée automatiquement.

Notez aussi l’adresse IP qui apparaît à l’onglet « Sorties », sur la page CloudFormation du Propulseur. Elle correspond à l’adresse IP externe de l’instance. Vous en aurez besoin pour vous connecter au serveur avec le protocole SSH et accéder aux interfaces Web de l’application.

Connectez-vous au serveur de l’application avec la commande SSH qui suit, à partir d’une interface de commande/d’un terminal activés par SSH.

ssh -i key_file.pem ubuntu@Public_IP

 

Remplacez « key_file » par la clé privée de la paire de clés SSH établie dans le formulaire de configuration et remplacez « Public_IP » par l’adresse IP obtenue à l’onglet « Sorties » de la console CloudFormation.

Après vous être connecté au serveur de l’application, vous pourrez suivre le déroulement du script d’automatisation avec les commandes que voici :

source /etc/profile.d/boosterpack.sh

tail -f /var/log/boosterpack.log

Notez le jeton d’utilisateur (copiez-le sur le bloc-notes), car vous en aurez besoin pour accéder à la console Kubernetes, par la suite. Vous pouvez aussi récupérer ce jeton au moyen du serveur de l’application du Propulseur avec la commande ci-dessous :

sudo microk8s config

 

L’étape suivante consiste à configurer le renvoi du port 8080 de votre ordinateur au port 80 de la MV de l’ATIR à travers un tunnel SSH. De cette manière, on sécurise l’accès au serveur tout en ouvrant la porte à tous les services http de la Solution type KAT.

Pour cela, utilisez la commande Linux/Mac qui suit.

La ligne de commande SSH crée un tunnel de localhost:8080, sur l’ordinateur, à localhost:80, sur la VM de l’ATIR, par son adresse IP externe.

ssh -i key_file.pem ubuntu@Public_IP -L 8080:localhost:80 -N

 

Une autre façon de procéder consisterait à configurer le renvoi d’un port SSH à l’autre avec l’outil Putty de Windows. Pour cela, suivez le guide : https://docs.bitnami.com/bch/faq/get-started/access-ssh-tunnel/ (en anglais)

Remarque : si vous utilisez Putty, rappelez-vous d’établir le lien avec localhost:8080, PAS localhost:8888, tel qu’indiqué dans le guide.

Vérification de l’installation

Attention : La barre oblique finale « / » est obligatoire dans l’URL ci-dessous!

1. Ouvrez un navigateur et allez à http://localhost:8080/frontend/

2. Vous serez connecté au service frontal de la liste todos dans Vue.js.

3. Vous devriez voir l’application Todo List; saisissez quelques choses à faire (todo) et assurez-vous que la liste s’allonge ou raccourcit quand vous ajoutez ou retranchez des éléments. Vous pouvez aussi modifier les éléments en les double-cliquant.

4. Ensuite, vérifiez que le service API de Django est accessible. Sur un nouvel onglet du navigateur, allez à http://localhost:8080/djangoapi/apis/v1/. Ceci devrait vous connecter à l’API explorable de Django. Vous devriez voir les éléments que vous venez de saisir avec l’application frontale (étape qui précède) en format JSON

.

5. À présent, ouvrez le tableau de bord de Kubernetes en allant à http://localhost:8080/dashboard/. Utilisez le jeton copié lors de la configuration (étape 11 du déploiement, plus haut) pour accéder au tableau de bord. Vous devriez pouvoir naviguer dans la grappe Kubernetes qui a été déployée sur la MV de l’ATIR. La saisie d’écran ci-dessous devrait correspondre à ce qui apparaît à l’écran.

6. Enfin, allez à http://localhost:8080/monitoring-grafana/ pour vous connecter au service de surveillance Grafana. Ouvrez une séance en utilisant les justificatifs par défaut suivants :Nom d’utilisateur : « admin »
Mot de passe : « prom-operator »

7. Pour avoir une idée de ce qu’il est possible de surveiller dans la grappe Kubernetes, allez au menu « Manage Dashboards », à gauche et cliquez le lien « Kubernetes / Compute Resources / Cluster », encadré sur la saisie d’écran ci-dessous.

8. Le tableau de bord ci-dessous devrait apparaître à l’écran avec diverses données sur la grappe. Vous pouvez personnaliser (modifier) le tableau de bord ou en créer un nouveau, selon ce que vous préférez.

 

Considérations d’ordre technique

Les principales fonctionnalités de la solution type sont examinées ci-dessous. Nous vous recommandons vivement de prendre connaissance de la documentation la plus récente que vous trouverez dans le dépôt de source ouverte Kubernetes Automation Toolkit de BigBitBus à l’adresse :

https://GitHub.com/BigBitBusInc/kubernetes-automation-toolkit

Déploiement

Skaffold

Outil de construction automatique développé par Google pour les applications Kubernetes. Il gère le flux de tâches qui bâtit, initialise et déploie l’application. Grâce à lui, le développeur peut consacrer plus de temps au développement qu’à l’érection et au déploiement de son application. Les déploiements utilisant Skaffold reposent sur un fichier « skaffold.YAML » renfermant diverses informations comme l’image Docker à utiliser pour bâtir le conteneur, le chemin jusqu’à l’application, l’environnement dans lequel elle doit être déployée et ainsi de suite. En exécutant ce fichier, on laisse Skaffold surveiller un répertoire local d’applications pour y repérer les modifications et bâtir, initialiser et déployer une grappe Kubernetes locale ou éloignée dès qu’un changement a été décelé. Plus sur le sujet ici : https://skaffold.dev/docs/

Dans notre exemple, Skaffold nous permet de développer l’application dorsale Django et l’application frontale Vue.js sans avoir à en configurer le déploiement, comme le fichier des manifestes Kubernetes ou la reconstruction des images. Une exécution rapide de Skaffold bâtira l’application et la déploiera dans la grappe Kubernetes, avec surveillance des changements éventuels qu’on y apporte.

Helm

Gestionnaire de paquets de Kubernetes. Équivalent de Yum/Apt pour les applications Kubernetes. Helm crée et déploie des formules Helm (Charts), c’est-à-dire des paquets structurés sur l’architecture de Kubernetes. Ces formules confèrent une structure simple et normalisée aux manifestes Kubernetes nécessaires pour le déploiement. Après addition de la formule au dépôt Helm local, la commande rapide « Helm install [formule Helm] » simplifie le déploiement dans la grappe Kubernetes. Plus d’informations à ce sujet ici : https://helm.sh/docs/

Des formules Helm ont été créées pour les applications dorsale et frontale du Propulseur, en conformité avec la structure déjà employée pour les autres composants. On s’est aussi servi de Helm pour installer la base de données PostgreSQL de Bitnami, l’opérateur Prometheus et Grafana.

Prometheus et Grafana

Modules surveillant les activités dans la grappe Kubernetes. Développé par SoundCloud, Prometheus se veut une solution complète pour visualiser et journaliser les données transférées dans la grappe. Ses principales fonctionnalités comprennent des modèles de données évolués pour les ressources de Kubernetes, un langage de recherche polyvalent et de nombreux types de graphes et de tableaux de bord. Grafana est un logiciel de visualisation permettant à l’utilisateur de mieux saisir ce qui se passe dans la grappe Kubernetes. Grafana restitue les données sous forme de graphes, de formules, de mesures et de cartes, ce qui simplifie la supervision d’une grappe complexe.

Grafana est doté d’un soutien intégré pour les recherches sur Prometheus. Le logiciel récupère les données glanées par Prometheus et les affiche de manière structurée grâce à une interface graphique au moyen de laquelle l’utilisateur peut suivre l’activité des ressources dans un espace de nommage donné de la grappe.

Applications

Vue.js (application frontale)

Cadriciel ouvert en JavaScript servant à bâtir des interfaces utilisateur. Il intègre le côté réactif de la conception Web permettant de connecter la partie en JavaScript au code HTML. Quand les données du composant en JavaScript changent, l’interface (HTML/CSS) se reconfigure automatiquement.

Dans notre Propulseur, l’application Vue.js fonctionne sous la forme d’une application frontale d’une page, c’est-à-dire une interface graphique avec laquelle l’utilisateur lance les appels RESTful habituels à l’application dorsale sans avoir à interagir directement avec elle.

Pour les invites de l’API, l’application recourt à un outil baptisé « Axios » de la bibliothèque JavaScript. Cet outil configure la requête en format HTTP de base avant de l’expédier au serveur dorsal.

Méthode	Description
OBTENIR (GET)	Au chargement de la page, l’application exécute automatiquement une commande qui récupère les choses de la liste (todos) qui n’ont pas encore été faites dans la base de données.
AFFICHER (POST)	Encadré demandant à l’utilisateur ce qu’il y a « à faire » pour l’inciter à ajouter des choses à la liste.
MODIFIER (PUT)	En double-cliquant une chose à faire, l’utilisateur peut la modifier. La touche ÉCHAP annule la modification.
SUPPRIMER (DELETE)	En survolant les choses encore à faire avec la souris et en cliquant le « x » rouge, on supprimera la chose en question de la liste.

Le CSS utilisé pour exécuter l’application est dérivé du modèle suivant :

https://GitHub.com/Klerith/TODO-CSS-Template

Pour accéder au répertoire dans lequel figurent les fichiers Vue.js, suivre le chemin :

https://GitHub.com/BigBitBusInc/kubernetes-automation-toolkit/tree/main/code/app-code/frontend/ToDo-vuejs

Le code sous-jacent présenté à l’utilisateur figure plus loin dans src/App.vue. Ne sont présentés ici que les composants HTML/CSS de base portant l’étiquette <template> et les composants JavaScript portant l’étiquette <script>.

Pour en savoir plus sur Vue.js, aller à : Introduction — Vue.js

Django (application dorsale)

Cadriciel Web ouvert en Python établissant les composants de base d’un projet en vue d’une application Web. Ainsi, l’utilisateur peut consacrer plus de temps au développement et moins au déploiement. La syntaxe est facile à saisir et comprend l’architecture de base d’un serveur Web.

Dans notre Propulseur, l’application Django fait office d’application dorsale qui établit l’API todos. Elle prend en charge les appels de l’API et envoie ou récupère l’information dans la base de données.

Au démarrage, l’application crée une liste « todo » modèle avec pour attributs, notamment, le titre et la description d’une chose à faire (todo), principal objet sur lequel repose l’application. Celle-ci établit une connexion avec la base de données et y envoie l’information du modèle par migration. Ensuite, la base de données produit un tableau présentant l’ensemble des objets todo.

Avec comme routeur le « DefaultRouter » de Django, l’application cartographie automatiquement les requêtes HTTP de l’application frontale en regard du jeu d’objets todo grâce à un ensemble « Viewset ». « Viewset » utilise des opérations comme énumérer, créer, actualiser et supprimer qui modifient le contenu de la base de données chaque fois que les objets changent. Par exemple, quand on ajoute un objet todo avec l’application Vue.js, le routeur saisit la requête, la cartographie selon sa méthode et l’expédie dans « Viewset », qui la prend en charge par l’opération « créer » du modèle. Quand la liste d’objets todo est modifiée, l’application Vue.js réagit en actualisant la page.

Le code de l’API todos a été dérivé de l’original, disponible à l’adresse : GitHub – wsvincent/drf-todo-api: Django REST Framework Todo API Tutorial

Pour voir le répertoire groupant tous les fichiers de code Django, on suivra le chemin kubernetes-automation-toolkit/code/app-code/api/todo-python-django at main · BigBitBusInc/kubernetes-automation-toolkit · GitHub

Pour en savoir plus sur le cadriciel REST de Django, lire : https://docs.djangoproject.com/fr/3.1/

Autres considérations

Sécurité

La MV de l’ATIR sur laquelle fonctionne la grappe Kubernetes hébergeant l’application todos n’est accessible que sur le port 22 (SSH). Pour explorer l’application et les points terminaux de Grafana, nous recourons à une tunnellisation sécurisée entre l’ordinateur et la MV. Les rustines de sécurité sont automatiquement appliquées à la MV d’Ubuntu par le modèle de l’application (Application Blueprint).

Les formules Helm (Charts) de l’échantillon comprennent des blocs de code TLS/SSL commentés qu’il est possible d’activer avec un certificat TLS valable pour le domaine. En réalité, on ne se connecterait pas avec un tunnel SSH, mais par encryptage TLS en utilisant le protocole sécurisé HTTPS. Les fichiers « values.YAML » comprennent des parties non commentées, ce qui vous permettra d’utiliser vos propres certificats SSL quand viendra le moment de déployer l’application afin que des utilisateurs de l’extérieur puissent s’en servir. Pour en savoir plus sur le fonctionnement de la couche TLS et des composants d’entrée, lisez ceci.

Dans la solution modèle KAT, nous avons attribué les justificatifs de l’administrateur de Kubernetes (root-admin) à l’utilisateur de la MV. En fait, comme c’est le cas pour n’importe quelle grappe de production dans laquelle de multiples utilisateurs ou services ont accès à Kubernetes, l’idéal consiste à utiliser le contrôle des accès basé sur les rôles. Nous vous encourageons à examiner les nombreux aspects associés à la sécurité avant d’utiliser Kubernetes dans un environnement de production.

Nous nous sommes servis de la fonction « secrets » de Kubernetes (pour stocker le mot de passe Postgres, par exemple, et l’appliquer à la formule Helm); nous préconisons l’usage de cette fonction plutôt que de configmaps en texte clair quand Kubernetes stocke des données sensibles.

Voici quelques excellentes ressources pour vous aider à démarrer si vous voulez en apprendre davantage sur la sécurité et Kubernetes.

1. 1. Documentation officielle de Kubernetes sur la sécurisation des grappes : https://kubernetes.io/docs/concepts/security/ 
   2. Gestion automatique des certificats avec Cert-Manager en cloud-native : https://cert-manager.io/

Réseau

Comme nous l’avons déjà mentionné, les composants d’entrée NGINX servent à rendre les points terminaux de l’application visibles au monde extérieur. Après avoir créé la MV dans l’ATIR, creusez un tunnel SSH entre le port local 8080 et le port HTTP 80 de la MV.

Cela fait, l’utilisateur pourra accéder aux composants de l’application avec le navigateur de son ordinateur aux endroits indiqués. Attention : le trait oblique final est obligatoire!

Points terminaux (après connexion à l’hôte local 8080 par le tunnel SSH)

Application frontale todos	http://localhost:8080/frontend/
API dorsale	http://localhost:8080/djangoapi/
Système de surveillance Grafana	http://localhost:8080/monitoring-grafana/
Tableau de bord Kubernetes	http://localhost:8080/dashboard/

La solution type KAT utilise Ingress Controller de NGINX, ce qui ouvre une foule de possibilités pour configurer les demandes de routage et de réseautage de la couche 7. Le serveur NGINX fait office de serveur de procuration inversé et d’équilibreur de charge. NGINX est extrêmement polyvalent et propose de nombreuses options pour configurer le trafic.

Apprenez en plus sur NGINX Ingress de Kubernetes ici.

Mise à l’échelle

Les fichiers « values.YAML » dans les formules Helm des applications frontale et dorsale ont un paramètre appelé « replicas » qui peut être modifié en fonction du nombre de répliques. L’Horizontal Pod Autoscaler de Kubernetes est également activé, si bien que le nombre de répliques s’ajuste automatiquement en fonction de l’utilisation de l’UCT par les Pods. Voir les fichiers « values.YAML » dans les formules Helm pour comprendre comment ces paramètres sont configurés. N’hésitez pas à expérimenter en fixant le nombre de répliques dans chaque fichier values.YAML employé pour le déploiement.

Disponibilité

Kubernetes peut créer de nombreux Pods qui utiliseront le même logiciel (l’application dorsale de Django ou l’application frontale Vue.js, par exemple). L’application est donc très facilement accessible. Cette particularité revêt une importance particulière quand on recourt à une grappe Kubernetes à nœuds multiples. Par exemple, si on l’exécute dans une grappe de ce genre, l’application todos restera active même si un nœud défaille. Kubernetes détectera puis relancera automatiquement le nœud défectueux. L’utilisateur ne s’en rendra pas compte, ce qui simplifie considérablement le travail technique requis quand on doit exploiter et maintenir des applications sur une plateforme de production d’une grande accessibilité.

Coût

Habituellement, la taille de la grappe Kubernetes est proportionnelle au nombre de nœuds d’exécution qu’elle abrite. Dans la solution type KAT, nous nous contentons d’une grappe à un nœud sur une seule machine virtuelle, mais les nœuds d’exécution et de contrôle seront plus nombreux dans la réalité, et les frais de réseau de même que ceux d’équilibrage de la charge pourraient s’accroître sensiblement avec l’expansion de la grappe. Pour avoir une idée du coût « réel » d’une grappe Kubernetes, nous vous suggérons de recourir à la calculatrice d’un des nuages publics, par exemple :

Google : https://cloud.google.com/products/calculator

Amazon AWS : https://calculator.aws/#/

Microsoft Azure : https://azure.microsoft.com/en-us/pricing/calculator/

Licence d’exploitation

Tous les composants de la solution type KAT sont visés par une licence de source ouverte; veuillez vous rapporter au dépôt de la source correspondante pour en savoir plus sur les conditions qui s’y associent. La licence pour le code du Propulseur KAT et la documentation connexe sont disponibles ici :

https://GitHub.com/BigBitBusInc/kubernetes-automation-toolkit/blob/main/LICENSE.md

Code source

On trouvera le code source à jour ici :

https://GitHub.com/BigBitBusInc/kubernetes-automation-toolkit

Glossaire

Termes et expressions utilisés dans le document.

Expression	Description	Lien/Complément d’information
Django	Cadriciel Web gratuit de source ouverte en Python	Documentation officielle de Django Illustration d’une API dorsale du genre « choses à faire » rédigée en Django
Helm	Gestionnaire de paquets pour Kubernetes	Documentation officielle sur Helm Illustration d’une formule Helm (Chart) dans le présent dépôt
Kubernetes	Système d’orchestration de conteneurs ouvert automatisant le déploiement, la mise à l’échelle et la gestion d’une application	Kubernetes
Microk8s	Système de distribution Kubernetes allégé, prêt à l’emploi	Microk8s
PostgresSQL	Système de gestion ouvert pour les bases de données relationnelles	PostgreSQL Illustration d’une configuration Postgres dans Kubernetes
Prometheus et Grafana	Base de données chronologiques et système de recherche de données avec interface utilisateur	Documentation officielle sur Prometheus Illustration de la configuration d’une pile Prometheus
Skaffold	A build and deploy tool for Kubernetes	Outil de construction et de déploiement pour Kubernetes Documentation officielle sur Skaffold
Vue.js	Illustration d’un fichier de définition Skaffold en YAML	Documentation officielle sur Vue.js Illustration d’une application frontale To-Do en Vue.js