Apprenons l'architecture de Kubernetes en détail.
Je suppose que vous avez une compréhension de base de Kubernetes. Sinon, consultez les articles d'introduction et d'installation suivants.
Kubernetes suit l'architecture maître-esclave. L'architecture Kubernetes a un nœud maître et des nœuds de travail. Il y a quatre composants d'un noeud maître.
- Serveur API Kube
- contrôleur
- ordonnanceur
- etcd
Et le nœud de travail a trois composants.
- kubelet
- kube-proxy
- runtime du conteneur
Voici à quoi ressemble une architecture Kubernetes:
Laissez-moi vous parler en détail des composants du nœud maître et des nœuds de travail.
Master Node
Le nœud maître gère le cluster Kubernetes et constitue le point d'entrée pour toutes les tâches administratives. Vous pouvez parler au nœud maître via l'interface de ligne de commande, l'interface graphique ou l'API. Pour atteindre la tolérance aux pannes, il peut y avoir plus d'un nœud maître dans le cluster. Lorsque nous avons plus d'un nœud maître, il y aurait un mode haute disponibilité, et avec un leader effectuant toutes les opérations. Tous les autres nœuds maîtres seraient les suiveurs de ce nœud maître principal.
De plus, pour gérer l'état du cluster, Kubernetes utilise etcd. Tous les nœuds maîtres se connectent à etcd, qui est un magasin clé-valeur distribué.
Laissez-moi vous expliquer tous ces composants un par un.
Serveur API
Le serveur API effectue toutes les tâches administratives sur le nœud maître. Un utilisateur envoie les commandes restantes au serveur API, qui valide ensuite les demandes, puis les traite et les exécute. etcd enregistre l'état résultant du cluster en tant que magasin clé-valeur distribué.
Planificateur
Après cela, nous avons un planificateur. Ainsi, comme son nom l'indique, le planificateur planifie le travail sur différents nœuds de travail. Il contient les informations d'utilisation des ressources pour chaque nœud de travail. Le planificateur prend également en compte les exigences de qualité de service, la localité des données et de nombreux autres paramètres de ce type. Ensuite, le planificateur planifie le travail en termes de pods et de services.
Gestionnaire de contrôleur
Les boucles de contrôle sans terminaison qui régulent l'état du cluster Kubernetes sont gérées par Control Manager. Désormais, chacune de ces boucles de contrôle connaît l'état souhaité de l'objet qu'elle gère, puis examine son état actuel via les serveurs d'API.
Dans une boucle de contrôle, si l'état souhaité ne correspond pas à l'état actuel de l'objet, alors les mesures correctives sont prises par la boucle de contrôle pour amener l'état actuel au même niveau que l'état souhaité. Ainsi, le gestionnaire de contrôleur s'assure que votre état actuel est le même que l'état souhaité.
etcd
L'etcd est un magasin clé-valeur distribué qui est utilisé pour stocker l'état du cluster. Donc, soit il doit faire partie du maître Kubernetes, soit vous pouvez également le configurer en externe. etcd est écrit dans le goLang, et il est basé sur le Consensus du radeau algorithme.
Le radeau permet à l'ensemble de machines de fonctionner comme un groupe cohérent qui peut survivre aux défaillances de certains de ses membres. Même si certains membres ne fonctionnent pas, cet algorithme peut toujours fonctionner à tout moment. L'un des nœuds du groupe sera le maître et les autres seront les suiveurs.
Il ne peut y avoir qu'un seul maître, et tous les autres maîtres doivent suivre ce maître. Outre le stockage de l'état du cluster, etcd est également utilisé pour stocker les détails de configuration tels que les sous-réseaux et les mappages de configuration.
Worker Node
Un nœud de travail est un serveur virtuel ou physique qui exécute les applications et est contrôlé par le nœud maître. Les pods sont planifiés sur les nœuds worker, qui disposent des outils nécessaires pour les exécuter et les connecter. Les pods ne sont rien d'autre qu'un ensemble de conteneurs.
Et pour accéder aux applications depuis le monde extérieur, vous devez vous connecter aux nœuds worker et non aux nœuds maîtres.
Explorons les composants du nœud de travail.
Runtime du conteneur
Le runtime du conteneur est essentiellement utilisé pour exécuter et gérer un cycle de vie continu sur le nœud worker. Quelques exemples d'exécutions de conteneurs que je peux vous donner sont les conteneurs rkt, lxc, etc. comme runtime du conteneur.
kubelet
Kubelet est essentiellement un agent qui s'exécute sur chaque nœud de travail et communique avec le nœud maître. Ainsi, si vous avez dix nœuds de travail, kubelet s'exécute sur chaque nœud de travail. Il reçoit la définition du pod par divers moyens et exécute les conteneurs associés à ce port. Il s'assure également que les conteneurs qui font partie des dosettes sont toujours sains.
Le kubelet se connecte au runtime du conteneur à l'aide du framework gRPC. Le kubelet se connecte à l'interface d'exécution du conteneur (CRI) pour effectuer des opérations sur les conteneurs et les images. Le service d'imagerie est responsable de toutes les opérations liées aux images tandis que le service d'exécution est responsable de toutes les opérations liées aux pod et aux conteneurs. Ces deux services ont deux opérations différentes à effectuer.
Permettez-moi de vous dire quelque chose d'intéressant, les environnements d'exécution des conteneurs étaient codés en dur dans Kubernetes, mais avec le développement de CRI, Kubernetes peut désormais utiliser différents environnements d'exécution de conteneurs sans avoir besoin de recompiler. Ainsi, tout environnement d'exécution de conteneur qui implémente CRI peut être utilisé par Kubernetes pour gérer des pods, des conteneurs et des images de conteneurs. Le shim Docker et les conteneurs CRI sont deux exemples de shim CRI. Avec docker shim, les conteneurs sont créés à l'aide de docker installé sur les nœuds de travail, puis en interne, docker utilise un conteneur pour créer et gérer des conteneurs
Proxy Kube
Kube-proxy s'exécute sur chaque nœud de travail en tant que proxy réseau. Il écoute le serveur API pour chaque création ou suppression de point de service. Pour chaque point de service, kube-proxy définit les routes afin qu'il puisse y accéder.
Conclusion
J'espère que cela vous aidera à mieux comprendre l'architecture de Kubernetes. Les compétences Kubernetes sont toujours à la demande, et si vous cherchez à apprendre à construire votre carrière, jetez un œil à ceci Cours Udemy.
