Bases de l’architecture des clusters Kubernetes
La technologie Kubernetes gagne en popularitĂ© auprĂšs des entreprises technologiques d’annĂ©e en annĂ©e. En bref, le cluster Kubernetes reprĂ©sente un certain nombre de machines abstraites pour le dĂ©ploiement automatique, l’exĂ©cution, la mise Ă l’Ă©chelle et l’administration d’applications conteneurisĂ©es. Cette solution open-source a Ă©tĂ© conçue pour faciliter la gestion de l’infrastructure, et donc rationaliser les processus de dĂ©veloppement et de livraison des applications en gĂ©nĂ©ral. Plongeons dans les bases de l’architecture du cluster Kubernetes pour avoir une idĂ©e plus claire de son fonctionnement et des avantages potentiels de son utilisation.
Architecture des clusters Kubernetes
Chaque cluster Kubernetes est constituĂ© d’au moins une instance maĂźtresse, appelĂ©e plan de contrĂŽle, et de plusieurs nĆuds ouvriers, qui exĂ©cutent le systĂšme d’orchestration du cluster. Les nĆuds de tĂȘte et les nĆuds travailleurs peuvent reprĂ©senter des ordinateurs virtuels ou physiques ou des instances cloud .
Plan de contrĂŽle
Le plan de contrĂŽle est destinĂ© Ă superviser les instances de travailleurs et Ă exĂ©cuter le serveur API Kubernetes, l’ordonnanceur et tous les principaux contrĂŽleurs. Tous les aspects administratifs, tels que l’interaction entre les Ă©lĂ©ments du cluster, la persistance de l’Ă©tat du cluster et la planification de la charge de travail sont gĂ©rĂ©s dans le nĆud principal. En parlant d’environnements de production, le nĆud principal fonctionne Ă travers un certain nombre de machines et un cluster fonctionne Ă travers un certain nombre de nĆuds garantissant la stabilitĂ© et la haute disponibilitĂ©.
Les interactions entre l’administrateur et le cluster se font par le biais de requĂȘtes API Kubernetes. Elles sont administrĂ©es par le nĆud maĂźtre, puis validĂ©es et traitĂ©es par le serveur API Kubernetes. Le serveur API exĂ©cute Ă©galement tous les processus internes au cluster, il suit l’Ă©tat de tous les composants et gĂšre les Ă©changes entre eux.
L’ordonnanceur surveille le serveur API Kubernetes pour les tĂąches et les pods nouvellement créés et organise les pods d’utilisateurs vers les nĆuds de travailleurs en tenant compte des besoins en ressources, de l’emplacement des donnĂ©es, des politiques matĂ©rielles et logicielles, des spĂ©cifications d’affinitĂ©, des dĂ©lais, etc.
Un magasin clĂ©-valeur est une partie du nĆud de contrĂŽle, qui est responsable du stockage de toutes les donnĂ©es du cluster Kubernetes.
Le gestionnaire de contrĂŽleurs surveille l’Ă©tat actuel des contrĂŽleurs via le serveur API Kubernetes, le compare Ă l’Ă©tat souhaitĂ© et s’assure qu’ils coĂŻncident. Il exĂ©cute Ă©galement les processus des contrĂŽleurs Node, Job, Endpoints, Service Account et Token.
Le gestionnaire de contrĂŽleurs Cloud est nĂ©cessaire pour l’intĂ©gration avec les technologies cloud dans le cas oĂč le cluster Kubernetes est exĂ©cutĂ© dans le cloud. Il exĂ©cute les contrĂŽleurs qui sont spĂ©cifiques au fournisseur de services cloud , parmi lesquels : les contrĂŽleurs de nĆuds, de routes et de services.
NĆuds de travail
Les agents et Ă©lĂ©ments principaux du nĆud de travail fournissent l’environnement d’exĂ©cution du cluster Kubernetes.
Kubelet est exĂ©cutĂ© sur chaque nĆud du cluster. Il joue le rĂŽle de pipeline entre le serveur API et le nĆud, en rĂ©cupĂ©rant les tĂąches du serveur et en s’assurant que les conteneurs sont exĂ©cutĂ©s dans le pod utilisateur et fonctionnent correctement.
Kube-proxy est un composant rĂ©seau trĂšs important (fonctionnant sur chaque nĆud ainsi que sur Kubelet) qui gĂšre la traduction et le routage IP. Il surveille et contrĂŽle la conformitĂ© aux rĂšgles du rĂ©seau, permettant l’interaction entre le cluster de rĂ©seau interne ou externe et les User Pods.
Le moteur d’exĂ©cution de conteneur qui exĂ©cute ou arrĂȘte les conteneurs se trouve dans chaque nĆud de travail. Il peut s’agir de Docker, CRI-O, containerd ou de toute autre interface d’exĂ©cution de conteneur Kubernetes.
Composants supplémentaires
- Infrastructure sur laquelle travailler : machines physiques ou virtuelles, clouds privés, publics ou hybrides, etc.
- Container Registry pour le stockage des images de conteneurs sur lesquelles repose le cluster Kubernetes
- Stockage des donnĂ©es d’application attachĂ©es au cluster
DĂ©ploiement d’un cluster Kubernetes sur la Cloud
Compte tenu de l’architecture assez complexe du cluster Kubernetes, il peut sembler trĂšs difficile de le dĂ©ployer, de le gĂ©rer et de le maintenir Ă jour, ce qui nĂ©cessite un service distinct. Avec Hidora Cloud Platform, la solution Kubernetes Cluster est disponible pour une installation automatique en quelques clics.
1. Connectez-vous Ă votre tableau de bord Hidora Cloud .
2. Naviguez vers le Marché (sous la catégorie Clusters).
3. Trouvez le cluster Kubernetes et spĂ©cifiez vos paramĂštres dans la boĂźte de dialogue d’installation :
- Sélectionnez une version de Kubernetes pour votre cluster.
- Choisissez le tableau de bord de K8s
- SpĂ©cifiez la topologie requise : dĂ©veloppement ou production. La topologie de dĂ©veloppement comprend un plan de contrĂŽle et un nĆud de travail Ă©volutif, celle de production consiste en un plan de contrĂŽle multiple avec des Ă©quilibreurs d’API et des travailleurs Ă©volutifs.
- SĂ©lectionnez le contrĂŽleur d’entrĂ©e prĂ©fĂ©rĂ© pour votre cluster (NGINX, Traefik ou HAProxy).
- Choisissez un cluster propre ou personnalisé pour votre déploiement
- Activer ou dĂ©sactiver un stockage NFS dĂ©diĂ© avec provisionnement dynamique des volumes (GlusterFS avec trois nĆuds supplĂ©mentaires)
- Ajoutez les modules dont vous avez besoin, ils peuvent ĂȘtre activĂ©s ultĂ©rieurement via les modules complĂ©mentaires.
- Spécifiez le nom de votre environnement
- Fournir un alias d’environnement
- Sélectionnez une région
4. Cliquez sur Installer et en quelques minutes, la plateforme Hidora Cloud configurera automatiquement votre cluster Kubernetes.
Les technologies d’automatisation d’Hidora Cloud garantissent une intĂ©gration harmonieuse et facilitent le travail dans un environnement cloud .
Ăcrit par
Matthieu Robin est le CEO de Hidora, un leader stratĂ©gique expĂ©rimentĂ©, un ancien administrateur systĂšme qui a gĂ©rĂ© et configurĂ© plus d’environnements manuellement que quiconque sur la planĂšte et aprĂšs avoir compris que cela pouvait ĂȘtre fait en quelques clics a créé Hidora SA. Il intervient rĂ©guliĂšrement lors de confĂ©rences et aide les entreprises Ă optimiser leurs processus mĂ©tier grĂące Ă DevOps. Suivez-le sur Twitter.
Commencer votre essai gratuit
Choisissez votre devise