Une introduction à Kubernetes

L'un des composants fondamentaux dont Kubernetes a besoin pour fonctionner est un magasin de configuration disponible globalement. Leetcd project, développé par l'équipe de CoreOS, est un magasin de clés-valeurs léger et distribué qui peut être configuré pour s'étendre sur plusieurs nœuds.

Kubernetes utiliseetcd pour stocker les données de configuration auxquelles chacun des nœuds 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 en fonction d'informations actualisées. Il aide également à maintenir l'état du cluster avec des fonctionnalités telles que l'élection du leader et le verrouillage distribué. En fournissant une simple API HTTP / JSON, l'interface permettant de définir ou de récupérer des valeurs est très simple.

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

L'un des services principaux les plus importants est un serveur API. Il s’agit du principal point de gestion de la grappe car il permet à un utilisateur de configurer les charges de travail et les unités organisationnelles de Kubernetes. Il est également chargé de s'assurer que le magasinetcd et les détails de service des conteneurs déployés sont en accord. Il sert de pont entre divers composants pour maintenir la santé des grappes 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 peuvent facilement communiquer avec elle. Un client appelékubectl est disponible comme méthode par défaut d'interaction avec le cluster Kubernetes à partir d'un ordinateur local.

Le responsable du traitement est un service général qui assume de nombreuses responsabilités. Il gère principalement 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 de routine. Par exemple, un contrôleur de réplication garantit que le nombre de répliques (copies identiques) défini pour un pod correspond au nombre actuellement déployé sur le cluster. Les détails de ces opérations sont écrits dansetcd, où le gestionnaire de contrôleur surveille les modifications via le serveur API.

Lorsqu'une modification est constatée, le contrôleur lit les nouvelles informations et met en œuvre la procédure qui remplit l'état souhaité. Cela peut impliquer de redimensionner une application, d'ajuster les points de terminaison, etc.

Le processus qui attribue les charges de travail à des nœuds spécifiques du cluster est le planificateur. Ce service lit les conditions d’exploitation d’une charge de travail, analyse l’environnement d’infrastructure actuel et place le travail sur un ou plusieurs 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.

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

Les gestionnaires de contrôleurs de nuage agissent comme le ciment qui permet à Kubernetes d’interagir avec des fournisseurs dotés de capacités, fonctionnalités et API différentes, tout en conservant en interne des constructions relativement génériques. Cela permet à Kubernetes de mettre à jour ses informations d'état en fonction des informations recueillies auprès du fournisseur de cloud, d'ajuster les ressources du cloud lorsque le système nécessite des modifications, et de créer et d'utiliser des services de cloud supplémentaires pour répondre aux exigences de travail soumises au cluster.

Le premier composant que chaque nœud doit avoir est un conteneur d'exécution. En règle générale, cette exigence est satisfaite en installant et en exécutantDocker, mais des alternatives telles querkt etrunc sont également disponibles.

L'exécution du conteneur 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 du cluster est, à son niveau de base, implémentée sous la forme d'un ou de plusieurs conteneurs à déployer. L'exécution du conteneur sur chaque nœud est le composant qui exécute enfin les conteneurs définis dans les charges de travail soumises au cluster.

Le point de contact principal pour chaque nœud avec le groupe de cluster est un petit service appelékubelet. Ce service est chargé de relayer les informations vers et depuis les services du plan de contrôle, ainsi que d'interagir avec le magasinetcd pour lire les détails de configuration ou écrire de nouvelles valeurs.

Le servicekubelet communique avec les composants maîtres pour s'authentifier auprès du cluster et recevoir des commandes et travailler. Le travail est reçu sous la forme d'unmanifest qui définit la charge de travail et les paramètres de fonctionnement. Le processuskubelet assume alors la responsabilité de maintenir l'état du travail sur le serveur de noeud. Il contrôle le temps d'exécution du conteneur pour lancer ou détruire les conteneurs si nécessaire.

Pour gérer le sous-réseau d'hôte individuel et rendre les services disponibles à 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 aux conteneurs appropriés, peut effectuer un équilibrage de charge primitif et est généralement chargé de s'assurer que l'environnement réseau est prévisible et accessible, mais isolé le cas échéant.

Unpod est l'unité la plus basique avec laquelle Kubernetes traite. Les conteneurs eux-mêmes ne sont pas attribués à des hôtes. Au lieu de cela, un ou plusieurs conteneurs étroitement couplés sont encapsulés dans un objet appelé pod.

Une nacelle représente généralement un ou plusieurs conteneurs devant ê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 comme une unité et partagent leur environnement, leurs volumes et leur espace IP. En dépit de leur implémentation conteneurisée, vous devez généralement considérer les pods comme une application monolithique unique pour mieux conceptualiser la façon dont le cluster gérera les ressources et la planification de ce dernier.

