Kubernetes est un puissant système open source, initialement développé par Google, pour la gestion des applications conteneurisées dans un environnement en cluster. Il vise à fournir de meilleurs moyens de gérer les composants et les services connexes et distribués dans diverses infrastructures.
Dans ce guide, nous aborderons certains des 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 en conteneur et la mise à l’échelle.
Qu’est-ce que Kubernetes ?
Kubernetes, à son niveau de base, est un système pour exécuter et coordonner des applications conteneurisées à travers un groupe de machines. Il s’agit d’une plate-forme conçue pour gérer complètement le cycle de vie des applications et des services conteneurisés à l’aide de méthodes offrant prévisibilité, évolutivité et haute disponibilité.
En tant qu’utilisateur de Kubernetes, vous pouvez définir comment vos applications doivent s’exécuter et comment elles peuvent interagir avec d’autres applications ou avec le monde extérieur. Vous pouvez augmenter ou diminuer vos services, effectuer des mises à jour progressives et basculer le trafic entre différentes versions de vos applications pour tester des fonctionnalités ou restaurer 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 capacités, il est utile d’avoir une idée de la façon dont il est conçu et organisé à un niveau élevé. Les Kubernetes peuvent être visualisés comme un système construit en couches, chaque couche supérieure faisant abstraction de la complexité des niveaux inférieurs.
À sa base, Kubernetes rassemble des machines physiques ou virtuelles individuelles dans un cluster en utilisant un réseau partagé pour communiquer entre chaque serveur. Ce cluster est la plate-forme physique où tous les composants, capacités et charges de travail de Kubernetes sont configurés.
Les machines du cluster ont chacune un rôle dans l’écosystème Kubernetes. Un serveur (ou un petit groupe dans des déploiements hautement disponibles) fonctionne en tant que serveur maître. Ce serveur agit comme une passerelle et un cerveau pour le cluster en exposant une API pour les utilisateurs et les clients, en vérifiant l’état de santé des autres serveurs, en décidant comment répartir et assigner le travail (“planification”) et en orchestrant la communication entre les autres composants. Le serveur maître agit en tant que point de contact principal avec le cluster et est responsable de la majeure partie de la logique centralisée fournie par Kubernetes.
Les autres machines du cluster sont désignées en tant que nœuds : serveurs chargés d’accepter et d’exécuter des charges de travail à l’aide de ressources locales et externes. Pour aider à l’isolation, la gestion et la flexibilité, Kubernetes exécute des applications et des services dans des conteneurs, de sorte que chaque nœud doit être équipé d’un conteneur d’exécution (comme Docker ou rkt). Le nœud reçoit les instructions de travail du serveur maître et crée ou détruit les conteneurs en conséquence, en ajustant les règles de mise en réseau pour router et acheminer le trafic de manière appropriée.
Comme mentionné ci-dessus, les applications et les services eux-mêmes sont exécutés sur le cluster dans des conteneurs. Les composants sous-jacents s’assurent que l’état souhaité des applications correspond à l’état actuel du cluster. Les utilisateurs interagissent avec le cluster en communiquant avec le serveur API principal ou avec des clients et des bibliothèques. Pour démarrer une application ou un service, un plan déclaratif est soumis dans 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 exigences 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 directement de Kubernetes.
Composants du serveur maître
Comme nous l’avons 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 du serveur maître fonctionnent ensemble pour accepter les demandes des utilisateurs, déterminer les meilleurs moyens de planifier les conteneurs de workload, 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.
Ces composants peuvent être installés sur une seule machine ou répartis sur plusieurs serveurs. Nous allons examiner chacun des composants individuels associés aux serveurs maîtres dans cette section.
etcd
L’un des composants fondamentaux dont Kubernetes a besoin est un magasin de configuration disponible dans le monde entier. Le projet etcd, développé par l’équipe de CoreOS, est un magasin de clés-valeurs léger et distribué pouvant être configuré pour couvrir plusieurs nœuds.
Kubernetes utilise etcd 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 des informations mises à jour. Il permet également de maintenir l’état du cluster avec des fonctionnalités telles que l’élection du leader et le verrouillage distribué. En fournissant une API HTTP/JSON simple, l’interface de définition ou de récupération des valeurs est très simple.
Comme la plupart des autres composants dans le plan de contrôle, etcd peut être configuré sur un serveur maître unique ou, dans des scénarios de production, distribué sur un certain nombre de machines. La seule exigence est qu’il soit accessible par le réseau à partir de chaque machine Kubernetes.
kube-apiserver
L’un des services maîtres les plus importants est le serveur API. C’est le principal point de gestion de l’ensemble du cluster car il permet à l’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 de service des conteneurs déployés sont en accord. Il agit comme un pont entre les différentes composantes pour maintenir la santé du cluster et diffuser les informations et les commandes.
Le serveur API implémente une interface RESTful, ce qui signifie que de nombreux outils et bibliothèques différents peuvent facilement communiquer avec lui. Un client appelé kubectl est disponible en tant que méthode par défaut d’interaction avec le cluster Kubernetes à partir d’un ordinateur local.
kube-controller-manager
Le gestionnaire du 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 de la charge de travail et exécutent les tâches de routine. Par exemple, un contrôleur de réplication s’assure que le nombre de réplicas (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 dans etcd, où le gestionnaire du contrôleur surveille les modifications via le serveur API.
Lorsqu’une modification est constatée, le contrôleur lit les nouvelles informations et implémente la procédure qui satisfait à l’état souhaité. Cela peut impliquer une mise à l’échelle d’une application vers le haut ou vers le bas, l’ajustement de points de terminaison, etc.
kube-scheduler
Le processus qui affecte réellement les charges de travail à des nœuds spécifiques dans le cluster est le planificateur. Ce service lit les exigences opérationnelles d’un workload, 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.
cloud-controller-manager
Les Kubernetes peuvent être déployés dans de nombreux environnements différents et peuvent interagir avec divers fournisseurs d’infrastructure pour comprendre et gérer l’état des ressources dans le cluster. Tandis que Kubernetes fonctionne avec des représentations génériques de ressources telles que le stockage attachable et les équilibreurs de charge, il doit pouvoir les mapper aux ressources réelles fournies par les fournisseurs de cloud non homogènes.
Les gestionnaires de contrôleurs de cloud agissent en tant que lien permettant à Kubernetes d’interagir avec des fournisseurs avec différentes capacités, fonctionnalités et API tout en conservant des constructions relativement génériques en interne. Cela permet à Kubernetes de mettre à jour ses informations d’état en fonction des informations collectées auprès du fournisseur de cloud, d’ajuster les ressources cloud en fonction des 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 de serveur de nœud
Dans Kubernetes, les serveurs qui exécutent des tâches tout en exécutant des conteneurs sont appelés des nœuds. Les serveurs de nœuds ont quelques exigences qui sont nécessaires pour communiquer avec les composants maîtres, configurer la mise en réseau des conteneurs et exécuter les charges de travail réelles qui leur sont affectées.
Le runtime de conteneur
Le premier composant que chaque nœud doit avoir est un runtime de conteneur. En règle générale, cette condition est satisfaite en installant et en exécutant Docker, mais des alternatives telles que rkt et runc sont également disponibles.
Le runtime de 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 sur le cluster est, à son niveau de base, implémentée comme un ou plusieurs conteneurs devant être déployés. Le runtime de conteneur sur chaque nœud est le composant qui exécute finalement les conteneurs définis dans les workloads soumis au cluster.
Kubelet
Le point de contact principal de chaque nœud avec le groupe de cluster est un petit service appelé kubelet. Ce service est chargé de relayer les informations depuis et vers les services du plan de contrôle, ainsi que d’interagir avec le magasin etcd pour lire les détails de la 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 travailler. Le travail est reçu sous la forme d’un manifeste qui définit la charge de travail et les paramètres de fonctionnement. Le processus de kubelet assume alors la responsabilité de maintenir l’état du travail sur le serveur de nœud. Il contrôle le runtime de conteneur pour lancer ou détruire les conteneurs selon les besoins.
kube-proxy
Pour gérer les sous-réseaux hôtes individuels et rendre les services disponibles aux autres composants, un petit service proxy appelé Kube-proxy est exécuté sur chaque serveur de nœud. Ce processus transmet les demandes aux conteneurs appropriés, peut effectuer l’é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.
