Déploiement avec Kubernetes

Du pod aux déploiements

1. Pod

Nous avons vu qu’il est possible de créer un pod utilisant un container tomcat-eni-todo-h2-env:dev. Nous utilisons tout d’abord cette version, nous ajouterons l’externalisation de la base de données plus tard.

Nous lançons donc un pod eni-todo-h2 avec le container utilisant cette image. Il faut s’assurer que le container a bien démarré et fonctionne correctement.

$ kubectl run eni-todo-h2 \ 
   --image=registry.diehard.net:5000/eni-todo-tomcat-h2:dev \ 
   --env=" 
DB_DTB_JDBC_URL="jdbc:mysql://mariadb.diehard.net:3306/db_todo" \
   --env="DB_DTB_USERNAME=springuser" ... 
pod/eni-todo-h2 created 

Il est également possible de lancer le container avec un fichier YAML et la commande suivante :

$ kubectl apply -f eni-todo-h2.000.pod.yaml 
pod/eni-todo-h2 created 

Les fichiers YAML utilisés dans ce chapitre sont dans le dossier src/main/kubernetes du dépôt git de l’application eni-todo (https://github.com/halnx-todo/k8s-manifests).

a. Sondes et contrôle de santé

Kubernetes offre un système de sonde permettant de vérifier la santé (healthcheck) d’un pod. Il y a trois types de sondes :

• livenessprobe

• readinessprobe

• startupprobe

Toutes les trois se configurent de la même façon, avec des objets dans la définition du container.

Il existe trois mécanismes de sonde possibles :

• tcpSocket : la kubelet présente sur le nœud vérifie que le container a bien ouvert le port défini dans les paramètres de cette sonde.

• Exec : la kubelet présente sur le nœud vérifie que le script défini dans les paramètres de cette sonde s’exécute correctement (code retour 0) dans le container observé.

• httpGet : la kubelet présente sur le nœud vérifie que l’appel HTTP défini dans les paramètres de cette sonde retourne un code retour tel que défini (200 par défaut).

Figure 1 : Spécifications des sondes d’un pod

Les sondes ont :

• un délai d’attente avant d’être activées (initialDelaySeconds) ;

• une fréquence d’exécution (periodSeconds) ;

• un seuil ou nombre d’erreurs...

Services et Endpoints

Nous sommes passés rapidement sur le besoin d’avoir plusieurs pods pour maintenir le service, mais c’est précisément cette redondance qui permet de maintenir cette haute disponibilité.

Il faut donc un mécanisme pour répartir les flux des requêtes vers les pods. C’est le rôle des objets Service. Cette abstraction est utilisée pour fournir les informations nécessaires au cluster afin de faire les configurations réseau permettant la communication dans le cluster et avec l’extérieur.

Comme nous l’avons évoqué dans les chapitres précédents, les labels sont utilisés pour permettre la sélection des objets dans Kubernetes. Le mécanisme des labels est omniprésent dans un cluster. Les labels sont également utilisés pour associer (mapping) les pods à un service via l’utilisation d’un sélecteur.

<service>.<namespace>.svc.cluster.local 

apiVersion: v1 
kind: Service 
metadata: 
  labels: 
    app: eni-todo 
  name: eni-todo 
spec: 
  ports: 
  - port: 80 
    name: http8080 
    protocol: TCP 
    targetPort: 8080 
  selector: 
    app: eni-todo 
  sessionAffinity: ClientIP 
  type: ClusterIP 

$ kubectl get po -l app=eni-todo 
NAME                       READY   STATUS    RESTARTS   AGE 
eni-todo-95755d699-gldr6   1/1     Running   0          55m 
eni-todo-95755d699-jrzrg   1/1    ...

Secret et ConfigMap

Nous avons vu que nous écrivons les variables d’environnement directement dans la définition des pods (template de pod). Il est toujours préférable d’externaliser les fichiers de configuration, c’est à cela que servent ConfigMap et Secret.

Figure 9 : ConfigMaps et Secret

Il est possible de stocker des couples variable/valeur dans des objets de type ConfigMap et Secret. Mais là où un ConfigMap stocke les informations directement au format texte et en clair, un secret demande une valeur encodée au format base64, par exemple :

mysql_root_password: cjAwdC1hZWtpZThhaHdhaV8= 

Le stockage dans la base etcd est également différent, car les secrets sont chiffrés dans la base si l’option est activée dans kube-apiserver (--encryption-provider-config). 

Il est également possible de stocker des fichiers dans les deux types d’objets.

Dans un ConfigMap :

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: mariadb-init 
data: 
  init.sh: | 
    #!/bin/sh ...

StatefulSet

Après avoir vu comment accéder à une base de données externe, nous allons voir comment mettre une base de données dans notre cluster.

Un pod peut s’instancier sur n’importe quel node en fonction des ressources disponibles. Si cela fonctionne très bien pour des services sans conservation de l’état (stateless), ce n’est pas le cas des bases de données dont le rôle même est la conservation des données.

Au début de Kubernetes, une astuce consistait à forcer l’exécution d’un pod sur un node précis via une sélection par l’attribut nodeName ou bien à utiliser les mécanismes de nodeAffinity ou nodeSelector, pour nous assurer qu’un pod était instancié sur le node ayant des répertoires dédiés au stockage des données du pod, que le pod pouvait monter directement avec hostpath.

apiVersion: v1 
kind: Pod 
metadata: 
  labels: 
    app: mariadb 
  name: mariadb 
spec: 
  volumes: 
  - name: test-volume 
    hostPath: 
      path: /data/mariadb 
      type: DirectoryOrCreate 
  containers: 
  - image: mariadb:10.5.8 
    name: mariadb 
    nodeName: k8s-worker01 
    env: 
    - name: MYSQL_USER 
      value: "springuser" 
    - name: MYSQL_PASSWORD 
      value: "mypassword-quoor-uHoe7z" 
    - name: MYSQL_DATABASE 
      value: "db_todo" 
    - name: MYSQL_ROOT_PASSWORD 
      value: "r00t-aeKie8ahWai_" 
    volumeMounts: 
    - mountPath: /var/lib/mysql 
      name: test-volume 
    ports: 
      - name: mariadb 
        containerPort: 3306 
        protocol:...

PersistentVolume

Comme nous l’avons évoqué plusieurs fois, Kubernetes est un orchestrateur qui sélectionne, parmi son pool de nodes et selon les critères qu’on lui a donnés, le node sur lequel instancier le pod. Cela signifie que pour apporter de la persistance de données, celle-ci doit pouvoir être utilisable par le pod sur n’importe quel node. Les containers constituant les pods vont devoir monter les volumes présents sur leur node. Le node lui-même ayant probablement un montage de système de fichier à réaliser en amont (NFS, Gluster FS, etc.). Les objets PersistentVolume et PersistentVolumeClaim fournissent aux clusters (node, kublet…) les informations nécessaires pour réaliser ces différents montages de systèmes de fichier.

Figure 10 : Spécifications d’un volume persistant

Un volume persistant (Persistent Volume ou PV) dispose de plusieurs attributs :...

StorageClass

Figure 12 : Spécifications d’une classe de stockage

La classe de stockage (StorageClass) est la ressource permettant de fournir dynamiquement des PVC (et les PV derrière).

Elle a plusieurs attributs :

Routes ingress

Job et CronJob

Il est possible de lancer des tâches (jobs) dans Kubernetes. Les jobs sont uniques : ils ne sont joués qu’une seule fois.

Figure 14 : Spécifications d’un Job et d’un CronJob

Les attributs du job sont les suivants :

Il est également possible d’avoir des tâches récurrentes programmées à certaines dates : les cronjobs.

Les attributs notables d’un cronjob sont les suivants :