Orchestrez vos conteneurs avec Kubernetes

Découvrez la structure du fichier YAML

Bon, si je résume, vous savez comment créer une image applicative et vous savez comment exécuter un pod au sein d’un cluster Kubernetes. Mais il serait bien de pouvoir partager aux autres personas de l’équipe la façon de démarrer le pod sans passer par des commandes.

Pour faciliter le déploiement du site e-commerce dans différents environnements, il serait judicieux de centraliser les informations de déploiement (nom du pod, image, nombre de réplicas) dans un fichier exécutable unique, distribuable à toute l'équipe.

L’utilisation de commande pour déployer un pod est ce qu’on appelle une approche impérative. Nous demandons de déployer un pod sur le cluster. Lors de la mise en production d’une application, il est courant de recevoir un document comprenant toute une liste de commandes à taper. Ce document s’appelle le manuel d’installation et décrit étape par étape comment installer l’application. Il est généralement rédigé par les Ops.

Par exemple, les commandes que vous avez lancées pour créer des pods sont une approche impérative. Vous avez lancé 5 commandes afin de créer 5 pods différents.

Mais faire du copier/coller de commandes n’est pas une bonne pratique. Effectivement, il se peut que la personne faisant le déploiement soit mal réveillée, malade, ou qu’elle ait mal dormi et a pu avoir oublié une commande.

Ce n’est donc pas une approche optimale. Le mieux serait d’avoir un concept ou vous pourriez spécifier ce dont vous avez besoin et laisser Kubernetes se charger de créer les ressources. C’est là où intervient le concept de "infrastructure as code".

L’infrastructure as code est un concept ou l’infrastructure est gérée au travers de fichiers. Cette approche est ce qu’on appelle une approche déclarative et fait partie des bonnes pratiques à suivre.

Kubernetes utilise une approche déclarative pour la gestion des pods. Cela signifie que vous définissez l'état souhaité de vos pods, et il s'occupe de les mettre en place et de les maintenir dans cet état.

Avec Kubernetes, vous pouvez gérer vos déploiements de deux manières : soit au travers des commandeskubectl , soit au travers de fichiers que l’on appelle manifest, décrit au format YAML.

Découvrez le Deployment

Pour déployer notre site e-commerce de LiveCorp, vous allez devoir créer un fichier YAML afin de spécifier l’état cible que vous souhaitez atteindre dans Kubernetes. Ce fichier YAML déclare une ressource de type “Deployment”.

Une ressource “Deployment” dans Kubernetes,  c’est une ressource qui décrit l'état souhaité d'un ensemble de pods. Il définit les caractéristiques suivantes :

• Le nombre de pods à exécuter: Vous pouvez spécifier le nombre de pods pour le déploiement. Kubernetes créera et maintiendra ce nombre de pods en cours d'exécution.

• L'image du conteneur à exécuter: Vous devez spécifier l'image du conteneur que vous souhaitez exécuter pour vos pods.

• Les ressources allouées aux pods: Vous pouvez définir les ressources CPU et mémoire requis par chaque pod.

• La stratégie de mise à jour: Vous pouvez définir comment Kubernetes doit mettre à jour les pods vers une nouvelle version de l'image.

La création d’un déploiement dans Kubernetes passe par le kind Deployment.

Une ressource Deployment dans Kubernetes est un contrôleur qui gère la création, la mise à l'échelle et la mise à jour des pods. Il vous permet de définir l'état souhaité pour un ensemble de pods, et Kubernetes s'occupe de le maintenir.

Les ressources Deployments sont particulièrement utiles pour les applications conteneurisées, car ils permettent de s'assurer que le nombre correct de pods est en cours d'exécution et qu'ils sont toujours à jour avec la dernière version de votre application.

Afin de stocker, rejouer et versionner le déploiement de pods dans Kubernetes, le meilleur moyen est de passer par un fichier YAML qui définit le déploiement que l’on veut appliquer sur le cluster.

Dans ce fichier YAML sera spécifié :

• le nom du déploiement ;

• le nombre de pods que l’on veut déployer ;

• le nom de l’image contenant l’application ;

• le port où l’application est accessible.

Écrivez votre fichier YAML de déploiement

Reprenons le déploiement du site e-commerce de LiveCorp. Le site est conteneurisé dans une image qui s’appelle nginx. L’application écoute sur le port 80 et nécessite un minimum de 5 réplicas afin de garantir une haute disponibilité.

Alice vous demande alors de chercher sur Internet afin de trouver un exemple de fichier de déploiement sur Kubernetes. Après quelques recherches et modifications pour l’adapter au déploiement du site e-commerce, voici le fichier YAML de déploiement que vous avez créé :

