Si ce n’est déjà fait, lisez le Plan de vol du Propulseur KAT de BigBitBus, Automatisation de l’orchestration dans le nuage avec Kubernetes, avant de tester la solution type.

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.

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.

Formule de la solution

Grafana et Prometheus sont déployés dans la grappe pour assurer la surveillance. Le tableau de bord de Kubernetes a aussi été installé et configuré afin que l’utilisateur puisse naviguer aisément lors de l’installation de Kubernetes. Un contrôleur d’entrée NGINX a été configuré pour que le trafic puisse accéder à la grappe Kubernetes de l’extérieur.

La solution type KAT comprend les scripts qui installent Microk8s afin que Kubernetes puisse démarrer sur une MV Ubuntu dans l’ATIR. Après démarrage de la MV, vous pourrez utiliser les artefacts infrastructure en tant que code pour déployer l’application et les sous-systèmes qui la supportent mentionnés plus haut de manière à obtenir une pile totalement fonctionnelle sur la MV Ubuntu avec Microk8s, dans le nuage de l’ATIR.

Le code de l’application et les artefacts de l’infrastructure de Kubernetes donnent un aperçu des différents rouages qui vous permettront de réaliser vos propres projets Kubernetes dans le nuage de l’ATIR et, par la suite, dans le nuage de n’importe quel fournisseur public ou privé.

Pour une souplesse maximale, la solution type peut être déployée sur votre propre ordinateur. Ceci vous permettra de développer et de tester du code localement sur Kubernetes. Pour plus d’informations à ce sujet, on lira le document installation vagabonde du Propulseur (en anglais).

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

Ce que ne permet pas la solution type

Voici quelques limites du Propulseur. Les liens mènent à une documentation plus complète à ce sujet.

1. Niveau de sécurité de type entreprise. Bien que nous abordions plus loin quelques aspects relatifs à la sécurité, d’autres éléments doivent être pris en considération et d’autres mesures implantées pour obtenir une grappe solide, prête pour la production et capable d’accepter de nombreux utilisateurs. Lire la documentation de Kubernetes sur la sécurité en suivant les liens fournis. Une autre solution consisterait à acheter un service Kubernetes géré, comme le proposent de nombreux fournisseurs d’infonuagique, pareil service comportant de nombreuses fonctionnalités en sécurité.
2. Utilisateurs multiples. La grappe Microk8s de la solution modèle KAT autorise un contrôle des accès basé sur les rôles (RBAC) comme l’utilisent certains comptes de service dans les formules Helm. Nous vous encourageons à en apprendre davantage sur le RBAC afin de mieux saisir les rôles et les autorisations quand de nombreux utilisateurs se connectent à une grappe Kubernetes.
3. Considérations relatives à des nœuds multiples. KAT fonctionne sur une seule MV. C’est pourquoi la documentation n’aborde pas la question des nœuds multiples lors de l’installation de Kubernetes. Les affinités, les altérations et les tolérances exercent une influence sur l’ordonnanceur Kubernetes de façon à privilégier un nœud actif plutôt qu’un autre lors de l’installation des pods dans la grappe. Un utilisateur averti se renseignera sur le module d’extension pour nœuds multiples de Micork8s ici avant d’essayer une telle configuration (nous ne dispensons aucun soutien technique pour une configuration de ce genre).
4. Intégration au service d’infonuagique. Les fournisseurs de services en nuage proposent des modules d’extension Kubernetes spéciaux qui facilitent l’exploitation. Ainsi, il est possible de créer des équilibreurs de charge Amazon AWS, Microsoft Azure et Google au moyen des services d’abstraction Kubernetes afin d’équilibrer les charges extérieures. Nous vous incitons à explorer les possibilités d’intégration sur mesure que proposent ces fournisseurs, car elles ont donné de bons résultats avec Kubernetes sur leurs plateformes respectives.

Déploiement

Si vous êtes membre de l’ATIR, une nouvelle instance de la solution type KAT peut être déployée simplement en cliquant le lien « Kubernetes Automation Toolkit » et en suivant les instructions qui apparaissent sur la page.

Configuration et lancement de l’application

Avant de passer au déploiement, vous devriez avoir effectué ce qui suit sur votre compte, dans le nuage de l’ATIR :

1. créé un groupe de sécurité vous donnant accès aux MV de l’ATIR (AWS et Azure) par SSH (TCP port 22) à partir de l’adresse IP de la MV;
2. configuré une clé SSH privée pour vous connecter aux MV de l’ATIR;
3. choisi un identifiant et un mot de passe pour vos MV Linux (dans les paramètres).

Si vous avez des questions concernant votre compte ATIR, veuillez lire le Guide technique de CANARIE avant d’aller plus loin. Vous devez avoir complété les étapes des diapositives 1 à 16 et 26 à 36 avant d’installer la solution type KAT. Vous devez pouvoir créer une MV Linux dans l’ATIR et vous y connecter par SSH avant d’aller plus loin.

Déploiement de la solution type KAT sur une MV de l’ATIR:

