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 (docker.io/library/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 YAML.

Redirigez également le résultat de la commande dans le fichier mariadb-deployment.yaml.

Ci-dessous la commande correspondante :

$ kubectl create deployment mariadb \ 
         --image=docker.io/library/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: ...

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éplicas 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...

Base et compte de test

1. Variables d’environnement du conteneur

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 :

MARIADB_DATABASE : nom de la base de données ;
MARIADB_USER : nom de l’utilisateur de base de données ;
MARIADB_PASSWORD : mot de passe de l’utilisateur.

Ces variables se déclarent au niveau du champ env du conteneur mariadb.

Ci-dessous l’extrait de configuration à ajouter :

env: 
 - name: MARIADB_ROOT_PASSWORD 
   value: mot-de-passe-root 
 - name: MARIADB_DATABASE 
   value: test 
 - name: MARIADB_USER 
   value: test 
 - name: MARIADB_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 MARIADB_DATABASE) ;
le nom de l’utilisateur (champ MARIADB_USER).

En reprenant ces différentes indications, la déclaration devrait...

Hébergement d’application en cluster