Qu’est-ce que Kubernetes ?

Introduction

Kubernetes est un système open source puissant, développé initialement par Google et soutenu par la Cloud Native Computing Foundation (CNCF), pour la gestion d’applications conteneurisées dans un environnement clusterisé. Son objectif est de fournir de meilleures façons de gérer les composants et services distribués associés sur une infrastructure variée. Pour en savoir plus sur Kubernetes, explorez le guide ci-dessous. Si vous recherchez un service d’hébergement Kubernetes géré, découvrez notre service Kubernetes géré et simple, conçu pour la croissance.

Dans ce guide, nous discuterons de ce qu’est Kubernetes, de certains concepts de base de Kubernetes. Nous parlerons de l’architecture du système, des problèmes qu’il résout et du modèle qu’il utilise pour gérer les déploiements et le dimensionnement des conteneurs.

Qu’est-ce que Kubernetes ?

Kubernetes, à son niveau de base, est un système permettant d’exécuter et de coordonner des applications conteneurisées sur un cluster de machines. Il s’agit d’une plateforme conçue pour gérer entièrement le cycle de vie des applications et services conteneurisés en utilisant des méthodes qui offrent la prévisibilité, la scalabilité et la haute disponibilité.

En tant qu’utilisateur de Kubernetes, vous pouvez définir comment vos applications doivent s’exécuter et les façons dont elles doivent pouvoir interagir avec d’autres applications ou le monde extérieur. Vous pouvez mettre à l’échelle vos services vers le haut ou vers le bas, effectuer des mises à jour progressives en douceur et basculer le trafic entre différentes versions de vos applications pour tester des fonctionnalités ou revenir en arrière sur des déploiements problématiques. Kubernetes fournit des interfaces et des primitives de plate-forme composable qui vous permettent de définir et de gérer vos applications avec un haut degré de flexibilité, de puissance et de fiabilité.

Architecture de Kubernetes

Pour comprendre comment Kubernetes est capable de fournir ces fonctionnalités, il est utile d’avoir une idée de sa conception et de son organisation à un niveau élevé. Kubernetes peut être visualisé comme un système construit en couches, chaque couche supérieure abstrayant la complexité trouvée dans les niveaux inférieurs.

À sa base, Kubernetes rassemble des machines physiques ou virtuelles individuelles dans un cluster à l’aide d’un réseau partagé pour communiquer entre chaque serveur, qu’il s’agisse à nouveau de machines physiques ou virtuelles. Ce cluster Kubernetes est la plate-forme physique où tous les composants, capacités et charges de travail Kubernetes sont configurés.

Les machines dans le cluster Kubernetes se voient attribuer un rôle au sein de l’écosystème Kubernetes. Un serveur (ou un petit groupe dans les déploiements hautement disponibles) agit en tant que serveur maître. Ce serveur fait office de passerelle et de cerveau pour le cluster en exposant une API Kubernetes pour les utilisateurs et les clients, en effectuant des vérifications de santé sur les autres serveurs, en décidant de la meilleure façon de répartir et d’assigner le travail (appelé « planification »), et en orchestrant la communication entre les autres composants (parfois appelée orchestration de conteneurs). Le serveur maître agit comme le principal point de contact avec le cluster et est responsable de la plupart de la logique centralisée que Kubernetes fournit.

Les autres machines du cluster sont désignées comme des nœuds : des serveurs responsables de l’acceptation et de l’exécution des charges de travail en utilisant des ressources locales et externes. Pour aider à l’isolation, à la gestion et à la flexibilité, Kubernetes exécute des applications et des services dans des conteneurs, donc chaque nœud doit être équipé d’un moteur d’exécution de conteneurs (comme Docker ou rkt). Le nœud reçoit des instructions de travail du serveur maître et crée ou détruit des conteneurs en conséquence, ajustant les règles de mise en réseau pour router et transférer le trafic de manière appropriée.

