Blog 

09.01.23 ● Jospin Anogo, DevOps engineer ● 5 minutes lecture

Si vous êtes ici, vous souhaitez débuter ou débuter la prise en main du plus connu des orchestrateurs : Kubernetes. Premièrement, c’est une bonne chose. L’incontournable Kubernetes est une techno présente et d’avenir qui ne cesse d’être adoptée partout dans le monde. Deuxièmement, son apprentissage n’est pas un long fleuve tranquille. Ne vous découragez pas. La communauté est engagée, les ressources gratuites d’apprentissage sont nombreuses, les formations utiles. Troisièmement, commencer par comprendre son architecture est la bonne chose à faire ! Alors regardons celle-ci de plus près .

Kubernetes est un orchestrateur de conteneurs. En d’autres termes, l’outil open-source vous permet de gérer vos multiples workloads et services conteneurisés préalablement avec une solution type Docker. En somme, vous pourrez être amené à gérer un seul nœud (idéal pour les phases de développement ou de test) ou des clusters à plusieurs milliers de nœuds. Enfin très important, kubernetes est portable, c'est-à-dire qu’il peut être déployé à l’aide de machines physiques ou virtuelles sur site ou dans le cloud. Cette dernière information a pour avantage de vous laisser le choix des services cloud, et l’inconvénient, de rajouter un peu de piment dans votre quotidien d’ingénieur. 

Voici l'architecture de Kubernetes. Avant de décortiquer tous les éléments ci-dessus, revenons sur ses concepts et composants fondamentaux : 

Un pod Kubernetes est un ensemble d’un ou plusieurs conteneurs, ceux-ci bénéficiant des mêmes ressources de calcul. Ainsi, un pod exécuté sur un cluster  s'assure que ses conteneurs soient exécutés ensemble sur le même cluster. 

Un cluster Kubernetes est constitué d’un ensemble de machines : les nœuds. Ils se regroupent en deux catégories : masters et workers. Les nœuds workers exécutent les instructions fournies par les nœuds masters et exécutent vos solutions conteneurisées.

Le data plane de Kubernetes est l’ensemble des machines de la catégorie : worker. Il se charge d'exécuter les instructions provenant du plan de contrôle et exécuter vos solutions conteneurisées. 

Le control plane de Kubernetes est l'ensemble des machines de la catégorie : master.  Il se charge principalement de gérer le fonctionnement des clusters Kubernetes en respectant vos configurations. 

Le control plane est l'élément central d’un cluster Kubernetes car il réunit l’ensemble des composants qui le contrôle. En somme, c’est grâce au control plan que votre cluster fonctionne sur la base de vos configurations en s’assurant que suffisamment de conteneurs peuvent s'exécuter avec les ressources nécessaires. Les composants qui le compose sont : l'API server, le scheduler, le controller manager, l'etcd. 

Le kube-APIserver est l'élément central du plan de contrôle en assurant toutes les communications internes et externes en exposant l’API Kubernetes. Il détermine si la requête est valide ou non et la traite dans le cas échéant. L'interaction se fait via les requêtes REST à l’aide Kubectl (interface de ligne de commande) et des outils de ligne de commande. 

Le Kube-scheduler est responsable de planifier l’affectation des pods aux différents nœuds de votre cluster qui répondent à vos besoins d’espaces. Pour ce faire, il tient compte du taux de charge et de la capacité des nœuds, le besoin en ressource (mémoire, processeur, volume) des différents pods. Vous pouvez très bien personnaliser des schedulers et en exécuter plusieurs sur un cluster. 

Le kube-controller-manager est l’ensemble de contrôleurs (déploiement,tâches, namespace, réplicats…) qui assurent que l’état de votre cluster est conforme à vos attentes. Pour ce faire, il consulte au scheduler pour s’assurer que le nombre de pods désirés est bien exécuté. Dans le cas où un pod est défaillant, il le détecte et le corrige. 

Vous pourrez aussi personnaliser vos propres controllers - appelés Operator - lié à une définition de ressource personnalisée (sans cette ressource le contrôleur personnalisé ne fonctionnera pas). 

Le controller cloud manager : Nous avons parlé de la portabilité de Kubernetes soit sa capacité à être déployé sur n’importe quel type de serveur (on-premise, cloud privé ou public). Dans un contexte de déploiement dans un environnement cloud, le cloud manager controller est une passerelle entre entre l’API de la plateforme cloud utilisée et votre cluster Kubernetes. Ainsi, vous bénéficiez des controllers spécifiques au cloud. 

