Tout au long de cette série, Craig Bowers, développeur de systèmes Cloud, démystifiera pour vous Kubernetes, communément appelé k8s. Dans ce blog, Craig va décomposer les composants de k8s.
Commençons par les bases : qu’est-ce que Kubernetes ?
Selon le site kubernetes.io, « Kubernetes est une plateforme open-source portable et extensible pour la gestion de charges de travail et de services conteneurisés, qui facilite à la fois la configuration déclarative et l’automatisation. » (https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/).
Kubernetes est une excellente plateforme pour la gestion des conteneurs. Elle offre de nombreuses fonctionnalités au-delà de la simple exécution de votre application conteneurisée, l’une des principales étant la sécurité. Elle peut être exécutée partout, que votre infrastructure soit dans le Cloud ou sur place.
Répartition des composants de Kubernetes
Maintenant que vous savez ce qu’est Kubernetes, regardons de plus près les composants impliqués. Dans ce premier article, je vais décomposer les composants de k8s. Dans les articles suivants, je m’appuierai sur cette base pour vous emmener dans une plongée plus détaillée dans l’écosystème k8s.
Au niveau le plus élevé se trouve le plan de contrôle (alias le maître) et les nœuds de travail. Le plan de contrôle est le cerveau de l’écosystème k8s et se compose du serveur API, du programmateur, du gestionnaire de contrôleur et, surtout, d’ETCD. Ces processus qui travaillent ensemble gèrent l’état du cluster dans son ensemble. Les nœuds de travail, comme vous l’avez probablement déjà deviné, sont l’endroit où s’exécutent vos charges de travail conteneurisées. Les nœuds de travail sont constitués des composants d’exécution kube-proxy, kubelet et conteneu Jetons un coup d’œil au plan de contrôle et aux nœuds de travail.
Chaque interaction dans k8s est un appel RESTful API et le serveur API est donc la porte d’entrée de l’environnement k8s. L’API est responsable du stockage des objets de l’API dans un état persistant. C’est là que l’ETCD entre en scène. L’ETCD est un magasin clé-valeur fiable, généralement déployé dans une architecture distribuée. En gros, c’est le backend de la base de données qui stocke tout ce qui se passe dans le cluster k8s. Le serveur API est le seul composant de l’écosystème k8s qui interagit avec ETCD. Techniquement, il y a d’autres circonstances, mais pour garder les choses simples, nous allons nous en tenir à cela pour l’instant. L’API elle-même est divisée en groupes, ce qui signifie que l’interaction des ressources de k8s tombera dans l’un de ces groupes. Je vous le montrerai en action dans une prochaine série.
Le planificateur est exactement ce qu’il semble être, il est responsable de la planification des pods sur les nœuds de travail. Il surveille les nouveaux pods en attente et trouve un nœud de travail avec suffisamment de ressources pour traiter les spécifications du pod. Le planificateur doit tenir compte de certaines considérations lorsqu’il décide sur quel nœud de travail planifier le pod. Le planificateur ne fait que programmer le pod sur un nœud, il n’exécute pas réellement le pod. Toute cette discussion sur les pods, mais de quoi s’agit-il ? Je pensais que k8s était une plateforme de conteneurs ? Pour l’instant, il suffit de considérer qu’un pod est la même chose qu’un conteneur. Nous reviendrons plus en détail sur les pods dans le prochain article.
Le gestionnaire de contrôleurs est un processus démon qui gère les contrôleurs. L’important ici est de comprendre le rôle d’un contrôleur dans l’écosystème k8s. Pensez aux contrôleurs comme étant responsables de la gestion d’un groupe limité de ressources. Par exemple, un ReplicationController est chargé de s’assurer que le nombre correct de pods est exécuté dans les nœuds de travail. Son seul rôle est de connaître l’état actuel et souhaité d’un pod donné, ainsi que le nombre d’instances de pod qui devraient fonctionner sur les nœuds de travail. Il adopte la même conception que les microservices, c’est-à-dire qu’il remplit une seule fonction et la remplit bien. Cela rend également les contrôleurs extensibles et vous pouvez créer vos propres contrôleurs personnalisés lorsque c’est nécessaire. Les contrôleurs par défaut sont la réplication, les nœuds, les points de terminaison et le jeton de compte de service &. Les contrôleurs sont les cerveaux de l’opération. Nous reviendrons sur les détails de ces contrôleurs dans un prochain article.
Nœuds de travail
Maintenant que nous avons compris comment fonctionne le plan de contrôle, examinons les nœuds de travail. Nous avons moins de composants de ce côté, mais c’est là que le vrai travail se fait, votre code et votre logique commerciale ! Le kubelet est le processus en aval du planificateur et du ReplicationController. Une fois que le planifiateur a attribué un nœud au pod, le kubelet est chargé d’exécuter le pod dans le moteur de conteneurs conformément à ses spécifications. Si le pod devait se planter pour une raison quelconque, le kubelet le remettrait en marche. Le kubelet gère également d’autres interactions avec le pod, comme la récupération des journaux, l’état, les métriques et le shelling dans le pod.
Le composant kube-proxy est chargé de gérer les règles de mise en réseau sur le système d’exploitation hôte sous-jacent pour la communication de service à service. Cela se fait généralement via iptables ou d’autres mécanismes de routage natifs de Linux. L’un des réseaux superposés de k8s est le réseau de services. C’est le réseau qui permet à votre pod de communiquer avec un autre groupement de pods. Je vais approfondir les services et la mise en réseau dans une prochaine série, mais ce qu’il faut retenir ici, c’est que le réseau de services lui-même est une abstraction et n’est pas vraiment une adresse routable. C’est pourquoi kube-proxy écrit des règles de routage qui réécriront l’IP de destination vers l’une des IP des pods de ce service particulier.
Enfin, le composant d’exécution du conteneur. Vous êtes probablement déjà nombreux à connaître ce composant. Deux moteurs de conteneurs populaires sont Docker et containerd. Ils fournissent simplement un environnement d’exécution qui comprend la composition de votre image de conteneur et l’exécute.
Restez à l’écoute des prochains billets où je me plongerai dans les ressources déployées dans l’environnement k8s. Je couvrirai l’autorisation, les pods, les services, les contrôleurs par défaut et plus encore !
Lisez le prochain article de cette série ici.
Vous pouvez vous référer à la documentation officielle des composants Kubernetes ici :
https://kubernetes.io/docs/concepts/overview/components/