Comme mentionné ci-dessus, les applications et les services eux-mêmes s’exécutent sur le cluster au sein de conteneurs. Les composants sous-jacents veillent à ce que l’état désiré des applications corresponde à l’état réel du cluster. Les utilisateurs interagissent avec le cluster en communiquant avec le serveur API Kubernetes principal, soit directement, soit avec des clients et des bibliothèques. Pour démarrer une application ou un service, un plan déclaratif est soumis au format JSON ou YAML définissant ce qu’il faut créer et comment il doit être géré. Le serveur maître prend ensuite le plan et détermine comment l’exécuter sur l’infrastructure en examinant les besoins et l’état actuel du système. Ce groupe d’applications définies par l’utilisateur fonctionnant selon un plan spécifié représente la couche finale de Kubernetes.

Composants du serveur maître

Comme décrit ci-dessus, le serveur maître agit en tant que plan de contrôle principal pour les clusters Kubernetes. Il sert de point de contact principal pour les administrateurs et les utilisateurs, et fournit également de nombreux systèmes à l’échelle du cluster pour les nœuds de travail relativement peu sophistiqués. Dans l’ensemble, les composants sur le serveur maître travaillent ensemble pour accepter les demandes des utilisateurs, déterminer les meilleures façons de planifier les conteneurs de charge de travail, authentifier les clients et les nœuds, ajuster le réseau à l’échelle du cluster, et gérer les responsabilités de mise à l’échelle et de vérification de l’état de santé.

Ces composants peuvent être installés sur une seule machine ou répartis sur plusieurs serveurs. Nous examinerons chacun des composants individuels associés aux serveurs maîtres des clusters Kubernetes dans cette section.

etcd

Un des composants fondamentaux dont Kubernetes a besoin pour fonctionner est un magasin de configuration globalement disponible. Le projet etcd, développé par l’équipe de CoreOS (système d’exploitation), est un magasin de clés-valeurs léger et distribué qui peut être configuré pour s’étendre sur plusieurs nœuds.

Kubernetes utilise etcd pour stocker les données de configuration auxquelles chaque nœud du cluster peut accéder. Cela peut être utilisé pour la découverte de services et peut aider les composants à se configurer ou à se reconfigurer selon des informations à jour. Cela aide également à maintenir l’état du cluster avec des fonctionnalités telles que l’élection de leader et le verrouillage distribué. En fournissant une API HTTP/JSON simple, l’interface pour définir ou récupérer des valeurs est très directe.

Comme la plupart des autres composants du plan de contrôle, etcd peut être configuré sur un seul serveur maître ou, dans des scénarios de production, distribué entre plusieurs machines. La seule exigence est qu’il soit accessible via le réseau à chacune des machines Kubernetes.

kube-apiserver

L’un des services maîtres les plus importants est un serveur API. Il s’agit du point de gestion principal de l’ensemble du cluster car il permet à un utilisateur de configurer les charges de travail et les unités organisationnelles de Kubernetes. Il est également responsable de s’assurer que le magasin etcd et les détails du service des conteneurs déployés sont en accord. Il fait office de pont entre différents composants pour maintenir la santé du cluster et diffuser des informations et des commandes.

Le serveur API implémente une interface RESTful, ce qui signifie que de nombreux outils et bibliothèques différents peuvent communiquer facilement avec lui. Un client appelé kubectl est disponible comme méthode par défaut pour interagir avec le cluster Kubernetes à partir d’un ordinateur local.

kube-controller-manager

Le gestionnaire de contrôleur est un service général qui a de nombreuses responsabilités. Principalement, il gère différents contrôleurs qui régulent l’état du cluster, gèrent les cycles de vie des charges de travail et effectuent des tâches routinières. Par exemple, un contrôleur de réplication veille à ce que le nombre de répliques (copies identiques) défini pour un pod corresponde au nombre actuellement déployé sur le cluster. Les détails de ces opérations sont écrits dans etcd, où le gestionnaire de contrôleur surveille les changements via le serveur API.