En règle générale, les modules consistent en un conteneur principal répondant à l'objectif général de la charge de travail et, éventuellement, en un conteneur auxiliaire facilitant 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 conteneur peut avoir un conteneur exécutant le serveur d'applications principal et un conteneur auxiliaire extrayant 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 du module car il existe d'autres objets de niveau supérieur plus adaptés à la tâche.

En règle générale, les utilisateurs ne doivent pas gérer les modules eux-mêmes, car ils ne fournissent pas certaines des fonctionnalités généralement nécessaires aux applications (telles que la gestion sophistiquée du cycle de vie et la mise à l'échelle). Les utilisateurs sont plutôt encouragés à travailler avec des objets de niveau supérieur qui utilisent des pods ou des modèles de pods en tant que composants de base, mais implémentent des fonctionnalités supplémentaires.

Souvent, lorsque vous travaillez avec Kubernetes, plutôt que de travailler avec des pods uniques, vous allez gérer 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 appelés contrôleurs de réplication et ensembles de réplication.

Unreplication controller est un objet qui définit un modèle de pod et contrôle des paramètres pour mettre à l'échelle des répliques identiques d'un pod horizontalement en augmentant ou en diminuant le nombre de copies en cours d'exécution. C'est un moyen simple de répartir la charge et d'augmenter la disponibilité de manière native dans Kubernetes. Le contrôleur de réplication sait comment créer de nouveaux pods en fonction des besoins, car un modèle ressemblant beaucoup à une définition de pod est incorporé 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 de sa configuration. Si un pod ou un hôte sous-jacent échoue, le contrôleur démarrera de nouveaux pods pour compenser. Si le nombre de répliques dans la configuration d’un contrôleur change, ce dernier démarre ou tue les conteneurs pour qu’ils correspondent au nombre souhaité. Les contrôleurs de réplication peuvent également effectuer des mises à jour progressives pour passer successivement un ensemble de modules à une nouvelle version, minimisant ainsi l'impact sur la disponibilité des applications.

LesReplication sets sont une itération de la conception du contrôleur de réplication avec une plus grande flexibilité dans la manière 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éplicas plus étendues, mais ils ne sont pas en mesure de faire des mises à jour progressives pour effectuer le cycle des retours vers une nouvelle version comme le peuvent les contrôleurs de réplication. Au lieu de cela, les ensembles de réplication sont conçus pour être utilisés à l'intérieur d'unités supplémentaires, de niveau supérieur, fournissant 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. S'ils s'appuient sur la conception de la nacelle pour offrir des garanties de fiabilité et de dimensionnement horizontaux et horizontaux, ils ne disposent pas des capacités de gestion du cycle de vie à granularité fine trouvées dans des objets plus complexes.

LesDeployments 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 comme un bloc de construction, ajoutant une fonctionnalité de gestion de cycle de vie flexible au mixage.

Bien que les déploiements construits avec des ensembles de réplication puissent sembler dupliquer les fonctionnalités offertes par les contrôleurs de réplication, les déploiements résolvent bon nombre des difficultés rencontrées lors de la mise en œuvre de mises à jour progressives. 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 l'historique de suivi, la résolution des défaillances du réseau lors de la mise à jour et l'annulation de modifications incorrectes sont difficiles ou laissées sous 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 modifiant la configuration. Kubernetes ajustera les jeux de réplicas, gérera les transitions entre les différentes versions de l'application et, facultativement, maintiendra automatiquement l'historique des événements et les fonctionnalités d'annulation. En raison de ces fonctionnalités, les déploiements seront probablement le type d'objet Kubernetes avec lequel vous travaillez le plus souvent.

LesStateful sets sont des contrôleurs de pod spécialisés qui offrent des garanties de commande et d'unicité. Celles-ci permettent généralement un contrôle plus fin lorsque vous avez des exigences particulières en matière de classement de déploiement, de données persistantes ou de mise en réseau stable. Par exemple, les ensembles avec état sont souvent associés à des applications orientées données, telles que des bases de données, qui doivent accéder aux mêmes volumes même si elles sont replanifiées sur un nouveau nœud.

Les ensembles avec état fournissent un identifiant de réseau stable en créant un nom unique, basé sur un nombre pour chaque pod, qui persistera même si le pod doit être déplacé vers un autre noeud. De même, les volumes de stockage persistants peuvent être transférés avec un pod lorsqu'une nouvelle planification est nécessaire. Les volumes persistent même après la suppression du pod afin d'éviter toute perte accidentelle de données.

Lors du déploiement ou du réglage de l'échelle, les ensembles avec état effectuent des opérations en fonction de l'identificateur numéroté dans 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.

Daemon sets est 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 le plus souvent utile lors du déploiement de pods permettant d'effectuer la maintenance et de fournir des services aux nœuds eux-mêmes.

Par exemple, la collecte et le transfert de journaux, l'agrégation de métriques et l'exécution de services augmentant 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 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 souvent configuré pour être indisponible pour la planification normale de pod, mais les ensembles de démons ont la possibilité de remplacer la restriction pod par pod pour s'assurer que les services essentiels sont en cours d'exécution.

Les charges de travail que nous avons décrites jusqu’à présent supposent toutes un cycle de vie long, semblable à celui des services. Kubernetes utilise une charge de travail appeléejobs pour fournir un flux de travail plus basé sur les tâches dans lequel les conteneurs en cours d'exécution sont censés se fermer avec succès après un certain temps une fois leur travail terminé. Les tâches sont utiles si vous devez exécuter un traitement ponctuel ou par lots au lieu d’exécuter un service continu.

Construire sur les emplois sontcron jobs. Comme les démons classiques decron sur les systèmes de type Linux et Unix qui exécutent des scripts selon une planification, 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écurrente. Les tâches cron de Kubernetes sont essentiellement une réimplémentation du comportement classique de cron, utilisant le cluster comme plate-forme au lieu d'un système d'exploitation unique.

Jusqu'à présent, nous utilisions le terme «service» au sens classique du terme Unix: pour désigner des processus de longue durée, souvent connectés à un réseau, capables de répondre aux demandes. Cependant, dans Kubernetes, unservice est un composant qui agit comme un équilibreur de charge interne de base et un ambassadeur pour les pods. Un service regroupe des ensembles logiques de modules remplissant la même fonction pour les présenter sous la forme d'une entité unique.

Cela vous permet de déployer un service capable de suivre et d’acheminer tous les conteneurs principaux d’un type donné. Les consommateurs internes doivent uniquement connaître le point de terminaison stable fourni par le service. Pendant ce temps, l’abstraction de service vous permet d’évoluer ou de remplacer les unités de travail d’arrière-plan si nécessaire. L’adresse IP d’un service reste stable quelles que soient les modifications apportées aux pods qu’il achemine. En déployant un service, vous devenez facilement découvrable et pouvez simplifier la conception de vos conteneurs.

Chaque fois que vous devez fournir l'accès à un ou plusieurs pods vers une autre application ou des consommateurs externes, vous devez 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 souhaitez 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 stratégies proposées. La configuration deNodePort fonctionne en ouvrant un port statique sur l’interface réseau externe de chaque nœud. Le trafic vers le port externe sera automatiquement acheminé vers les pods appropriés via un service IP de cluster interne.

Sinon, le type de serviceLoadBalancer crée un équilibreur de charge externe à acheminer vers le service à l'aide de l'intégration de l'équilibreur de charge Kubernetes d'un fournisseur de cloud. Le gestionnaire de contrôleur de cloud créera la ressource appropriée et la configurera à l'aide des adresses de service de service interne.

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 permettant d'associer un 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 abstractionvolumes 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 arrêté. Cela signifie que les 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 le pod terminé, le volume partagé est détruit. Ce n'est donc pas une bonne solution pour des données véritablement persistantes.

Persistent volumes sont un mécanisme pour extraire 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 les ressources de stockage pour le cluster que les utilisateurs peuvent demander et réclamer pour les pods qu'ils exécutent. Une fois qu'un pod est créé avec un volume persistant, la politique de récupération du volume détermine si le volume est conservé jusqu'à ce qu'il soit supprimé manuellement ou supprimé avec les données immédiatement. Les données persistantes peuvent être utilisées pour se prémunir contre les défaillances de nœud et pour allouer des quantités de stockage supérieures à celles disponibles localement.

Une abstraction organisationnelle de Kubernetes liée à, mais en dehors des autres concepts, est un étiquetage. Unlabel dans Kubernetes est une balise sémantique qui peut être attachée aux objets Kubernetes pour les marquer comme faisant partie d'un groupe. Celles-ci peuvent ensuite être sélectionnées pour cibler différentes instances à des fins de gestion ou de routage. Par exemple, chacun des objets basés sur le contrôleur utilise des étiquettes pour identifier les pods sur lesquels ils doivent opérer. Les services utilisent des étiquettes pour comprendre les modules dorsaux vers lesquels ils doivent router les demandes.

Les étiquettes sont données sous forme de simples paires clé-valeur. Chaque unité peut avoir plus d'une étiquette, mais chaque unité ne peut avoir qu'une entrée pour chaque touche. Habituellement, une clé «name» est utilisée comme identifiant général, mais vous pouvez également classer les objets selon d'autres critères tels que l'étape de développement, l'accessibilité publique, la version de l'application, etc.

Annotations est 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 conteneur à des critères de sélection, les annotations sont de forme plus libre 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 pour la sélection.