L’etcd, le seul composant stateful du control plane, est la base de données de votre cluster Kubernetes. Il contient l’ensemble des informations de configurations, d'exécutions et de l’état du cluster. Cette base stocke tous vos objets sous la clé /registry au format clé-valeur : /registry/pods/exemple/redhat.

En cas de panne de l’etcd, vos applications en cours d’exécution n’en seront pas affectées. En revanche, vous ne pourrez plus créer ou mettre à jour vos objets. 

Le Data plane renferme la charge du métier. L'exécution de vos services conteneurisés respecte les instructions du control plan que vous avez configuré. Les nœuds de catégorie worker vont exécuter les workloads (pods) applicatifs. Pour faire évoluer les capacités de votre cluster, il vous suffira d'augmenter le nombre de workers. Ces workers sont constitués d’un ensemble de composants : Kubelet, le moteur d'exécution des conteneurs, le Kube-proxy. 

Kubelet est un agent présent dans chaque worker. Responsable de la communication en le control plane et les workers, il se charge d'exécuter les conteneurs dans les pods et d'exécuter les actions instruites par le control plane. De plus, Il a la responsabilité de collecter les metrics sur le worker et de les envoyer au control plan afin que le scheduler puisse plannifier l’affectation des pods sur la base d’informations exactes. 

Présent dans chaque worker, le container runtime exécute les conteneurs. En d’autres termes, il met en œuvre son environnement d’exécution, Docker par exemple. Kubernetes gère bien sûr d’autres solutions si elles sont conformes aux normes OCI (Open Container Initiative) comme rkt ou encore CRI-O. 

Enfin le Kube-proxy ! Ce dernier composant - deamonset - œuvre à l’équilibrer les charges du trafic vers un ensemble de pods. En somme, il assure la disponibilité des services Kubernetes stockés dans le etcd via leurs IP virtuelles à tous les clusters. 

Sur le schéma ci-dessus, vous constatez différentes formes de communication entre chaque élément, en voici les étapes : 

1) L’utilisateur entre les commandes via l’invite de commande Kubectl ; ces instructions représentent la configuration de l’état souhaité.

(!) À l’utilisation de Kubectl, vous communiquez avec le API server via l’API HTTP REST. 

(!) L’API server va communiquer avec tous les autres éléments en Protobuf (sauf etcd) pour assurer que le client et les composants s'entendent malgré la distance.  

2) L’API server reçoit ces commandes comme des requêtes HTTP REST et vérifie leurs conformités

3) Le controller manager fait une comparaison entre l’état souhaité et l’état actuel du cluster kubernetes, exemple : ajout de pods

4) Le scheduler vérifie les besoins de ressources des pods à ajouter, puis demande une collecte de métriques du plan de données via l’API server.

5) La demande arrive sur le Kubelet qui se charge de faire cette collecte sur chaque worker et envoyer ces informations au scheduler via l’API server.

6) Le scheduler planifie alors le déploiement des pods en question sur les workers ayant assez de ressources et respectant les exigences demandées.

7) Le kubelet des workers concernés exécutent les pods via les container runtimes en communicant sur le port CRI puis configurent le réseau des services et pods 

(!) Le conteneur runtime expose des API CRI gRPC qui représentent les points de terminaison d'exécution et de service d’imagerie. 

(!) Kubelet communique avec le Container Runtime via l’interface CRI (container runtime interface) 

8) L’état actuel et les informations de configuration sont donc stockés dans la base de données etcd.

(!) Etcd expose l’API traduit les appels d’API HTTP en message gRPC (un Remote Procedural Calls optimisé par le géant google - d’où le “g”). 

Comprendre le fonctionnement de Kubernetes vous aidera à améliorer votre approche dans l’usage quotidien du gouvernail. C’est aussi vous assurer une meilleure compréhension des futures sources d’apprentissage que vous allez lire ou regarder. Enfin : ne vous découragez pas, l'écosystème Kubernetes est passionnant et vous offrira de nombreuses opportunités ! 

Pour vous aider dans votre parcours, voici un pense-bête à toujours avoir sur vous :

Définition du multi-cloud et vue d'ensemble sur ses tenants et aboutissants.

Introduction au modèle multi-cloud d'un point de vue business.

Introduction aux architectures en microservices.

Assurons que vos efforts investis dans le cloud soient rentables … dans le temps !

© Copyright BeOpen IT.  All Rights Reserved