Lorsqu’un changement est détecté, le contrôleur lit les nouvelles informations et met en œuvre la procédure qui répond à l’état désiré. Cela peut impliquer de mettre à l’échelle une application vers le haut ou vers le bas, d’ajuster les points de terminaison, etc.

kube-scheduler

Le processus qui attribue effectivement des charges de travail à des nœuds spécifiques dans le cluster est le planificateur. Ce service lit les exigences opérationnelles d’une charge de travail, analyse l’environnement d’infrastructure actuel et place le travail sur un nœud ou des nœuds acceptables.

Le planificateur est responsable du suivi de la capacité disponible sur chaque hôte pour s’assurer que les charges de travail ne sont pas planifiées au-delà des ressources disponibles. Le planificateur doit connaître la capacité totale ainsi que les ressources déjà allouées aux charges de travail existantes sur chaque serveur.

cloud-controller-manager

Kubernetes peut être déployé dans de nombreux environnements différents et peut interagir avec divers fournisseurs d’infrastructure pour comprendre et gérer l’état des ressources dans le cluster. Bien que Kubernetes fonctionne avec des représentations génériques de ressources comme le stockage attachable et les équilibreurs de charge, il a besoin d’un moyen de les mapper aux ressources réelles fournies par les fournisseurs de cloud non homogènes.

Les gestionnaires de contrôle de cloud agissent comme le lien qui permet à Kubernetes d’interagir avec des fournisseurs ayant différentes capacités, fonctionnalités et API tout en maintenant des structures relativement génériques en interne. Cela permet à Kubernetes de mettre à jour ses informations d’état selon les données recueillies auprès du fournisseur de cloud, d’ajuster les ressources cloud selon les besoins du système, et de créer et utiliser des services cloud supplémentaires pour satisfaire les exigences de travail soumises au cluster.

Composants serveur de nœud

Dans Kubernetes, les serveurs qui effectuent des travaux en exécutant des conteneurs sont appelés nœuds. Les serveurs de nœuds ont quelques exigences nécessaires pour communiquer avec les composants maîtres, configurer le réseau de conteneurs et exécuter les charges de travail effectives qui leur sont assignées.

A Container Runtime

Le premier composant que chaque nœud doit avoir est un moteur d’exécution de conteneur. Généralement, cette exigence est satisfaite en installant et en exécutant Docker, mais des alternatives comme rkt et runc sont également disponibles.

Le runtime de conteneurs est responsable du démarrage et de la gestion des conteneurs, des applications encapsulées dans un environnement d’exploitation relativement isolé mais léger. Chaque unité de travail sur le cluster est, à son niveau de base, implémentée comme un ou plusieurs conteneurs qui doivent être déployés. Le runtime de conteneurs sur chaque nœud est le composant qui exécute finalement les conteneurs définis dans les charges de travail soumises au cluster.

kubelet

Le principal point de contact de chaque nœud avec le groupe de cluster est un petit service appelé kubelet. Ce service est responsable de la transmission d’informations vers et depuis les services du plan de contrôle, ainsi que de l’interaction avec le magasin etcd pour lire les détails de configuration ou écrire de nouvelles valeurs.

Le service kubelet communique avec les composants maîtres pour s’authentifier auprès du cluster et recevoir des commandes et du travail. Le travail est reçu sous forme d’un manifeste qui définit la charge de travail et les paramètres d’exploitation. Le processus kubelet assume ensuite la responsabilité de maintenir l’état du travail sur le serveur du nœud. Il contrôle le runtime de conteneurs pour lancer ou détruire les conteneurs selon les besoins.

kube-proxy

