Fonctionnement de Kubernetes
Une installation Kubernetes correctement configurée dépend de la compréhension solide de l’architecture du système Kubernetes. Vous examinez ici tous les composants qui constituent une installation Kubernetes.
Qu’est-ce qu’un cluster d’ordinateurs ?
Un cluster est un ensemble d’ordinateurs que vous configurez pour qu’ils fonctionnent ensemble et qu’ils soient vus comme un seul système. Les ordinateurs configurés dans le cluster gèrent les mêmes types de tâches. Par exemple, ils vont tous héberger des sites web ou des API, ou exécuter un travail gourmand en calcul.
Un cluster utilise un logiciel centralisé responsable de la planification et du contrôle de ces tâches. Les ordinateurs d’un cluster qui exécutent les tâches sont appelés nœuds, tandis que les ordinateurs qui exécutent le logiciel de planification sont appelés plans de contrôle.
Architecture de Kubernetes
Rappelez-vous qu’un orchestrateur est un système qui déploie et gère des applications. Vous avez également découvert qu’un cluster est un ensemble d’ordinateurs qui fonctionnent ensemble et qui sont considérés comme un seul système. Vous utilisez Kubernetes comme logiciel d’orchestration et de cluster pour déployer vos applications et répondre aux modifications des besoins en ressources informatiques.
Un cluster Kubernetes contient au moins un plan principal et un ou plusieurs nœuds. Les plans de contrôle et les instances de nœud peuvent être des appareils physiques, des machines virtuelles ou des instances dans le cloud. Le système d’exploitation hôte par défaut dans Kubernetes est Linux, avec une prise en charge par défaut pour les charges de travail Linux.
Il est également possible d’exécuter des charges de travail Microsoft en utilisant Windows Server 2019 ou une version ultérieure sur des nœuds de cluster. Par exemple, supposons que le service de traitement des données dans l’application de suivi de drones soit écrit sous la forme d’une application .NET 4.5 qui utilise des appels d’API spécifiques du système d’exploitation Windows. Ce service ne peut s’exécuter que sur des nœuds qui exécutent un système d’exploitation Windows Server.
À présent, regardons plus en détail les plans de contrôle et les nœuds Worker, ainsi que le logiciel qui s’exécute sur chacun d’entre eux. Comprendre le rôle de chaque composant et où chaque composant s’exécute dans un cluster est utile lors de l’installation de Kubernetes.
Plan de contrôle Kubernetes
Le plan de contrôle Kubernetes dans un cluster Kubernetes exécute une collection de services qui gère la fonctionnalité d’orchestration dans Kubernetes.
Dans le cadre d’un apprentissage, l’utilisation d’un seul plan de contrôle dans votre environnement de test est pratique dès lors que le but est d’explorer la fonctionnalité Kubernetes. Cependant, dans la production et les déploiements dans le cloud comme Azure Kubernetes Service (AKS), vous constaterez que la configuration préférée est un déploiement à haute disponibilité avec trois à cinq plans de contrôle répliqués.
Remarque
Le fait qu’un plan de contrôle exécute un logiciel spécifique pour gérer l’état du cluster ne l’empêche pas d’exécuter d’autres charges de travail de calcul. Néanmoins, il est généralement souhaitable de l’exclure des charges de travail non critiques et d’applications utilisateur.
Nœud Kubernetes
Un nœud dans un cluster Kubernetes est l’endroit où vos charges de travail de calcul s’exécutent. Chaque nœud communique avec le plan de contrôle via le serveur API pour l’informer des changements d’état sur le nœud.
Services s’exécutant sur un plan de contrôle
Kubernetes s’appuie sur plusieurs services d’administration exécutés sur le plan de contrôle. Ces services gèrent des aspects comme la communication des composants de cluster, la planification des charges de travail et la persistance de l’état des clusters.
Les services suivants composent le plan de contrôle d’un cluster Kubernetes :
- Serveur d’API
- Magasin de stockage
- Planificateur
- Gestionnaire de contrôleurs
- Gestionnaire de contrôleurs cloud
Qu’est-ce qu’un serveur d’API ?
Vous pouvez vous représenter le serveur d’API comme front-end du plan de contrôle dans votre cluster Kubernetes. Toutes les communications entre les composants de Kubernetes passent par cette API.
Par exemple, en tant qu’utilisateur, vous utilisez une application de ligne de commande appelée kubectl qui vous permet d’exécuter des commandes sur le serveur d’API de votre cluster Kubernetes. Le composant qui fournit cette API est appelé le kube-apiserver : vous pouvez déployer plusieurs instances de ce composant pour prendre en charge la mise à l’échelle dans votre cluster.
Cette API expose une API RESTful que vous pouvez utiliser pour envoyer des commandes ou des fichiers de configuration basés sur YAML. YAML est un standard de sérialisation des données lisible par l’homme pour les langages de programmation. Vous utilisez des fichiers YAML pour définir l’état prévu de tous les objets dans un cluster Kubernetes.
Supposons par exemple que vous voulez augmenter le nombre d’instances de votre application dans le cluster. Vous définissez le nouvel état à l'aide d'un fichier basé YAML et soumettez ce fichier au serveur API. Le serveur API valide la configuration, l'enregistre dans le cluster et applique enfin l'augmentation configurée dans les déploiements d'applications.
Qu’est-ce que le magasin de stockage ?
Le magasin de stockage est un stockage persistant dans lequel votre cluster Kubernetes enregistre sa configuration complète. Kubernetes utilise un magasin de clés-valeurs fiable distribué à haute disponibilité, appelé etcd. Ce magasin clés-valeurs stocke l’état actuel et l’état souhaité de tous les objets au sein de votre cluster.
Dans un cluster Kubernetes de production, les instructions officielles de Kubernetes préconisent d’avoir de trois à cinq instances répliquées de la base de données etcd pour assurer une haute disponibilité.
Notes
etcd n’est pas responsable de la sauvegarde de données. Il est de votre responsabilité de garantir qu’un plan de sauvegarde effectif est en place pour sauvegarder les données de etcd.
Qu’est-ce que le planificateur ?
Le planificateur est le composant responsable de l’affectation des charges de travail sur tous les nœuds. Le planificateur surveille la présence des conteneurs nouvellement créés dans le cluster et les affecte à des nœuds.
Qu’est-ce que le gestionnaire de contrôleurs ?
Le gestionnaire de contrôleurs lance et supervise les contrôleurs configurés pour un cluster via le serveur d’API.
Kubernetes utilise des contrôleurs pour suivre les états d’objets dans le cluster. Chaque contrôleur s’exécute dans une boucle sans fin pour surveiller et répondre aux événements du cluster. Par exemple, il existe des contrôleurs pour surveiller les nœuds, les conteneurs et les points de terminaison.
Le contrôleur communique avec le serveur d’API pour déterminer l’état de l’objet. Si l'état actuel est différent de l'état souhaité de l'objet, le contrôleur prend des mesures pour garantir l'état souhaité.
Supposez que l’un des trois conteneurs en cours d’exécution dans votre cluster cesse de répondre et subisse une défaillance. Dans ce cas, un contrôleur décide si vous devez lancer de nouveaux conteneurs pour garantir que vos applications sont toujours disponibles. Si l’état souhaité est d’exécuter trois conteneurs à tout moment, l’exécution d’un nouveau conteneur est alors planifiée.
Qu’est-ce que le gestionnaire de contrôleurs cloud ?
Le gestionnaire de contrôleurs cloud s’intègre aux technologies cloud sous-jacentes dans votre cluster quand celui-ci s’exécute dans un environnement cloud. Ces services peuvent être des équilibreurs de charge, des files d’attente et du stockage.
Services s’exécutant sur un nœud
Plusieurs services s’exécutent sur un nœud Kubernetes pour contrôler le mode d’exécution des charges de travail.
Les services suivants s’exécutent sur le nœud Kubernetes :
- Kubelet
- Kube-proxy
- Runtime de conteneur
Qu’est-ce que le kubelet ?
Le kubelet est l’agent qui s’exécute sur chaque nœud du cluster et surveille les demandes de travail provenant du serveur d’API. Il garantit que l’unité de travail demandée est en cours d’exécution et qu’elle est saine.
Le kubelet surveille les nœuds et garantit que les conteneurs planifiés sur chaque nœud s’exécutent comme prévu. Le kubelet gère seulement les conteneurs créés par Kubernetes. Il n’est pas responsable de la replanification du travail à exécuter sur d’autres nœuds si le nœud actuel ne peut pas exécuter le travail.
Qu’est-ce que kube-proxy ?
Le composant kube-proxy est responsable du réseau du cluster local et s’exécute sur chaque nœud. Il s’assure que chaque nœud a une adresse IP unique. Il implémente aussi des règles pour gérer le routage et l’équilibrage de charge du trafic avec iptables et IPVS.
Ce proxy ne fournit pas de services DNS par lui-même. Une extension de cluster DNS basé sur CoreDNS est recommandé et installé par défaut.
Qu’est-ce que le runtime de conteneur ?
Le runtime de conteneur est le logiciel sous-jacent qui exécute des conteneurs sur un cluster Kubernetes. Le runtime est chargé de l’extraction, du démarrage et de l’arrêt des images conteneurs. Kubernetes prend en charge plusieurs runtimes de conteneur, notamment mais sans s’y limiter, Docker, containerd, rkt, CRI-O et frakti. La prise en charge de nombreux types de runtime de conteneur est basé sur l’interface CRI (Container Runtime Interface). Le CRI est une conception de plug-in qui permet au kubelet de communiquer avec le runtime de conteneur disponible.
Le runtime de conteneur par défaut dans AKS est containerd, un runtime de conteneur standard pour l’industrie.
Interagir avec un cluster Kubernetes
Kubernetes fournit un outil en ligne de commande appelé kubectl pour gérer votre cluster. Utilisez kubectl pour envoyer des commandes au plan de contrôle du cluster ou pour extraire des informations sur tous les objets Kubernetes via le serveur d’API.
kubectl utilise un fichier de configuration qui comprend des informations de configuration suivantes :
- La configuration Cluster spécifie un nom de cluster, des informations de certificat et le point de terminaison de l’API de service associé au cluster. Cette définition vous permet de vous connecter à plusieurs clusters à partir d’une seule station de travail.
- La configuration Utilisateur spécifie les utilisateurs et leurs niveaux d’autorisations lors de l’accès aux clusters configurés.
- La configuration Contexte regroupe des clusters et des utilisateurs en utilisant un nom convivial. Par exemple, vous pouvez avoir un « cluster de dév. » et un « cluster de prod. » pour identifier vos clusters de développement et de production.
Vous pouvez configurer kubectl pour vous connecter à plusieurs clusters en fournissant le contexte approprié dans le cadre de la syntaxe de la ligne de commande.
Pods Kubernetes
Un pod représente une seule instance d’une application exécutée dans Kubernetes. Les charges de travail que vous exécutez sur Kubernetes sont des applications conteneurisées. Contrairement à un environnement Docker, vous ne pouvez pas exécuter de conteneurs directement sur Kubernetes. Vous empaquetez le conteneur dans un objet Kubernetes appelé pod. Un pod est le plus petit objet que vous pouvez créer dans Kubernetes.
Un même pod peut regrouper un ou plusieurs conteneurs. Cependant, un pod ne contient généralement pas de copies multiples de la même application.
Un pod contient des informations sur la configuration du stockage partagé et du réseau, ainsi qu’une spécification sur la façon d’exécuter ses conteneurs packagés. Vous utilisez des modèles de pod pour définir les informations sur les pods qui s’exécutent dans votre cluster. Les modèles de pod sont des fichiers codés en YAML que vous réutilisez et que vous incluez dans d’autres objets pour gérer les déploiements de pods.
Imaginons par exemple que vous voulez déployer un site web sur un cluster Kubernetes. Vous créez le fichier de définition de pod qui spécifie la configuration et les images conteneur de l’application. Vous déployez ensuite le fichier de définition de pod sur Kubernetes.
Il est peu probable qu’une application web ait un site web comme unique composant de la solution. Une application web a généralement un type de magasin de données et d’autres éléments de prise en charge. Les pods Kubernetes peuvent également contenir plusieurs conteneurs.
Supposons que votre site utilise une base de données. Le site web est empaqueté dans le conteneur principal et la base de données est empaquetée dans le conteneur de prise en charge. Plusieurs conteneurs communiquent entre eux par le biais d'un environnement. Les conteneurs comprennent des services pour un système d'exploitation hôte, une pile réseau, un espace de noms du noyau, une mémoire partagée et un volume de stockage. Le pod est l’environnement de bac à sable (sandbox) qui fournit tous ces services à votre application. Le pod permet également aux conteneurs de partager l’adresse IP qui lui est affectée.
Comme vous pouvez potentiellement créer de nombreux pods s’exécutant sur de nombreux nœuds, il peut être difficile de les identifier. Vous pouvez reconnaître et grouper les pods en utilisant des étiquettes de chaîne que vous spécifiez quand vous définissez un pod.
Cycle de vie d’un pod Kubernetes
Les pods Kubernetes ont un cycle de vie distinct qui a un impact sur la façon dont vous déployez, exécutez et mettez à jour les pods. Vous commencez par envoyer le manifeste YAML du pod au cluster. Une fois le fichier manifeste et stocké dans le cluster, il définit l’état souhaité du pod. Le planificateur planifie le pod sur un nœud sain avec suffisamment de ressources pour exécuter le pod.
Voici les phases du cycle de vie d’un pod :
| Phase | Description |
|---|---|
| Pending | Le pod accepte le cluster, mais les conteneurs du cluster ne sont pas tous configurés ou prêts à s’exécuter. L'état En attente indique le temps d'attente d'un pod pour être programmé et le temps passé à télécharger les images des conteneurs. |
| En cours d’exécution | Le pod passe à l’état En cours d’exécution une fois que toutes les ressources du pod sont prêtes. |
| Réussite | Le pod passe à l’état Réussite une fois qu’il a terminé sa tâche prévue et qu’il a été exécuté avec succès. |
| Échec | Les pods peuvent échouer pour différentes raisons. Un conteneur dans le pod peut échouer, entraînant l’arrêt de tous les autres conteneurs. Il se peut également qu’une image n’ait pas été trouvée pendant la préparation des conteneurs de pod. Dans ces types de cas, le pod peut passer à un état d’Échec. Les pods peuvent transitionner à un état d’Échec à partir d’un état En attente ou d’un état En cours d’exécution. Une défaillance spécifique peut également remettre un pod dans l’état En attente. |
| Inconnu | Si l’état du pod ne peut pas être déterminé, le pod est à l’état Inconnu. |
Les pods sont conservés sur un cluster jusqu’à ce qu’un contrôleur, le plan de contrôle ou un utilisateur les supprime explicitement. Lorsqu'un pod est supprimé, un nouveau pod est créé immédiatement après. Le nouveau pod est considéré comme une instance entièrement nouvelle basée sur le manifeste du pod n'est pas une copie exacte, il diffère donc du pod supprimé.
Le cluster n’enregistre pas l’état du pod ou la configuration affectée dynamiquement. Par exemple, il n’enregistre pas l’ID ou l’adresse IP du pod. Cet aspect affecte la façon dont vous déployez les pods et la façon dont vous concevez vos applications. Par exemple, vous ne pouvez pas vous appuyer sur des adresses IP préaffectées pour vos pods.
États des conteneurs
Gardez à l’esprit que les phases sont un résumé de la position du pod dans son cycle de vie. Quand vous inspectez un pod, le cluster utilise trois états pour suivre vos conteneurs à l’intérieur du pod :
| State | Description |
|---|---|
| En attente | État par défaut d’un conteneur et état du conteneur quand il n’est pas en cours d’exécution ou arrêté. |
| En cours d’exécution | Le conteneur s’exécute comme prévu sans aucun problème. |
| Terminé | Le conteneur n’est plus en cours d’exécution. La raison en est que toutes les tâches sont terminées ou que le conteneur a échoué pour une raison quelconque. Une raison et un code de sortie sont disponibles lors du débogage des deux cas. |