Editions ENI Livres | Vidéos | e-Formations
Cycle de vie d’un container dans Kubernetes
Objectifs du chapitre et prérequis
Les précédents chapitres ont beaucoup abordé les notions d’utilisation de Kubernetes au travers du déploiement de l’application MailHog. Cette application a été déployée de plusieurs manières différentes :
-
Manuellement à l’aide du dashboard Kubernetes.
-
Via la création d’objet à l’aide de kubectl.
-
Enfin, à l’aide de fichiers de définition des éléments à créer.
Ce chapitre va s’attarder sur le cycle de vie d’un container au travers de deux aspects :
-
La correspondance entre un pod et son container au niveau du moteur Docker.
-
Le mécanisme de surveillance des containers.
Gestion des crashs d’application
1. Consultation de l’état des pods
L’application MailHog déployée dans Kubernetes ne fait pour l’instant l’objet d’aucune surveillance. La seule chose réalisée par Kubernetes est de s’assurer que le container tourne correctement.
Un bon moyen de s’en rendre compte est de se connecter dans le container associé à l’application MailHog, de tuer le processus MailHog et de voir le compteur de démarrage s’incrémenter.
Ci-dessous la commande permettant de scruter l’état des pods de l’application portant le label app=mailhog :
$ kubectl get pods -l app=mailhog Ci-dessous le résultat de cette commande :
NAME READY STATUS RESTARTS AGE
mailhog-5c76b9bb6c-hc7s8 1/1 Running 0 3m31s 2. Connexion au pod
La connexion à un pod se fait en spécifiant les paramètres suivants à la commande kubectl :
-
Le mot-clé exec,
-
L’option pour indiquer qu’il s’agit d’une connexion interactive (-i).
-
L’option pour affecter un terminal (tty) à la connexion (-t).
-
Le nom du pod (cf. commande précédente) ou une référence à l’objet de déploiement (deployment/mailhog).
-
L’indicateur de fin des options de kubectl (--).
-
La commande à lancer : sh pour un shell.
Pour résumer, la commande à lancer sera la suivante :
$ kubectl exec -it deployment/mailhog -- sh Une fois projeté dans le contexte du container de MailHog, il est possible de consulter la liste des process présents avec la commande ps suivie de l’option -ef :
$ ps -ef Cette commande renvoie alors la liste des process présents dans le container :
PID USER TIME COMMAND
1 mailhog 0:00 MailHog
13 mailhog 0:00 sh
22 mailhog 0:00 ps -ef Outre les process 13 et 22 qui correspondent au shell et à la commande ps, le seul process présent est celui de MailHog qui porte le numéro 1.
Avant de tuer le process de MailHog, un répertoire test va être créé...
État d’un container
1. Pourquoi scruter l’état d’un container ?
Un process arrêté est le signe indéniable qu’une application est indisponible. En revanche, la réciproque n’est pas forcément vraie. En effet, un process, même s’il est lancé, peut être :
-
soit dans un état figé,
-
soit dans une boucle infinie,
-
soit dans un état saturé.
Une bonne pratique est d’aller au-delà de la simple vérification de la présence d’un process en réalisant des tests applicatifs.
Ces tests vont bien sûr dépendre énormément du type d’applicatif et de ce que l’administrateur est prêt à mettre en œuvre. Il convient de bien garder en tête le rapport coût/bénéfice, que ce soit au niveau de la consommation des ressources ou du développement à réaliser pour mettre en place cette surveillance. Ces tests peuvent être de plusieurs types (en allant du plus simple au plus compliqué) :
-
Surveiller la présence d’un port d’écoute.
-
Surveiller la présence d’un fichier.
-
Réaliser une connexion HTTP.
-
Se connecter à une base de données.
-
Faire appel à une page de diagnostic.
2. Readiness vs Liveness
Kubernetes permet de définir deux types de surveillance sur un container :
-
Les tests « readiness », permettant de savoir si un container est prêt (est-il démarré ? Est-ce que ses dépendances sont prêtes ?).
-
Les tests « liveness » permettant de savoir si un container est toujours utilisable (a-t-il suffisamment de mémoire ? Répond-il toujours en temps et en heure ?).
Dans le cas d’un test « readiness » négatif, le container sera écarté du trafic, mais ne sera pas supprimé. Un test de type « liveness » négatif aura des conséquences plus graves pour le container. En cas d’erreur, ce dernier sera arrêté pour être remplacé par un nouveau.
En plus de ces deux tests, il existe un test supplémentaire utilisé lors du démarrage d’un container « startupProbe »....
Définition de la capacité d’un pod
1. Pourquoi définir une capacité ?
Jusqu’à maintenant, les pods déployés n’ont jamais été bornés dans leur consommation. Si un pod se met à partir en boucle infinie ou à consommer toute la ressource mémoire d’un seul coup, il peut impacter d’autres pods se trouvant sur un même nœud.
La définition de la capacité d’un pod est là pour empêcher cette surconsommation. Dans le cas de la CPU, le pod sera tout simplement limité à la consommation maximale allouée. À part aller plus lentement, le programme ne sera pas plus impacté que cela. En revanche, une surconsommation de mémoire se traduira par la fin pure et simple du process via le mécanisme de OOM Killer (Out-Of-Memory Killer) du noyau Linux.
2. Réservation et surallocation
Au niveau des limites, il en existe deux : une valeur réservée et une valeur maximale. La première va réserver la ressource et la seconde va permettre de dépasser cette réserve temporairement.
Attention de ne pas trop jouer avec ces limites. Une machine sur laquelle la ressource mémoire est surallouée au-delà d’une certaine limite peut amener à des crashs ou des comportements erratiques.
Autre point, la ressource CPU est beaucoup plus encline que la mémoire à être surallouée. Attention bien sûr de rester raisonnable au niveau de cette surallocation.
3. Allocation de ressources à un container
Pour la suite du chapitre, les exemples seront pris avec l’application MailHog précédemment déployée.
Dans un déploiement, l’allocation de ressources se fait au niveau du champ spec --> containers --> resources d’un pod. Ce champ accepte deux enregistrements :
-
Le champ limits pour définir les consommations maximales d’un container.
-
Le champ requests pour définir la réservation des ressources.
Ces deux champs prennent en paramètre les mêmes options :
-
Le champ memory avec la quantité de mémoire à utiliser.
-
Le champ cpu avec la quantité de CPU à allouer.
Au niveau du contenu de ces champs, faites attention à l’interprétation...