Pour gérer le sous-réseau de chaque hôte individuel et rendre les services disponibles pour d’autres composants, un petit service proxy appelé kube-proxy est exécuté sur chaque serveur de nœud. Ce processus transfère les demandes vers les conteneurs appropriés, peut effectuer un équilibrage de charge primitif et est généralement responsable de garantir que l’environnement de mise en réseau est prévisible et accessible, mais isolé lorsque cela est approprié.

Objets et charges de travail Kubernetes

Alors que les conteneurs sont le mécanisme sous-jacent utilisé pour déployer des applications conteneurisées, Kubernetes utilise des couches d’abstraction supplémentaires sur l’interface des conteneurs 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

A pod is the most basic unit that Kubernetes deals with. Containers themselves are not assigned to hosts. Instead, one or more tightly coupled containers are encapsulated in an object called a pod.

A pod generally represents containers that should be controlled as a single application. Pods consist of containers that operate closely together, share a life cycle, and should always be scheduled on the same node. They are managed entirely as a unit and share their environment, volumes, and IP space. In spite of their containerized implementation, you should generally think of pods as a single, monolithic application to best conceptualize how the cluster will manage the pod’s resources and scheduling.

Généralement, les pods se composent d’un conteneur principal qui satisfait le but général de la charge de travail et éventuellement de quelques conteneurs auxiliaires qui facilitent des 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 qui sont étroitement liés à l’application principale. Par exemple, un pod peut avoir un conteneur exécutant le serveur d’application principal et un conteneur auxiliaire téléchargeant des fichiers vers le système de fichiers partagé lorsque des modifications sont détectées dans un référentiel externe. Le dimensionnement horizontal est généralement déconseillé au niveau du pod car il existe d’autres objets de niveau supérieur mieux adaptés à la tâche.

En général, les utilisateurs ne devraient pas gérer eux-mêmes les pods, car ils ne fournissent pas certaines des fonctionnalités généralement nécessaires dans les applications (comme une gestion sophistiquée du cycle de vie et du dimensionnement). Au lieu de cela, les utilisateurs sont encouragés à travailler avec des objets de niveau supérieur qui utilisent des pods ou des modèles de pod comme composants de base mais qui implémentent des fonctionnalités supplémentaires.

Contrôleurs de Réplication et Ensembles de Réplication

Souvent, lorsqu’on travaille avec Kubernetes, plutôt que de travailler avec des pods individuels, vous allez plutôt gérer des groupes de pods identiques et répliqués. Ceux-ci sont créés à partir de modèles de pod et peuvent être dimensionnés horizontalement par des contrôleurs appelés contrôleurs de réplication et ensembles de réplication.

A replication controller is an object that defines a pod template and control parameters to scale identical replicas of a pod horizontally by increasing or decreasing the number of running copies. This is an easy way to distribute load and increase availability natively within Kubernetes. The replication controller knows how to create new pods as needed because a template that closely resembles a pod definition is embedded within the replication controller configuration.

Le contrôleur de réplication est responsable 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 l’hôte sous-jacent échoue, 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 arrête les conteneurs pour correspondre au nombre désiré. Les contrôleurs de réplication peuvent également effectuer des mises à jour progressives pour faire passer un ensemble de pods à une nouvelle version un par un, minimisant l’impact sur la disponibilité de l’application.

Les ensembles de réplication sont une itération de 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éplica accrues, mais ils ne peuvent pas effectuer de mises à jour progressives pour faire passer les backends à une nouvelle version comme le peuvent 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é.

Tout 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 des pods pour ajouter une mise à l’échelle horizontale et des garanties de fiabilité, ils manquent certaines des capacités de gestion du cycle de vie à grain fin que l’on trouve dans des objets plus complexes.

Déploiements

Les déploiements sont l’un des types de charges de travail les plus courants à créer et à gérer directement. Les déploiements utilisent des ensembles de réplication comme bloc de construction, ajoutant des fonctionnalités de gestion de cycle de vie flexibles à l’ensemble.

