Cycle de vie et états des Pods

Les pods ne sont pas statiques : ils passent par différentes étapes, comme au cours d'un parcours. Comprendre ce « cycle de vie » est essentiel pour gérer efficacement vos applications dans Kubernetes.

Cela vous aide à savoir si votre application est saine, en cours de démarrage ou si elle a rencontré un problème.

Kubernetes répartit les pods en cinq phases principales. Ces phases donnent une vue d'ensemble de l'état actuel d'un pod :

• Pending : le pod a été accepté par Kubernetes, mais ses conteneurs n'ont pas encore démarré.
• Running : au moins un conteneur du pod est en cours d'exécution ou de démarrage.
• Succeeded : tous les conteneurs du pod se sont terminés correctement et ne redémarreront pas.
• Failed : tous les conteneurs se sont terminés et au moins l'un d'eux a échoué (par exemple, avec un code de sortie différent de zéro).
• Unknown : l'état du pod n'a pas pu être déterminé, souvent en raison de problèmes de communication.

Un pod se trouve dans la phase Pending lorsqu'il a été accepté par le serveur d'API Kubernetes, mais qu'un ou plusieurs de ses conteneurs n'ont pas encore été créés ou configurés.

Les raisons courantes sont les suivantes :

• L'image du conteneur est toujours en cours de téléchargement.
• Le cluster ne dispose pas de suffisamment de ressources (CPU/mémoire) pour planifier le pod.
• Les volumes sont toujours en cours de création ou de montage.

Examinons un exemple. Si vous essayez de déployer un pod avec une image qui n'existe pas, il peut rester bloqué dans l'état « Pending » ou afficher une erreur de récupération d'image.

Voici un exemple de définition de pod :

apiVersion: v1
kind: Pod
metadata:
  name: pending-pod-demo
spec:
  containers:
  - name: my-container
    image: non-existent-image:latest
    ports:
    - containerPort: 80

Pour vérifier son état, vous utiliseriez kubectl get pod. Vous pourriez voir quelque chose comme ceci :

$ kubectl get pod pending-pod-demo
NAME               READY   STATUS         RESTARTS   AGE
pending-pod-demo   0/1     ErrImagePull   0          5s

ErrImagePull indique que l'image n'a pas pu être récupérée, ce qui empêche le pod d'atteindre l'état Running.

La phase Running signifie que le Pod a été associé à un nœud et que tous ses conteneurs ont été créés avec succès. Au moins un conteneur est en cours d’exécution ou est en train de démarrer ou de redémarrer.

Il est important de noter qu’un Pod en cours d’exécution ne signifie pas automatiquement que l’application qu’il contient est saine ou pleinement fonctionnelle. Cela signifie simplement que les conteneurs sont actifs.

Voici une définition standard de Pod pour un serveur web Nginx. Après son application, votre Pod devrait rapidement passer à l’état « Running ».

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Une fois le déploiement effectué, la commande kubectl get pod afficherait :

$ kubectl get pod nginx-pod
NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          10s

La valeur 1/1 dans READY confirme qu’un conteneur sur un est prêt.

Ces phases représentent les états de terminaison d’un Pod :

• Succeeded : un Pod entre dans cette phase lorsque tous ses conteneurs se sont terminés avec succès et ne seront pas redémarrés. C’est typique des Pods qui exécutent des tâches ponctuelles ou des traitements par lots.
• Failed : un Pod se trouve dans la phase Failed lorsque tous ses conteneurs se sont terminés et qu’au moins un conteneur s’est terminé en échec, par exemple avec un code d’état différent de zéro.

La compréhension de ces phases vous aide à diagnostiquer la fin des tâches ou les erreurs de l’application.

La phase Unknown signifie que l’état du Pod n’a pas pu être déterminé. Il s’agit d’une phase rare, mais critique.

Cette situation se produit généralement lorsque le Kubelet, l’agent, du nœud sur lequel le Pod s’exécute cesse de communiquer avec le serveur d’API Kubernetes. Cela peut être dû à un problème réseau, à un Kubelet qui a planté ou à un problème affectant le nœud lui-même.

Bien que les Pods aient des phases globales, les conteneurs individuels qu’ils contiennent possèdent également leurs propres états, plus précis. Ces états influencent directement la phase globale du Pod :

• Waiting : le conteneur attend actuellement de démarrer. Cela peut être dû au téléchargement de l’image, à l’allocation de ressources ou à l’attente de la fin des conteneurs d’initialisation.
• Running : le conteneur s’exécute activement sans rencontrer de problème.
• Terminated : le conteneur a terminé son exécution. Il peut avoir réussi ou échoué.

Imaginez que vous venez de déployer un nouveau Pod. Vous exécutez kubectl get pod my-app et obtenez la sortie suivante :

NAME      READY   STATUS     RESTARTS   AGE
my-app    0/1     Pending    0          12s

Quelle est la raison la plus probable pour laquelle le Pod my-app se trouve à l’état Pending, avec 0/1 conteneur prêt ?

Vous avez appris que les Pods Kubernetes progressent à travers des phases distinctes : Pending, Running, Succeeded, Failed et Unknown. Ces phases fournissent une vue d’ensemble de l’état opérationnel d’un Pod.

Nous avons également abordé les états des conteneurs individuels (Waiting, Running et Terminated), qui contribuent à la phase globale du Pod. La surveillance de ces états avec kubectl get pod et kubectl describe pod, que vous étudierez plus en détail par la suite, est essentielle pour comprendre l’état de santé de votre application.

Ensuite, nous examinerons des modèles avancés de Pods et verrons comment exécuter plusieurs conteneurs regroupés au sein d’un même Pod grâce au modèle de conteneur auxiliaire.