1. Ouvrez une séance dans le nuage de l’ATIR et allez à l’onglet « Provisioning ».
2. Cliquez le menu puis le bouton .
3. Sélectionnez un des BigBitBus-KAT-Blueprints pour déployer la solution sur AWS ou Azure et cliquez le bouton « Next ». Remarque : dans l’exemple ci-dessous, nous déploierons la solution dans Amazon AWS, mais les étapes sont les mêmes pour un déploiement dans Azure.
   
   
4. Les quelques étapes suivantes serviront à ajouter des précisions sur la configuration, comme le montrent les saisies d’écran. Commencez par remplir les champs App Summary dans SETUP puis cliquez Next.
   
   Poursuivez la configuration en cliquant le logo Ubuntu, à gauche, et en saisissant les valeurs que voici dans les champs CONFIGURATION :Cloud : AWS-Canada ou Azure Canada
   Version : 20.04
   Layout : Ubuntu
   Plan : Amazon M5 Large ou Azure Standard F4s
   Remarque : il se pourrait qu’un avertissement vous indique que vous ne disposez pas d’un budget suffisant pour déployer l’application. Si c’est le cas, vous devrez supprimer certaines ressources dans l’ATIR afin de libérer assez d’espace.
   Resource Pool : [nom que vous avez donné au bassin de ressources du locataire]
   Volumes : root – 80 GB – gp2
   Networks : [zone az-availability par défaut du locataire]
   Security Groups : [groupe de sécurité par défaut]
   Public IP : choisissez EIP
5. Cliquez Next pour passer à l’écran Review.
6. Assurez-vous que tout est correct et poursuivez en cliquant . Vous devriez constater que l’installation de l’application a débuté.
7. Profitez de ce répit pour cliquer le nom de l’instance (« bbbtestinstance », ici) et obtenir plus d’informations au sujet de la MV sur laquelle s’installe KAT, notamment son adresse IP externe qu’on peut voir sur la saisie d’écran ci-dessous.
8. Dix à vingt minutes plus tard, le bouton lecture vert , devrait apparaître, signe que le Blueprint a bien été déployé (voir la saisie d’écran ci-dessus).
9. Cliquez l’onglet de la MV pour voir la série des mesures exécutées pendant et après le provisionnement. Pour plus de détails, cliquez à côté de chaque intervention.
10. L’étape la plus importante consiste à cliquer à côté de « BigBitBus-KATConfigOutput ». Vous afficherez le fichier de configuration de Kubernetes et le jeton dont vous aurez besoin pour vous connecter au tableau de bord par la suite.
11. Notez la valeur du jeton (copiez-la sur le bloc-notes). Sans elle, vous ne pourrez accéder au tableau de bord de Kubernetes.
12. Configurez le réacheminement du port 8080 de l’ordinateur au port 80 par un tunnel SSH menant à la MV de l’ATIR qui a été provisionnée. Cette étape sécurise l’accès de la solution type KAT aux services HTTP.Voici la commande Linux/Mac pour configurer cela.
    1. Utiliser la ligne de commande SSH pour créer un tunnel de localhost:8080 sur l’ordinateur à localhost:80 sur la MV de l’ATIR avec l’adresse IP externe (15.223.8.62, dans ce cas). Vous trouverez les valeurs de la connexion SSH (identifiant, mot de passe, clé SSH) dans les paramètres de l’utilisateur de l’ATIR (« bbbuser », dans notre cas). L’emplacement par défaut de la clé SSH privée est : /home/[userID]/.ssh/morphy.Commande:
       $ ssh –I /home/user/.ssh/morphy bbbuser@15.223.8.62 –L 8080:localhost:80 –N
    2. Pour configurer le réacheminement SSH avec l’outil Putty de Windows, suivez ces instructions : https://docs.bitnami.com/bch/faq/get-started/access-ssh-tunnel/.
       Si vous utilisez Putty, rappelez-vous de réacheminer vers localhost:8080, PAS vers localhost:8888 comme on l’indique dans le guide.
       

Vérification de l’installation

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

1. 1. Ouvrez un navigateur et allez à http://localhost:8080/frontend/
      Vous serez connecté au service frontal de la liste todos dans Vue.js.
      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.
   2. 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.
   3. À 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.
   4. 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 »
   5. 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.
   6. 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.

   Félicitations. La solution type KAT a bien été déployée!

   Nous préconisons vivement que vous visitiez le code source et le dépôt de documents GitHub pour en apprendre davantage sur les différents composants de KAT ainsi que sur Kubernetes et la façon de déployer des applications sur la plateforme KAT :

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

   Clôture

   Une fois que vous aurez fini d’expérimenter avec la solution type KAT, supprimez l’instance sur laquelle elle fonctionnait afin de réduire votre budget mensuel sur AWS ou Azure.

   1. Dans la liste des instances, sélectionnez l’instance de la MV sur laquelle vous avez déployé la solution type et sélectionnez « supprimer » dans le menu Actions. Vous détruirez la solution type avec l’instance de la MV sur laquelle elle a été déployée dans l’ATIR.

   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