Bien que les déploiements construits avec des ensembles de réplications puissent sembler dupliquer les fonctionnalités offertes par les contrôleurs de réplication, les déploiements résolvent de nombreux points douloureux qui existaient dans la mise en œuvre des mises à jour continues. Lors de la mise à jour des 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 après des échecs réseau pendant la mise à jour, et l’annulation de modifications problématiques sont soit difficiles, soit laissées à la responsabilité 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épliques, gérera les transitions entre différentes versions d’applications, et maintiendra facultativement l’historique des événements et les capacités d’annulation automatiquement. En raison de ces caractéristiques, les déploiements seront probablement le type d’objet Kubernetes avec lequel vous travaillerez le plus fréquemment.

Ensembles Stables

Les ensembles d’états sont des contrôleurs de pod spécialisés qui offrent des garanties d’ordonnancement et d’unicité. Principalement, ils sont utilisés pour avoir un contrôle plus précis lorsque vous avez des exigences spéciales liées à l’ordonnancement du déploiement, aux données persistantes ou au réseau stable. Par exemple, les ensembles d’états sont souvent associés à des applications orientées données, comme les bases de données, qui ont besoin d’accéder aux mêmes volumes même si elles sont réaffectées à un nouveau nœud.

Les ensembles d’états fournissent un identifiant de réseau stable en créant un nom unique basé sur un numéro 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 persistant peuvent être transférés avec un pod lorsque la réaffectation est nécessaire. Les volumes persistent même après que le pod a été supprimé pour éviter toute perte de données accidentelle.

Lors du déploiement ou de l’ajustement de l’échelle, les ensembles d’états effectuent des opérations en fonction de l’identifiant numéroté dans leur nom. Cela offre une plus grande prévisibilité et un meilleur contrôle sur l’ordre d’exécution, ce qui peut être utile dans certains cas.

Jeux de démons

Les jeux 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 sur un sous-ensemble, si spécifié). C’est le plus souvent utile lors du déploiement de pods qui aident à effectuer la maintenance et à fournir des services pour les nœuds Kubernetes 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. Parce que les ensembles de démons fournissent souvent des services fondamentaux et sont nécessaires dans toute la flotte, ils peuvent contourner les restrictions de planification des pods qui empêchent les autres contrôleurs d’attribuer des pods à certains hôtes. Par exemple, en raison de ses responsabilités uniques, le serveur maître est fréquemment configuré pour être indisponible pour la planification normale des pods, mais les ensembles de démons ont la capacité de contourner la restriction pod par pod pour s’assurer que les services essentiels fonctionnent.

Travaux et Travaux Cron

Les charges de travail que nous avons décrites jusqu’à présent ont toutes supposé un cycle de vie semblable à celui d’un service fonctionnant en continu. Kubernetes utilise une charge de travail appelée travaux pour fournir un flux de travail plus orienté tâches où les conteneurs en cours d’exécution sont censés se terminer avec succès après un certain temps une fois leur travail terminé. Les travaux sont utiles si vous devez effectuer un traitement ponctuel ou par lots au lieu d’exécuter un service continu.

La création d’emplois est basée sur des tâches cron. Comme les démons cron conventionnels sur les systèmes Linux et de type Unix qui exécutent des scripts selon un calendrier, les tâches cron dans Kubernetes fournissent une interface pour exécuter des tâches avec un composant de planification. Les tâches cron peuvent être utilisées pour planifier l’exécution d’une tâche à l’avenir ou de manière régulière et récurrente. Les tâches cron 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.

Autres composants 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 à permettre la persistance. Nous discuterons ici de quelques exemples plus courants.

Services Kubernetes

Jusqu’à présent, nous avons utilisé le terme « service » dans le sens conventionnel, de type Unix : pour désigner des processus s’exécutant en continu, souvent connectés en réseau, capables de répondre à des requêtes. 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 comme une seule entité.

