Mis à jours 6 septembre 2022
Les objets Kubernetes et les charges de travail
Alors que les conteneurs sont le mécanisme sous-jacent utilisé pour déployer des applications, Kubernetes utilise des couches d’abstraction supplémentaires sur l’interface du conteneur pour fournir des fonctionnalités de mise à l’échelle, de résilience et de gestion du cycle de vie. Au lieu de gérer directement les conteneurs, les utilisateurs définissent et interagissent avec des instances composées de diverses primitives fournies par le modèle d’objet Kubernetes. Nous passerons en revue les différents types d’objets pouvant être utilisés pour définir ces charges de travail ci-dessous.
Pods
Un pod est l’unité la plus élémentaire avec laquelle Kubernetes traite. Les conteneurs eux-mêmes ne sont pas affectés aux hôtes. Au lieu de cela, un ou plusieurs conteneurs étroitement couplés sont encapsulés dans un objet appelé un pod.
Un pod représente généralement un ou plusieurs conteneurs qui devraient être contrôlés comme une seule application. Les pods sont constitués de conteneurs qui fonctionnent étroitement ensemble, partagent un cycle de vie et doivent toujours être planifiés sur le même nœud. Ils sont entièrement gérés en tant qu’unité et partagent leur environnement, leurs volumes et leur espace IP. En dépit de leur implémentation conteneurisée, vous devriez généralement considérer les pods comme une application monolithique unique pour mieux conceptualiser la manière dont le cluster gérera les ressources et la planification de pod.
Habituellement, les pods sont constitués d’un conteneur principal qui satisfait l’objectif général de la charge de travail et, éventuellement, de certains conteneurs auxiliaires qui facilitent les tâches étroitement liées. Ce sont des programmes qui bénéficient d’être exécutés et gérés dans leurs propres conteneurs, mais sont étroitement liés à l’application principale. Par exemple, un pod peut avoir un conteneur exécutant le serveur d’applications principal et un conteneur d’assistance qui transfère des fichiers vers le système de fichiers partagé lorsque des modifications sont détectées dans un référentiel externe. La mise à l’échelle horizontale est généralement déconseillée au niveau de pod, car il existe d’autres objets de niveau supérieur plus adaptés à la tâche.
Généralement, les utilisateurs ne doivent pas gérer les pods eux-mêmes, car ils ne fournissent pas certaines des fonctionnalités généralement requises dans les applications (comme la gestion et la mise à l’échelle sophistiquées du cycle de vie). Au lieu de cela, les utilisateurs sont encouragés à utiliser des objets de niveau supérieur qui utilisent des pods ou des modèles de pod en tant que composants de base, mais qui implémentent des fonctionnalités supplémentaires.
Les contrôleurs de réplication et les ensembles de réplication
Souvent, lorsque vous travaillez avec Kubernetes, plutôt que de travailler avec des pods individuels, vous gérez plutôt des groupes de pods identiques et répliqués. Ils sont créés à partir de modèles de pod et peuvent être mis à l’échelle horizontalement par des contrôleurs connus sous le nom de contrôleurs de réplication et d’ensembles de réplication.
Un contrôleur de réplication est un objet qui définit un modèle de pod et des paramètres de contrôle pour mettre à l’échelle horizontalement les répliques identiques d’un pod en augmentant ou en diminuant le nombre de copies en cours d’exécution. C’est un moyen facile de distribuer la charge et d’augmenter la disponibilité de manière native au sein de Kubernetes. Le contrôleur de réplication sait comment créer de nouveaux pods si nécessaire, car un gabarit ressemblant étroitement à une définition de pod est intégré dans la configuration du contrôleur de réplication.
Le contrôleur de réplication est chargé de s’assurer que le nombre de pods déployés dans le cluster correspond au nombre de pods dans sa configuration. Si un pod ou un hôte sous-jacent tombe en panne, le contrôleur démarrera de nouveaux pods pour compenser. Si le nombre de réplicas dans la configuration d’un contrôleur change, le contrôleur démarre ou élimine les conteneurs pour qu’ils correspondent au nombre souhaité. Les contrôleurs de réplication peuvent également effectuer des mises à jour tournantes pour faire passer un ensemble de pods vers une nouvelle version une par une, en minimisant l’impact sur la disponibilité des applications.
Les ensembles de réplication sont une itération sur la conception du contrôleur de réplication avec une plus grande flexibilité dans la façon dont le contrôleur identifie les pods qu’il est censé gérer. Les ensembles de réplication commencent à remplacer les contrôleurs de réplication en raison de leurs capacités de sélection de réplique supérieures, mais ils ne sont pas en mesure de faire des mises à jour tournantes pour exécuter des backends vers une nouvelle version comme les contrôleurs de réplication. Au lieu de cela, les ensembles de réplication sont destinés à être utilisés à l’intérieur d’unités supplémentaires de niveau supérieur qui fournissent cette fonctionnalité.
Comme les pods, les contrôleurs de réplication et les ensembles de réplication sont rarement les unités avec lesquelles vous travaillerez directement. Bien qu’ils s’appuient sur la conception de pod pour ajouter des garanties de mise à l’échelle horizontale et de fiabilité, ils ne disposent pas des capacités de gestion du cycle de vie à grain fin que l’on trouve dans des objets plus complexes.
Les déploiements
Les déploiements sont l’une des charges de travail les plus courantes à créer et à gérer directement. Les déploiements utilisent des ensembles de réplication en tant que bloc de construction, ajoutant une fonctionnalité de gestion du cycle de vie flexible au mélange.
Alors que les déploiements construits avec des ensembles de réplications peuvent sembler dupliquer la fonctionnalité offerte par les contrôleurs de réplication, les déploiements résolvent un grand nombre de problèmes qui existaient dans l’implémentation des rolling updates. Lors de la mise à jour d’applications avec des contrôleurs de réplication, les utilisateurs doivent soumettre un plan pour un nouveau contrôleur de réplication qui remplacerait le contrôleur actuel. Lors de l’utilisation de contrôleurs de réplication, des tâches telles que le suivi de l’historique, la récupération suite à des défaillances réseau pendant la mise à jour et l’annulation des mauvaises modifications sont soit difficiles soit laissés à la charge de l’utilisateur.
Les déploiements sont un objet de haut niveau conçu pour faciliter la gestion du cycle de vie des pods répliqués. Les déploiements peuvent être facilement modifiés en changeant la configuration et Kubernetes ajustera les ensembles de réplicas, gérera les transitions entre les différentes versions d’application, et gardera facultativement l’historique des événements et les capacités d’annulation de façon automatique. En raison de ces fonctionnalités, les déploiements seront probablement le type d’objet Kubernetes avec lequel vous travaillez le plus fréquemment.
Les ensembles à états
Les ensembles à états sont des contrôleurs de pod spécialisés qui offrent des garanties de commande et d’unicité. Principalement, ils sont utilisés pour avoir un contrôle plus précis lorsque vous avez des exigences particulières liées à l’ordre de déploiement, aux données persistantes ou au réseau stable. Par exemple, les ensembles à états sont souvent associés à des applications orientées données, comme les bases de données, qui doivent avoir accès aux mêmes volumes, même s’ils sont replanifiés vers un nouveau nœud.
Les ensembles à états fournissent un identifiant de réseau stable en créant un nom basé sur un nombre unique pour chaque pod qui persistera même si le pod doit être déplacé vers un autre nœud. De même, les volumes de stockage persistants peuvent être transférés avec un pod lorsque la replanification est nécessaire. Les volumes persistent même après la suppression du pod pour éviter toute perte accidentelle de données.
Lors du déploiement ou de l’ajustement de niveau, les ensembles à états effectuent des opérations en fonction de l’identifiant numéroté de leur nom. Cela donne plus de prévisibilité et de contrôle sur l’ordre d’exécution, ce qui peut être utile dans certains cas.
Les ensembles de démons
Les ensembles de démons sont une autre forme spécialisée de contrôleur de pod qui exécute une copie d’un pod sur chaque nœud du cluster (ou un sous-ensemble, si spécifié). Ceci est très souvent utile lors du déploiement de pods qui facilitent la maintenance et fournissent des services pour les nœuds eux-mêmes.
Par exemple, la collecte et la transmission de journaux, l’agrégation de métriques et l’exécution de services qui augmentent les capacités du nœud lui-même sont des candidats populaires pour les ensembles de démons. Comme les ensembles de démons fournissent souvent des services fondamentaux et sont nécessaires dans l’ensemble de la flotte, ils peuvent contourner les restrictions de planification des pods qui empêchent les autres contrôleurs d’assigner des pods à certains hébergeurs. Par exemple, en raison de ses responsabilités uniques, le serveur maître est fréquemment configuré pour être indisponible pour une planification de pod normale, mais les ensembles de démons peuvent remplacer la restriction pod par pod pour s’assurer que les services essentiels sont exécutés.
Jobs et Jobs cron
Les charges de travail que nous avons décrites jusqu’ici ont toutes supposé un cycle de vie de longue durée, semblable à celui d’un service. Kubernetes utilise une charge de travail appelée jobs pour fournir un flux de travail plus basé sur les tâches où les conteneurs en cours d’exécution devraient se terminer avec succès après un certain temps une fois leur travail terminé. Les jobs sont utiles si vous devez effectuer un traitement unique ou par lot au lieu d’exécuter un service continu.
Ce qu’on construit sur les jobs est des jobs cron. Comme les démons cron conventionnels sur les systèmes Linux et Unix qui exécutent des scripts sur une planification, les jobs cron dans Kubernetes fournissent une interface pour exécuter des jobs avec un composant de planification. Les jobs cron peuvent être utilisées pour programmer un travail à exécuter dans le futur ou sur une base régulière et récurrente. Les jobs cron de Kubernetes sont essentiellement une réimplémentation du comportement cron classique, en utilisant le cluster comme plate-forme au lieu d’un seul système d’exploitation.
Les autres composants de Kubernetes
Au-delà des charges de travail que vous pouvez exécuter sur un cluster, Kubernetes fournit un certain nombre d’autres abstractions qui vous aident à gérer vos applications, à contrôler le réseau et à activer la persistance. Nous allons discuter de quelques-uns des exemples les plus courants ici.
Les prestations de service
Jusqu’à présent, nous avons utilisé le terme « service » au sens conventionnel Unix : pour désigner les processus de longue durée, souvent connectés au réseau, capables de répondre aux demandes. Cependant, dans Kubernetes, un service est un composant qui agit comme un équilibreur de charge interne de base et un ambassadeur pour les pods. Un service regroupe des collections logiques de pods qui exécutent la même fonction pour les présenter en une seule entité.
Cela vous permet de déployer un service capable de suivre et de router vers tous les conteneurs backend d’un type particulier. Les consommateurs internes doivent uniquement connaître le point de terminaison stable fourni par le service. Pendant ce temps, l’abstraction du service vous permet d’étendre ou de remplacer les unités de travail backend si nécessaire. L’adresse IP d’un service reste stable indépendamment des modifications apportées aux pods vers lesquels il route. En déployant un service, vous gagnez facilement de la visibilité et pouvez simplifier la conception de vos conteneurs.
Chaque fois que vous devez fournir l’accès à un ou plusieurs pods à une autre application ou à des clients externes, vous devez configurer un service. Par exemple, si vous avez un ensemble de pods exécutant des serveurs Web qui devraient être accessibles depuis Internet, un service fournira l’abstraction nécessaire. De même, si vos serveurs Web doivent stocker et récupérer des données, vous devez configurer un service interne pour leur donner accès aux pods de base de données.
Bien que les services, par défaut, ne soient disponibles qu’à l’aide d’une adresse IP routable en interne, ils peuvent être mis à disposition en dehors du cluster en choisissant l’une des plusieurs stratégies. La configuration NodePort fonctionne en ouvrant un port statique sur l’interface réseau externe de chaque nœud. Le trafic vers le port externe sera routé automatiquement vers les pods appropriés à l’aide d’un service IP de cluster interne.
Autrement, le type de service LoadBalancer crée un équilibreur de charge externe à router vers le service à l’aide de l’intégration de l’équilibreur de charge Kubernetes d’un fournisseur cloud. Le gestionnaire de contrôleur de cloud crée la ressource appropriée et la configure en utilisant les adresses de service internes.
Les volumes et les volumes persistants
Le partage fiable des données et la garantie de leur disponibilité entre les redémarrages de conteneurs constituent un défi dans de nombreux environnements conteneurisés. Les temps d’exécution des conteneurs fournissent souvent un mécanisme pour attacher le stockage à un conteneur qui persiste au-delà de la durée de vie du conteneur, mais les implémentations manquent généralement de flexibilité.
Pour résoudre ce problème, Kubernetes utilise sa propre abstraction de volumes qui permet aux données d’être partagées par tous les conteneurs d’un pod et de rester disponibles jusqu’à ce que le pod soit terminé. Cela signifie que des pods étroitement couplés peuvent facilement partager des fichiers sans mécanismes externes complexes. Les échecs de conteneur dans le pod n’affecteront pas l’accès aux fichiers partagés. Une fois que le pod est terminé, le volume partagé est détruit, donc ce n’est pas une bonne solution pour les données réellement persistantes.
Les volumes persistants sont un mécanisme d’abstraction d’un stockage plus robuste qui n’est pas lié au cycle de vie du pod. Au lieu de cela, ils permettent aux administrateurs de configurer des ressources de stockage pour le cluster que les utilisateurs peuvent demander et revendiquer pour les pods qu’ils exécutent. Une fois qu’un pod est terminé avec un volume persistant, la stratégie de récupération du volume détermine si le volume est conservé jusqu’à ce qu’il soit supprimé manuellement ou immédiatement avec les données. Les données persistantes peuvent être utilisées pour se prémunir contre les défaillances basées sur les nœuds et pour allouer des quantités de stockage supérieures à celles disponibles localement.
Les étiquettes (labels) et les annotations
Une abstraction organisationnelle de Kubernetes liée, mais en dehors des autres concepts, est l’étiquetage. Une étiquette dans Kubernetes est une étiquette sémantique qui peut être attachée aux objets Kubernetes pour les marquer comme une partie d’un groupe. Ceux-ci peuvent ensuite être sélectionnés pour le ciblage de différentes instances pour la gestion ou le routage. Par exemple, chacun des objets basés sur le contrôleur utilise des étiquettes pour identifier les pods sur lesquels ils doivent fonctionner. Les services utilisent des étiquettes pour comprendre les pods backends auxquels ils doivent router les demandes.
Les étiquettes sont données comme de simples paires clé-valeur. Chaque unité peut avoir plus d’une étiquette, mais chaque unité ne peut avoir qu’une seule entrée pour chaque clé. Habituellement, une clé “nom” est utilisée comme identifiant général, mais vous pouvez également classer les objets selon d’autres critères tels que le stade de développement, l’accessibilité publique, la version de l’application, etc.
Les annotations sont un mécanisme similaire qui vous permet d’attacher des informations de valeur-clé arbitraires à un objet. Alors que les étiquettes doivent être utilisées pour les informations sémantiques utiles pour faire correspondre un pod avec des critères de sélection, les annotations sont plus libres et peuvent contenir des données moins structurées. En général, les annotations sont un moyen d’ajouter des métadonnées riches à un objet qui n’est pas utile à des fins de sélection.
Conclusion
Kubernetes est un projet passionnant qui permet aux utilisateurs d’exécuter des charges de travail conteneurisées évolutives et hautement disponibles sur une plate-forme hautement abstraite. Alors que l’architecture et l’ensemble des composants internes de Kubernetes peuvent à première vue sembler décourageants ; leur puissance, leur flexibilité et leur robustesse sont inégalées dans le monde open-source. En comprenant comment les blocs de construction de base s’assemblent, vous pouvez commencer à concevoir des systèmes qui tirent pleinement parti des capacités de la plate-forme pour exécuter et gérer vos charges de travail à grande échelle.