apiVersion: apps/v1
kind: Deployment
metadata:
name: site-ecommerce-deployment
spec:
replicas: 5
selector:
matchLabels:
app: site-ecommerce
template:
metadata:
labels:
app: site-ecommerce
spec:
containers:
- name: site-ecommerce
image: site-ecommerce:1.2.0
ports:
- containerPort: 8080

Prenons un peu de recul afin de comprendre ce fichier !

La première ligne est importante, c’est elle qui va indiquer à Kubernetes quelle version de l’API Kubernetes utiliser.

apiVersion: apps/v1
…

L’apiVersion

L'élément apiVersion dans Kubernetes est une chaîne de caractères qui spécifie la version de l'API que vous utilisez pour un objet de ressource particulier. Il joue un rôle crucial dans la gestion de vos ressources Kubernetes.

L' apiVersion est composé de deux parties séparées par une barre oblique (/):

• Le “Groupe d'API” (API Group) qui indique le groupe auquel appartient la ressource. Le groupe par défaut, également appelé groupe principal, est vide et n'est pas explicitement mentionné dans l'apiVersion. Les groupes nommés, tels que apps ou extensions, requièrent une spécification explicite.

• la “Version” qui représente la version spécifique de l'API utilisée pour la ressource. Kubernetes prend en charge plusieurs versions d'API pour certains groupes, offrant une rétrocompatibilité et permettant l'introduction de nouvelles fonctionnalités.

L'apiVersion est essentiel pour la compatibilité du déploiement. Elle garantit que vous utilisez la version d'API appropriée pour votre cluster et les ressources que vous gérez. Grâce à l’apiVersion, vous pouvez aussi déterminer les fonctionnalités disponibles pour la ressource. Différentes versions d'API peuvent proposer des fonctionnalités différentes.

Dans notre cas, l’apiVersion à utiliser est  apps/v1  car nous allons manipuler la ressource Deployment.

La deuxième ligne est la ressource que vous voulez créer sur le cluster. Pour le déploiement du site e-commerce, il faut utiliser la ressource Deployment.

…
kind: Deployment
…

Les types de "kind"

Un "kind" dans Kubernetes représente un type d'objet API. Il définit la structure et les propriétés d'un objet Kubernetes spécifique. Les Pods et les Deployment sont des “kind” de Kubernetes. Ils en existent plusieurs, tous dépendant de l’apiVersion utilisé.

Les lignes suivantes sont des métadonnées, c’est-à-dire des données supplémentaires afin d’enrichir la ressource que vous allez créer.

…
metadata:
name: site-ecommerce-deployment
…

Il faut à minima nommer le déploiement et donc avoir une balise  name  présente ici. Ce nom doit être unique dans tout le cluster. C’est ainsi que Kubernetes pourra identifier tous les déploiements présents sur le cluster.

Le bloc suivant est le bloc de spécification de la ressource créée. Ici, vous allez créer un Deployment. Il faut alors spécifier un certain nombre d’informations afin que le déploiement soit effectif.

…
spec:
replicas: 5
selector:
matchLabels:
app: site-ecommerce
template:
metadata:
labels:
app: site-ecommerce
spec:
containers:
- name: site-ecommerce
image: site-ecommerce:1.2.0
ports:
- containerPort: 8080

La ligne replica indique le nombre de pods à déployer. Pour le site e-commerce, il en faut 5. Spécifiez ce chiffre pour le déploiement et Kubernetes assurera que ces 5 pods sont toujours en cours d'exécution sur le cluster.

…
spec:
replicas: 5
…

Ensuite, la ligne selector précise comment Kubernetes trouve quel pod gérer. Il se base sur la ligne du dessous qui spécifie les labels des pods. Pour le site e-commerce, le fichier spécifie de poser le label  app: site-ecommerce  sur les pods. Ces deux labels doivent être identiques afin que Kubernetes retrouve bien les pods à gérer.

…
spec:
selector:
matchLabels:
app: site-ecommerce
template:
metadata:
labels:
app: site-ecommerce
…

Enfin, le dernier bloc, à partir de la ligne “spec”, spécifie le nom de l’image à déployer, le nom du conteneur dans le pod, ainsi que le port de l’image.

…
spec:
containers:
- name: site-ecommerce
image: site-ecommerce:1.2.0
ports:
- containerPort: 8080

Dans le cas du déploiement du site de LiveCorp, le nom de l’image est  site-ecommerce  en version 1.2.0. Le nom du conteneur dans le pod que va créer Kubernetes sera  site-ecommerce  et le port d’écoute du conteneur sera 8080.

Avec ce fichier, Kubernetes aura toutes les informations nécessaires pour appliquer votre premier déploiement !

Il est maintenant temps d’appliquer ce fichier sur votre cluster Kubernetes et de laisser Kubernetes créer les pods nécessaires !

Dans ce screencast, vous avez vu comment :

• déclarer votre fichier YAML de déploiement de l’application ;

• appliquer ce fichier sur le cluster Kubernetes ;

