Comprendre les pods Kubernetes

Le Pod est un concept clé à comprendre lorsque l'on travaille avec Kubernetes. Dans cet article, nous aurons un aperçu du Pod Kubernetes et d'autres concepts intéressants qui lui sont liés, comme la planification, les hooks de cycle de vie, les sondes et bien plus encore.

Comprendre les pods Kubernetes
Photo par Michel Jasmund / Unsplash

Pods

Le Pod est la plus petite unité de calcul de Kubernetes. Il s'agit d'un objet Kubernetes représentant un ou plusieurs conteneurs. Les conteneurs à l'intérieur d'un Pod partagent la même adresse IP, qui est l'adresse IP du Pod.

Les conteneurs d'un Pod peuvent communiquer entre eux localement sur n'importe quel port, en utilisant l'adresse IP 127.0.0.1 et monter les volumes déclarés au niveau du Pod.

Les Conteneurs d'initialisation sont des conteneurs spéciaux utilisés pour les tâches d'initialisation. Ils sont exécutés avant le démarrage des conteneurs. Si un conteneur d'initialisation échoue, le Pod est considéré comme ayant échoué et est traité conformément à son Politique de redémarrage.

Les Pods peuvent également avoir des conteneurs side-car qui s'exécutent aux côtés du conteneur principal pour fournir des fonctionnalités supplémentaires telles que la journalisation, la surveillance, la synchronisation des données, etc. Voici la Référence API du Pod pour tous les champs que nous pouvons utiliser dans les manifestes.

Cycle de vie des pods

Planification

Etat des pods

L'objet Pod a un champ status qui prend ses valeurs à partir du champ phase de l'objet PodStatus contenant des informations sur l'état d'un Pod. Les phases disponibles, représentant les états d'un Pod ( Pending, Running, Succeeded, Failed, Unknown) sont décrites ici. Dans la sortie de commande ci-dessous :

$ kubectl get pods -n kube-system
NAME                                  READY   STATUS    RESTARTS        AGE
coredns-55cb58b774-xrqzp              1/1     Running   0               4d5h
(...)

les STATUS : les valeurs possibles pour la colonne incluent les valeurs du statut des pods, ainsi que des valeurs supplémentaires telles que :

  • CrashLoopBackOff : lorsque le pod ne parvient pas à redémarrer à plusieurs reprises
  • Terminating : lorsqu'un pod est en cours de suppression
$ kubectl describe pods/coredns-55cb58b774-xrqzp -n kube-system
Name:                 coredns-55cb58b774-xrqzp
Namespace:            kube-system
(...)
Status:               Running
(...)

Conditions des pods

La routine shell PodStatus possède également un tableau de PodConditions par lequel le Pod est passé ou non. Pour plus de détails sur les conditions gérées par Kubelet, consultez conditions du pod. Les conditions sont affichées dans la sortie de la commande kubectl describe sur un Pod.

$ kubectl describe pods/coredns-674b8bbfcf-przl7 -n kube-system
(...)
Conditions:
  Type                        Status
  PodReadyToStartContainers   True 
  Initialized                 True 
  Ready                       True 
  ContainersReady             True 
  PodScheduled                True 
(...)

Etat des conteneurs, politiques de redémarrage et sondes

Les conteneurs d'un Pod ont Etats qui sont suivis par Kubernetes, afin que Kubelet puisse, par exemple, redémarrer les conteneurs pour gérer certaines pannes. Ces états sont actuellement Waiting, Running et Terminated Voir États des conteneurs Pods pour plus de détails. En cas de panne, les conteneurs sont redémarrés en fonction de leur politique de redémarrage.

Kubelet effectue également périodiquement certains diagnostics sur les conteneurs, appelés sondes pour déterminer par exemple s’ils ont démarrés ( startupProbe), fonctionnent correctement (livenessProbe) ou sont prêts à recevoir du trafic via les points de terminaison des services Kubernetes (readinessProbe). Les sondes de conteneurs sont personnalisables et les mécanismes de sondes utilisés pour effectuer les diagnostics sont soit l'exécution de code ( exec) ou des requêtes réseau (httpGet, tcpSocket, grpc).