Cela vous permet de déployer un service qui peut suivre et router vers tous les conteneurs backend d’un type particulier. Les consommateurs internes n’ont besoin de connaître que le point de terminaison stable fourni par le service. Pendant ce temps, l’abstraction du service vous permet de mettre à l’échelle ou de remplacer les unités de travail backend selon les besoins. L’adresse IP d’un service reste stable indépendamment des changements apportés aux pods qu’il route. En déployant un service, vous gagnez facilement en découvrabilité 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 consommateurs externes, vous devriez configurer un service. Par exemple, si vous avez un ensemble de pods exécutant des serveurs Web qui doivent ê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 voudriez configurer un service interne pour leur donner accès à vos pods de base de données.

Bien que les services, par défaut, ne soient disponibles qu’en utilisant une adresse IP routable en interne, ils peuvent être rendus disponibles 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 automatiquement routé vers les pods appropriés en utilisant un service IP de cluster interne.

Alternativement, le type de service LoadBalancer crée un équilibreur de charge externe pour router vers le service en utilisant l’intégration de l’équilibreur de charge Kubernetes du fournisseur de cloud. Le gestionnaire du contrôleur cloud créera la ressource appropriée et la configurera en utilisant les adresses de service interne du service.

Volumes et Volumes Persistants

Partager des données de manière fiable et garantir leur disponibilité entre les redémarrages de conteneurs est un défi dans de nombreux environnements conteneurisés. Les moteurs d’exécution de conteneurs fournissent souvent un mécanisme pour attacher du 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 remédier à cela, Kubernetes utilise sa propre abstraction de volumes qui permet de partager des données entre tous les conteneurs dans une capsule (pod) et de les rendre disponibles jusqu’à ce que la capsule soit terminée. Cela signifie que des capsules étroitement couplées peuvent facilement partager des fichiers sans mécanismes externes complexes. Les échecs de conteneurs à l’intérieur de la capsule n’affecteront pas l’accès aux fichiers partagés. Une fois la capsule terminée, le volume partagé est détruit, donc ce n’est pas une bonne solution pour des données vraiment persistantes.

Les volumes persistants sont un mécanisme permettant d’abstraire un stockage plus robuste qui n’est pas lié au cycle de vie de la capsule. Au lieu de cela, ils permettent aux administrateurs de configurer des ressources de stockage pour le cluster que les utilisateurs peuvent demander et réclamer pour les capsules qu’ils exécutent. Une fois qu’une capsule a terminé avec un volume persistant, la politique de récupération du volume détermine si le volume est conservé jusqu’à sa suppression manuelle ou supprimé avec les données immédiatement. Les données persistantes peuvent être utilisées pour se protéger contre les défaillances basées sur les nœuds et allouer des quantités de stockage plus importantes que celles disponibles localement.

Étiquettes et Annotations

A Kubernetes organizational abstraction related to, but outside of the other concepts, is labeling. A label in Kubernetes is a semantic tag that can be attached to Kubernetes objects to mark them as a part of a group. These can then be selected for when targeting different instances for management or routing. For instance, each of the controller-based objects use labels to identify the pods that they should operate on. Services use labels to understand the backend pods they should route requests to.

Les étiquettes sont données sous forme de paires clé-valeur simples. 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 à usage 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 clé-valeur arbitraires à un objet. Alors que les étiquettes doivent être utilisées pour des informations sémantiques utiles pour faire correspondre un pod à 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 ne sont pas utiles à 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. Bien que l’architecture de Kubernetes et son ensemble de composants internes puissent sembler intimidants au début, leur puissance, leur flexibilité et leur ensemble de fonctionnalités robustes sont inégalés dans le monde open source et pour le développement natif du cloud. En comprenant comment les blocs de construction de base s’emboîtent, vous pouvez commencer à concevoir des systèmes qui exploitent pleinement les capacités de la plate-forme pour exécuter et gérer vos charges de travail à grande échelle, en construisant d’incroyables applications cloud natives.