• vérifier que vous avez le bon nombre de pods.

Appliquez votre premier fichier YAML sur Kubernetes

Pour appliquer ce fichier YAML sur le cluster Kubernetes, la commande à utiliser est toujours la commande  kubectl , qui est la seule commande à pouvoir interagir avec Kubernetes.

Kubectl permet d’appliquer directement un fichier YAML avec la sous-commande apply, ainsi que le flag  -f .

Appliquez votre fichier Deployment

Pour déployer votre fichier, la commande sera alors :

kubectl apply -f nginx-deploiment.yaml

Cette commande va lire le fichier YAML, créer les ressources Kubernetes définies dans le fichier et les déployer sur votre cluster Kubernetes.

Vérifiez l’état de votre déploiement

Une fois que vous avez appliqué le fichier YAML, vous pouvez vérifier que le pod est bien déployé avec la commande suivante :

kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
site-ecommerce-deployment-567d948-6ddk9   1/1     Running   0          2m13s
site-ecommerce-deployment-567d948-7q2sc   1/1     Running   0          2m13s
site-ecommerce-deployment-567d948-q9697   1/1     Running   0          2m13s
site-ecommerce-deployment-567d948-vplf7   1/1     Running   0          2m13s
site-ecommerce-deployment-567d948-vwzln   1/1     Running   0          2m13s

Cette commande affichera une liste de tous les pods en cours d'exécution sur votre cluster Kubernetes. Vous devriez y voir 5 pods nommés nginx avec l'état Running.

kubectl get pods -w

Cette commande affichera alors tous les événements de création de pods sur le cluster Kubernetes.

Analysez votre déploiement

Vous pouvez aussi vérifier que Kubernetes a bien créé une ressource de type Deployment dans le cluster avec la commande  kubectl get deploy .

Vous retrouverez le nom de votre déploiement, avec quelques informations supplémentaires liées à vos pods.

kubectl get deploy
NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
site-ecommerce-deployment   5/5         5                      5                    32s

Tout d’abord, dans la colonne READY, vous voyez que 5 pods sur 5 sont disponibles et en train de s’exécuter. Cela indique bien que Kubernetes a déployé les 5 réplicas du pod nginx. Si maintenant vous détruisez un pod, vous allez voir que Kubernetes va détecter qu’un pod est manquant et redémarrer automatiquement un nouveau pod afin d’avoir le nombre de réplicas spécifiés dans le YAML de déploiement.

kubectl delete pod/site-ecommerce-deployment-567d948-6ddk9
kubectl get deploy
NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
site-ecommerce-deployment   4/5         5                      4                   177m
site-ecommerce-deployment   5/5         5                      5                   177m

Vous voyez ici que Kubernetes est bien dans un paradigme déclaratif car il a détecté un changement dans la configuration du cluster et à appliquer de nouveau changement afin de converger vers l’état désiré.

Ensuite, la colonne UP-TO-DATE vous indique les pods qui sont à jour par rapport à la définition dans le fichier YAML. Cela est utile dans le cas d’une mise à jour de version d’image de pod. Par exemple, passer de la version 1.27 à la version 1.28 de nginx va modifier la colonne UP-TO-DATE au fur et à mesure du déploiement des nouveaux pods.

Enfin, la colonne AVAILABLE indique le nombre de pods qui sont disponibles pour supporter des requêtes entrantes. Vous avez pu voir que cette colonne reflète le nombre de pods dans la colonne READY.

À vous de jouer

Contexte

Alice : Tu sais maintenant comment déployer une application dans Kubernetes au travers d’un fichier YAML ! Je te propose de déployer ton image que tu as précédemment construite et poussée sur la registry.

Vous allez devoir créer un fichier Deployment qui contiendra :

• le type de ressource que vous voulez déployer (rappel : kind: Deployment) ;

• les metadonnées que vous voulez appliquées ;

• le nom de l’image complète présente dans votre registry ;

• le nombre de réplicas à déployer (petit rappel, le site e-commerce nécessite 5 réplicas) ;

• le port à exposer (rappel : 8080).

Consignes

1. Créez un fichier de déploiement YAML ;

2. Appliquez-le sur minikube ;

3. Vérifiez que le déploiement s’est bien déroulé.

En résumé

• Kubernetes utilise un paradigme déclaratif à la place d’un paradigme impératif.

• L'interaction avec le cluster Kubernetes passe par des API, chacun ayant sa propre version.

• Un kind spécifie la ressource avec laquelle on veut interagir.

• L’état souhaité est défini dans un fichier YAML.

• Le Deployment spécifie le nom de l’image, le nombre de réplicas ainsi que le nom et la version de l’image.

Maintenant que vous avez déployé votre pod de manière déclarative, regardons ensemble comment analyser un déploiement et diagnostiquer une erreur dans la configuration de votre fichier YAML.