Voici un exemple de manifeste de configuration pour les sondes et la politique de redémarrage d'un Pod : pod-utilisant-des-sondes-et-une-politique-de-redémarrage.

Hooks de cycle de vie des conteneurs d'un Pods

Les hooks de cycle de vie de conteneurs Kubernetes rendent les conteneurs conscients des événements de leur cycle de vie de gestion. Les hooks sont exécutés sur certains événements de gestion des conteneurs comme la création et l'arrêt. Actuellement, deux hooks sont exposés aux conteneurs :

  • PostStart: exécuté après la création du conteneur, avant que le conteneur n'entre dans l'état Running .
  • PreStop: exécuté avant l'arrêt du conteneur, avant que le conteneur n'entre dans l'état Terminated .

Voir hooks de cycle de vie des conteneurs pour plus de détails. Les conteneurs peuvent gérer les hooks et exécuter du code lorsque les hooks sont exécutés. Les gestionnaires de hooks actuellement disponibles sont listés ici : gestionnaires de hooks de cycle de vie. Voir implémentation de gestionnaires de hooks pour les détails.

Pour les détails sur les exécutions des gestionnaires de hook (comment les gestionnaires de hooks sont exécutés en fonction des actions de hook : httpGet, exec, sleep... voir exécution du gestionnaire de hooks.

Pour plus de détails sur les garanties de livraison des hooks (garanties concernant l'envoi de hooks par Kubernetes lors des événements de gestion du cycle de vie des conteneurs), consultez garanties-de-livraison-des-hooks.

Pour un exemple d'implémentation des actions de hooks de cycle de vie, consultez manifeste-pour-hook-de-cycle-de-vie-du-pod.

Suppression des pods

kubectl delete , par défaut termine les conteneurs du Pod de façon gracieuse. Ce qui signifie qu'un signal SIGTERM est envoyé au premier processus (PID 1) du ou des conteneurs du Pod ciblé. C'est ce qui se passe lorsque des Pods sont supprimés à l'intérieur d'un cluster Kubernetes (avec kubectl delete or kubectl scale , par le HPA ou autre).

Une période de grâce de 30 secondes par défaut sera alors respectée, afin de donner le temps au processus ciblé d'arrêter ses services (ne pas accepter de nouvelles requêtes) et de terminer les requêtes déjà acceptées. Si la période de grâce expire, le processus ciblé sera terminé violemment. Lors de l'utilisation de la commande kubectl, la période de grâce peut être transmise comme option pour modifier la valeur par défaut. Vous pouvez également définir la période de grâce dans vos déclarations de Pods :

spec:
  terminationGracePeriodSeconds: 60 # in seconds

Toutes les applications ne gèrent pas SIGTERM correctement, alors assurez-vous que votre application principale s'arrêtera correctement lors de la réception du signal SIGTERM .

Si votre application ne s'arrête pas correctement après avoir reçu le signal SIGTERM , vous pouvez utiliser le hook de cycle de vie preStop pour exécuter une commande d'arrêt gracieux spécifique avant d'envoyer le signal SIGTERM au premier processus du conteneur du Pod.

La routine shell preStop est bloquante, ce qui signifie qu'elle doit se terminer avant que l'appel de suppression du pod ne soit envoyé. Par exemple, les processus nginx se termineront immédiatement lors de la réception du signal SIGTERM au lieu de se terminer gracieusement... et se terminer gracieusement lorsqu'ils reçoivent un signal QUIT . Pour le cas de nginx donc, pour que les Pods s'arrêtent gracieusement, nous pouvons par exemple faire ce qui suit :

(...)
spec:
  containers:
  (...)
    lifecycle:
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

Voilà ce que je voulais partager sur les pods Kubernetes. J'espère que cela vous sera utile.

Vous souhaitez signaler une erreur ou poser une question ? N'hésitez pas à m'envoyer un e-mail à gmkziz@hackerstack.org.Je serai heureux de vous lire.

Si vous aimez mes articles, pensez à vous inscrire à ma newsletter afin de recevoir les derniers articles dès qu'ils sont disponibles.

Prenez soin de vous, continuez à apprendre et à bientôt pour le prochain post 🚀