Cycle de vie d’un conteneur dans Kubernetes

1. Consultation de l’état des pods

L’application Mailpit 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 conteneur tourne correctement.

Un bon moyen de s’en rendre compte est de se connecter dans le conteneur associé à l’application Mailpit, de tuer le processus Mailpit 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=mailpit :

$ kubectl get pods -l app=mailpit 

Ci-dessous le résultat de cette commande :

NAME                       READY   STATUS    RESTARTS   AGE 
mailpit-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 :

Pour résumer, la commande à lancer sera la suivante :

$ kubectl exec -it deployment/mailpit -- sh 

Une fois projeté dans le contexte du conteneur de Mailpit, 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 conteneur :

PID   USER     TIME   COMMAND 
   1  root     0:00  /mailpit 
  13  root     0:00  sh 
  22  root     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 Mailpit qui porte le numéro 1.

Avant de tuer le process de Mailpit...

1. Pourquoi scruter l’état d’un conteneur ?

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 :

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é) :

2. Readiness vs Liveness

Kubernetes permet de définir deux types de surveillance sur un conteneur :

Dans le cas d’un test « readiness » négatif, le conteneur sera écarté du trafic, mais ne sera pas supprimé. Un test de type « liveness » négatif aura des conséquences plus graves pour le conteneur. 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 conteneur « startupProbe »....

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 conteneur

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 :

Ces deux champs prennent en paramètre les mêmes options :

Au niveau du contenu de ces champs, faites attention à l’interprétation...