Objets et architecture Kubernetes
Kubernetes définit un jeu d'outils ("primitives") qui, ensemble, fournissent des mécanismes pour déployer, maintenir et mettre à l’échelle des applications. Ces objets qui composent Kubernetes sont conçus pour être combinés et extensibles et donc permettre de supporter une grande variété de charge de travail. Cette extensibilité est fournie en grande partie par l'API de Kubernetes, qui est utilisée par les composants internes aussi bien que par les extensions et les conteneurs tournant sur Kubernetes. (Source).
Les objets de base de Kubernetes incluent:
- Pod
- Service
- Volume
- Namespace
En outre, Kubernetes contient un certain nombre d’abstractions de niveau supérieur appelées Contrôleurs. Les contrôleurs s’appuient sur les objets de base et fournissent des fonctionnalités supplémentaires. Voici quelques exemples de Contrôleurs :
- ReplicaSet
- Deployment
- StatefulSet
- DaemonSet
- Job
1. Objets Kubernetes
- Pods
- Services
- Volumes
- Espaces nommés (Namespaces)
Pods
L’unité de base de l'ordonnancement dans Kubernetes est appelé "pod". C'est une vue abstraite de composants conteneurisés. Un pod consiste en un ou plusieurs conteneurs qui ont la garantie d'être co-localisés sur une machine hôte et peuvent en partager les ressources.
Chaque pod dans Kubernetes possède une adresse IP unique (à l'intérieur du cluster), qui permet aux applications d'utiliser les ports de la machine sans risque de conflit.
Un pod peut définir un volume, comme un répertoire sur un disque local ou sur le réseau, et l'exposer aux conteneurs de ce pod. Les Pods peuvent être gérés manuellement au travers de l'API de Kubernetes. Leur gestion peut également être déléguée à un contrôleur.
Services
Un service Kubernetes est un ensemble de modules qui fonctionnent ensembles, tel qu'une couche d'une application multi-tiers. L'ensemble des pods qui constituent un service est défini par un sélecteur d'étiquettes. Kubernetes fournit deux modes de découverte de service, utilisant des variables environnementales ou utilisant le DNS de Kubernetes. La découverte de service attribue une adresse IP et un nom DNS stables au service, et répartit le trafic en fonction de la charge de manière round-robin aux connexions réseau de cette adresse IP parmi les pods correspondant au sélecteur (même lorsque les pods passent de machine en machine). Par défaut, un service est exposé à l'intérieur d'un cluster (par exemple, les pods de backend peuvent être regroupées dans un service, avec des demandes d'équilibrage de charge des pods avant entre eux), mais un service peut également être exposé en dehors du cluster (par exemple, pour que les clients puissent atteindre les pods en frontend).
Volumes
Les systèmes de fichiers dans un conteneur Kubernetes fournissent un stockage éphémère, par défaut. Cela signifie qu'un redémarrage du conteneur effacera toutes les données sur ces conteneurs, et donc, cette forme de stockage est tout à fait limité dans tout les cas sauf les applications triviales. Un volume Kubernetes fournit un stockage persistant qui existe pendant toute la durée de vie du pod. Ce stockage peut également être utilisé comme espace disque partagé pour les conteneurs à l'intérieur du pod. Les volumes sont montés à des points de montage spécifiques à l'intérieur du conteneur, qui sont définis par la configuration de la nacelle, et ne peuvent être montés sur d'autres volumes ou reliés à d'autres volumes. Le même volume peut être monté en différents points de l'arborescence du système de fichiers par différents conteneurs.
Espaces de nommage (namespaces)
Kubernetes fournit un partitionnement des ressources qu'il gère en différents ensembles qui ne se chevauchent pas appelés "namespaces". Ils sont destinés à être utilisés dans des environnements avec de nombreux utilisateurs répartis sur plusieurs équipes ou projets, ou même séparant des environnements tels que le développement, le test et la production.
2. Gestion des objets Kubernetes
Kubernetes fournit des mécanismes qui permettent de gérer, sélectionner ou manipuler ses objets.
- Étiquettes et sélecteurs
- Sélecteurs de champs
Étiquettes et sélecteurs
Kubernetes permet aux clients (utilisateurs ou composants internes) d'attacher des paires clé-valeur appelées "étiquettes" à n'importe quel objet API du système, comme les pods et les noeuds. Lorsqu'un service est défini, on peut définir les sélecteurs d'étiquettes qui seront utilisés par le routeur de service / équilibreur de charge pour sélectionner les instances du pod vers lesquelles le trafic sera acheminé. Ainsi, le simple fait de changer les étiquettes des pods ou de changer les sélecteurs d'étiquettes sur le service peut être utilisé pour contrôler quels pods reçoivent du trafic et lesquels n'en reçoivent pas, ce qui peut être utilisé pour supporter différents modèles de déploiement comme les déploiements blue-green ou les tests A-B. Cette capacité à contrôler dynamiquement la façon dont les services utilisent les ressources d'implémentation permet un couplage lâche au sein de l'infrastructure.
Par exemple, si les Pods d'une application ont des labels pour un système tier ("frontend", "backend", par exemple) et une release_track ("preproduction", "production", par exemple), alors une opération sur tous les nodes "backend" et "preproduction" peuvent utiliser un label selector comme suit :
tier=backend AND release_track=preproduction
Sélecteurs de champs
Tout comme les étiquettes, les sélecteurs de champs permettent également de sélectionner les ressources Kubernetes. Contrairement aux étiquettes, la sélection est basée sur les valeurs d'attribut inhérentes à la ressource sélectionnée, plutôt que sur une catégorisation définie par l'utilisateur. metadata.name et metadata.namespace sont des sélecteurs de champs qui seront présents sur tous les objets Kubernetes. Les autres sélecteurs qui peuvent être utilisés dépendent du type d'objet ou de ressource.
3. Architecture Kubernetes
Kubernetes suit l'architecture maitre/esclave. Les composants de Kubernetes peuvent être divisés en ceux qui gèrent un noeud individuel et ceux qui font partie du plan de contrôle.
Plan de contrôle Kubernetes
Le maître Kubernetes est l'unité de contrôle principale qui gère la charge de travail et dirige les communications dans le système. Le plan de contrôle de Kubernetes consiste en plusieurs composants, chacun ayant son propre processus, qui peuvent s'exécuter sur un seul node maître ou sur plusieurs maîtres permettant de créer des clusters haute disponibilité. Les différents composants du plan de contrôle de Kubernetes sont décrits ci-dessous:
- etcd
- Serveur d'API
- L'ordonnanceur
etcd
etcd est une unité de stockage distribuée persistante et légère de données clé-valeur développée par CoreOS, qui permet de stocker de manière fiable les données de configuration du cluster, représentant l'état du cluster à n'importe quel instant. D'autres composants scrutent les changements dans ce stockage pour aller eux-mêmes vers l'état désiré.
Serveur d'API
Le serveur d'API est un élément clé et sert l'API Kubernetes grâce à JSON via HTTP. Il fournit l'interface interne et externe de Kubernetes. Le serveur d'API gère et valide des requêtes REST et met à jour l'état des objets de l'API dans etcd, permettant ainsi aux clients de configurer la charge de travail et les containers sur les noeuds de travail.
L'ordonnanceur
L'ordonnanceur est un composant additionnel permettant de sélectionner quel node devrait faire tourner un pod non ordonnancé en se basant sur la disponibilité des ressources. L'ordonnanceur gère l'utilisation des ressources sur chaque node afin de s'assurer que la charge de travail n'est pas en excès par rapport aux ressources disponibles. Pour accomplir cet objectif, l'ordonnanceur doit connaître les ressources disponibles et celles actuellement assignées sur les serveurs.
Controller manager
Le gestionnaire de contrôle (controller manager) est le processus dans lequel s'exécutent les contrôleurs principaux de Kubernetes tels que DaemonSet Controller et le Replication Controller. Les contrôleurs communiquent avec le serveur d'API pour créer, mettre à jour et effacer les ressources qu'ils gèrent (pods, service endpoints, etc.).
Node Kubernetes
Le "Node" aussi appelé "Worker" ou "Minion" est une machine unique (ou une machine virtuelle) où des conteneurs (charges de travail) sont déployés. Chaque node du cluster doit exécuter le programme de conteneurisation (par exemple Docker), ainsi que les composants mentionnés ci-dessous, pour communiquer avec le maître afin de configurer la partie réseau de ces conteneurs.
- Kubelet
Kubelet
Kubelet est responsable de l'état d'exécution de chaque noeud (c'est-à-dire, d'assurer que tous les conteneurs sur un noeud sont en bonne santé). Il prend en charge le démarrage, l'arrêt, et la maintenance des conteneurs d'applications (organisés en pods) dirigé par le plan de contrôle.
Kubelet surveille l'état d'un pod et s'il n'est pas dans l'état voulu, le pod sera redéployé sur le même node. Le statut du node est relayé à intervalle de quelques secondes via messages d’état vers le maître. Dès que le maître détecte un défaut sur un node, le Replication Controller voit ce changement d'état et lance les pods sur d'autres hôtes en bonne santé[réf. nécessaire].
Kube-proxy
Le kube-proxy est l’implémentation d'un proxy réseau et d'un répartiteur de charge, il gère le service d'abstraction ainsi que d'autres opérations réseaux. Il est responsable d'effectuer le routage du trafic vers le conteneur approprié en se basant sur l'adresse IP et le numéro de port de la requête entrante.
cAdvisor
cAdvisor est un agent qui surveille et récupère les données de consommation des ressources et des performances comme le processeur, la mémoire, ainsi que l'utilisation disque et réseau des conteneurs de chaque node.
Plugins
...