Editions ENI Livres | Vidéos | e-Formations
Hébergement d’application en cluster
Objectifs du chapitre et prérequis
Ce chapitre va aborder un besoin spécifique au fonctionnement de Kubernetes : l’hébergement d’un groupe de pods fonctionnant en cluster. Ce type d’hébergement se retrouve souvent lors de la mise en place de base de données ou d’un ensemble de machines fonctionnant en cluster pour offrir de la haute disponibilité.
La gestion de la persistance de données sera abordée puisqu’elle diffère légèrement du mécanisme précédemment abordé.
La synchronisation des données entre pods sera quant à elle abordée dans le chapitre suivant.
Déploiement d’une base de données MariaDB
1. Origine du besoin
Le lancement d’une base de données dans Kubernetes ne constitue pas en soi une difficulté : il existe des images pour la plupart des bases de données open source du marché.
La principale difficulté va venir de deux aspects :
-
La persistance de la donnée.
-
La mise en place de la résilience.
Par la suite, l’exercice va consister à déployer une base de données de type MariaDB et mettre en place une réplication.
2. Déploiement
a. Choix de l’image Docker
Sur le site Docker Hub (https://hub.docker.com), la base de données est disponible dans l’image officielle mariadb (https://hub.docker.com/_/mariadb).
Une première installation va être réalisée afin de se familiariser avec cette dernière.
b. Version initiale du fichier de déploiement
Comme vu précédemment, kubectl permet de créer une ébauche de fichier de déploiement.
Pour cela, passez-lui les options suivantes :
-
Le verbe create suivi du type (deployment).
-
Un nom pour le déploiement (mariadb).
-
L’option image suivie du nom d’image à utiliser (mariadb).
-
L’option --dry-run pour ne pas créer directement le déploiement.
-
L’option --output yaml pour obtenir le résultat au format YAMLL
Redirigez également le résultat de la commande dans le fichier mariadb-deployment.yaml.
Ci-dessous la commande correspondante :
$ kubectl create deployment mariadb \
--image=mariadb --dry-run \
--output yaml > mariadb-deployment.yaml c. Gestion de la réentrance
Afin de gérer la réentrance, les champs inutiles (vides, nuls ou à une valeur par défaut) vont être supprimés.
Ci-dessous la liste des champs à supprimer :
-
metadata --> creationTimestamp
-
spec --> replicas
-
spec --> strategy
-
spec --> template --> metadata --> creationTimestamp
-
spec --> template --> spec --> containers --> resources
-
status
Ci-dessous le contenu du fichier mariadb-deployment.yaml après ces modifications :
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: mariadb ...Mise en place d’un StatefulSet
1. Augmentation du nombre de pods associés au déploiement
En informatique, l’augmentation du nombre de lancements d’une même application permet de régler deux types de problèmes :
-
Augmentation de la résilience d’un système.
-
Augmentation de la capacité de traitement d’un système.
Kubernetes offre un mécanisme permettant de faire de la montée en charge automatique au niveau des déploiements.
Pour changer le nombre de pods associés à un déploiement, vous pouvez vous appuyer sur la commande kubectl suivie des options suivantes :
-
Le verbe scale.
-
Le type d’objet à modifier (deployment).
-
Le nom de l’objet à modifier (mariadb).
-
Le nombre de réplicats souhaité (--replicas=2).
Pour passer de 1 à 2 pods, l’opération pourra se faire avec la commande suivante :
$ kubectl scale deployment mariadb --replicas=2 Consultez l’état des pods de mariadb :
$ kubectl get pods -l app=mariadb --watch Ci-dessous les premières lignes renvoyées par cette commande :
NAME READY STATUS RESTARTS AGE
mariadb-6c758c6984-4pnjw 0/1 ContainerCreating 0 1s
mariadb-6c758c6984-czsbw 1/1 Running 0 3m Au bout de quelques secondes, la ligne suivante doit apparaître :
mariadb-6c758c6984-4pnjw 0/1 Running 0 4s Au bout d’environ 1 minute, les lignes suivantes doivent apparaître (une nouvelle toutes les minutes) :
mariadb-6c758c6984-4pnjw 0/1 Running 1 65s
mariadb-6c758c6984-4pnjw 0/1 Running 2 2m4s Le nouveau pod n’arrive pas à démarrer.
Afin de comprendre ce qu’il se passe, consultez l’état du pod :
$ kubectl describe pods mariadb-6c758c6984-4pnjw La section Events devrait contenir le message rencontré...
Base et compte de test
1. Variables d’environnement du container
Pour la suite de l’exercice, afin de tester la réplication, une base et un compte de test vont être créés.
L’image Docker de MariaDB supporte ce type d’opérations. Pour les réaliser, elle s’appuie sur le contenu des variables suivantes :
-
MYSQL_DATABASE : nom de la base de données.
-
MYSQL_USER : nom de l’utilisateur de base de données.
-
MYSQL_PASSWORD : mot de passe de l’utilisateur.
Ces variables se déclarent au niveau du champ env du container mariadb.
Ci-dessous l’extrait de configuration à ajouter :
env:
- name: MYSQL_ROOT_PASSWORD
value: mot-de-passe-root
- name: MYSQL_DATABASE
value: test
- name: MYSQL_USER
value: test
- name: MYSQL_PASSWORD
value: test 2. ConfigMap et secret
a. Pourquoi y faire appel ?
Le nombre de variables est encore petit. Toutefois, il devient intéressant de commencer à stocker ces éléments dans des emplacements plus appropriés : les ConfigMaps et les secrets.
b. Structure d’un objet ConfigMap
Les objets ConfigMap (ou cm) sont des objets assez simples. Ci-dessous la structure minimum :
-
Le champ apiVersion et kind.
-
Le champ metadata constitué du champ name (contenant le nom de l’objet ConfigMap).
-
Le champ data avec les variables d’environnement à déclarer.
Pour l’exercice, l’objet ConfigMap portera le nom mariadb. Il stockera les informations suivantes :
-
Le nom de la base de données (champ MYSQL_DATABASE).
-
Le nom de l’utilisateur (champ MYSQL_USER).
En reprenant ces différentes indications, la déclaration...
