Remarque perev. : Cet article poursuit le cycle de documents d'un rédacteur technique de Google, travaillant sur la documentation pour Kubernetes (Andrew Chen) et directeur de l'ingénierie logicielle de SAP (Dominik Tornow). Leur objectif est d'expliquer clairement et clairement les bases de Kubernetes. La dernière fois, nous avons traduit un article sur la haute disponibilité , et maintenant nous parlerons d'un concept aussi basique dans Kubernetes que pod.
Kubernetes est un moteur d'orchestration de conteneurs conçu pour exécuter des applications conteneurisées sur plusieurs nœuds, communément appelés cluster. Dans ces publications, nous utilisons une approche de modélisation des systèmes pour améliorer la compréhension de Kubernetes et de ses concepts sous-jacents. Les lecteurs sont encouragés à avoir déjà une compréhension de base de Kubernetes.
Les pods sont les éléments de base de Kubernetes, mais même les utilisateurs expérimentés de Kubernetes ne peuvent pas toujours expliquer de quoi il s'agit.
Cette publication propose un modèle de pensée concis qui met en lumière les caractéristiques déterminantes des pods Kubernetes. Pour des raisons de brièveté, j'ai dû omettre certaines autres fonctionnalités des
pods , telles que les
sondes de
vivacité et de préparation , le partage des ressources
(y compris le partage d'espace de noms récemment apparu - environ Transl. ) , Travailler avec le réseau.
Définition
Un pod est une demande d'exécution d'un ou plusieurs conteneurs sur un seul nœud.
Un pod est défini en présentant une demande d'
exécution d' un ou plusieurs conteneurs sur un seul nœud, et ces conteneurs partagent l'accès aux ressources telles que les volumes de stockage et la pile réseau.
Cependant, dans la vie de tous les jours, le terme "pod" peut être utilisé à la fois dans le sens de cette
demande et dans le sens de la
collecte de conteneurs qui sont lancés en réponse à la demande. Par conséquent, dans la publication, nous utiliserons le mot "pod" lorsque nous parlerons de la demande, et pour le deuxième cas - utiliser l'expression "ensemble de conteneurs".
Les pods sont considérés comme les blocs de construction de base de Kubernetes car toutes les charges de travail dans Kubernetes - par exemple,
Déploiements ,
ReplicaSets et
Jobs - peuvent être exprimées sous forme de pods.
Pod est le
seul et unique objet dans Kubernetes qui provoque l'exécution des conteneurs.
Pas de dosette - pas de contenant!
Schéma 1. Déploiement, ReplicaSet, pod et conteneursArchitecture de Kubernetes
Schéma 2. Pods, Scheduler et KubeletDans cette illustration, les objets et composants correspondants sont mis en surbrillance. Les
pods sont représentés comme des
objets pod Kubernetes et fonctionnent avec eux:
Objets Kubernetes
Figure 3. Objets KubernetesCette illustration montre les objets Kubernetes chargés de travailler avec le pod:
- l'objet pod réel (Pod Object) ;
- Objet de liaison
- Objet Node
Pod Object définit l'ensemble des conteneurs qui seront lancés et la
stratégie de redémarrage souhaitée en cas de panne de conteneur, et surveille également l'état de lancement.
L'objet de liaison lie l'
objet pod à l'objet nœud , c'est-à-dire attribue un pod à l'hôte pour un lancement ultérieur.
Node Object représente un nœud dans un cluster Kubernetes.
Traitement des pods
Schéma 4. Traitement du pod'aLorsqu'un pod est créé par un utilisateur ou un contrôleur tel que
ReplicaSet Controller ou
Job Controller , Kubernetes traite le pod en deux étapes:
- Le planificateur planifie un pod,
- Kubelet lance la capsule.
Planification des pods
Figure 5. Cycle de contrôle du planificateur KubernetesLa tâche du
planificateur dans Kubernetes est de planifier un pod, c'est-à-dire de lui affecter un nœud approprié dans le cluster Kubernetes pour un lancement ultérieur.
Association d'un objet pod à un objet nodeUn pod est affecté à un nœud (ou
s'y lie ) si et seulement s'il existe un objet de liaison qui a:
- l'espace de noms est égal à l'espace de noms du pod,
- le nom est égal au nom du pod,
- le type de cible est égal au
Node , - le nom de la cible est égal au nom du nœud.
(Les amateurs d'aventure peuvent jeter un coup d'œil à l'essentiel de Kelsey Hightower GitHub intitulé «
Création et planification manuelle d'un module », un guide étape par étape sur la création d'un objet de reliure manuelle.)
Lancement du pod
Schéma 6. Cycle de contrôle du kubeletLa tâche de Kubelet est de lancer le pod, ce qui signifie essentiellement lancer un ensemble de conteneurs de pod. Le lancement du pod Kubelet se déroule en deux phases: l'initialisation et la scène principale.
En règle générale, un ensemble de conteneurs pendant la phase d'initialisation effectue des travaux préparatoires, tels que la préparation du répertoire et de la structure de fichiers nécessaires. Et l'ensemble des conteneurs de la phase principale effectue déjà les tâches «les plus importantes».
Dans la vie de tous les jours, bien que ce ne soit pas tout à fait correct, le terme «pod» implique souvent un ensemble de conteneurs dans la phase principale ou une signification encore plus étroite du conteneur «le plus important» de la phase principale.
Schéma 7.1. Démarrage d'un pod, phase d'initialisation (init) et phase principale (principale)Pendant l'initialisation, Kubelet démarre séquentiellement les conteneurs conformément aux spécifications du
.Spec.InitContainers et dans l'ordre spécifié dans la liste. Pour réussir le lancement du pod et en tenant compte de la stratégie de redémarrage, ses conteneurs d'initialisation doivent démarrer et se terminer avec succès.
Pendant la phase principale, Kubelet lance simultanément des conteneurs conformément aux spécifications du
.Spec.Containers . Ici, pour un lancement réussi du pod, et en tenant compte de la politique de redémarrage, ses principaux conteneurs doivent être démarrés et terminés avec succès ou travailler un temps illimité.
Schéma 7.2. Pod en cours d'exécution, détails de ce processusEn cas de défaillance d'un conteneur, lorsque le conteneur cesse de fonctionner avec un
code de sortie différent de zéro (0), Kubelet peut redémarrer le conteneur conformément à la stratégie de redémarrage du pod. Cette stratégie a l'une des significations suivantes:
Always , en
OnFailure ,
Never .
La politique de redémarrage du pod a une sémantique différente pour les conteneurs init et les conteneurs principaux: si le lancement des conteneurs init doit aboutir, les conteneurs principaux peuvent ne pas se terminer.
Politique de redémarrage pour le conteneur initLe conteneur initial sera redémarré (c'est-à-dire qu'il entraînera le lancement d'un nouveau conteneur avec les mêmes spécifications) à la fin de ses travaux uniquement si les conditions suivantes sont remplies:
- Le code de sortie du conteneur signale une erreur et
OnFailure politique de redémarrage OnFailure est Always ou OnFailure .
Politique de redémarrage pour le conteneur principalLe conteneur principal ne sera redémarré (c'est-à-dire implique le lancement d'un nouveau conteneur avec la même spécification) à la fin de ses travaux que si les conditions suivantes sont remplies:
- stratégie de redémarrage définie comme
Always ou - La stratégie de redémarrage est définie comme
OnFailure et le code de sortie du conteneur signale une erreur.
Diagramme 8. Exemple de chronologie avec un point rouge, symbolisant une défaillance du conteneurL'illustration montre une chronologie de lancement de pod possible avec deux spécifications pour les conteneurs init et deux spécifications pour les conteneurs principaux. Il montre également la création (conformément à la politique de redémarrage) du nouveau
conteneur Main Container 1.2 après un problème avec le lancement de
Main Container 1.1 .
Phases de pod
Diagramme 9. Interaction de Kubelet avec l'objet pod et le runtime du conteneur (runtime du conteneur)Kubelet reçoit les spécifications de pod pour
.Spec.InitContainers et
.Spec.Containers , lance l'ensemble de conteneurs spécifié et met à jour les valeurs de
.Status.InitContainerStatuses pour
.Status.InitContainerStatuses et
.Status.ContainerStatuses .
Kubelet réduit les
.Status.InitContainerStatuses et
.Status.ContainerStatuses en une seule valeur -
.Status.Phase .
La phase pod est une projection de l'état des conteneurs à partir d'un ensemble de conteneurs, elle dépend de:
- états et codes de sortie des conteneurs init,
- états et codes de sortie des conteneurs principaux.
Schéma 10. Phases de la gousseEn attente
Phase en attenteUn pod est en attente si et seulement si:
- aucun des conteneurs d'initialisation de pod n'est à l'état
Terminated avec une erreur ( Failure ); - tous les principaux conteneurs à dosettes sont en
Waiting .
Courir
Phase d'exécutionPod est en phase de travail si et seulement si:
- tous les conteneurs pod init sont à l'état
Terminated avec succès; - au moins un conteneur de pod principal est en état de fonctionnement;
- aucun des conteneurs de pod principaux n'est à l'état
Terminated avec un Failure .
Succès
Phase de réussitePod est en phase de réussite si et seulement si:
- tous les conteneurs pod init sont à l'état
Terminated avec succès; - tous les principaux conteneurs à dosettes sont à l'état
Terminated avec succès.
Échec
Phase d'échecUn pod est en phase d'échec si et seulement si:
- tous les conteneurs à dosettes sont à l'état
Terminated ; - au moins l'un des conteneurs de pod est à l'état
Terminated avec une erreur ( Failure ).
Inconnu
En plus des phases décrites ci-dessus, la nacelle peut être dans une phase inconnue, ce qui indique l'impossibilité de déterminer sa phase actuelle.
Collecte des ordures pour les pods
Schéma 11. Cycle de contrôle du ramasse-miettesUne fois le pod planifié et lancé, un contrôleur spécial dans Kubernetes - le
Pod Garbage Collector Controller - est responsable de la suppression des objets pod du
magasin d'objets Kubernetes .
Conclusion
Pod est le bloc de construction de base de Kubernetes: pod est défini comme la représentation d'une demande de lancement d'un ou plusieurs conteneurs sur un seul nœud. Une fois le pod créé, Kubernetes le traite en deux étapes: tout d'abord, le
planificateur planifie le pod, puis Kubelet le lance. Tout au long de son cycle de vie, le pod passe par différentes phases, signalant l'état - ou, plus précisément, l'état de son ensemble de conteneurs - à l'utilisateur et au système.
PS du traducteur
Lisez aussi dans notre blog: