Guide de Gestion des Clusters Kubernetes

L'Équipe Alphorm
L'Équipe Alphorm 19e lecture en min

Après avoir exploré les bases de l’administration Kubernetes dans notre article précédent, nous allons maintenant approfondir notre compréhension des contrôleurs. Dans le vaste écosystème de Kubernetes, comprendre et maîtriser les contrôleurs est essentiel pour une gestion efficace des clusters. Les contrôleurs Kubernetes jouent un rôle crucial en maintenant l’état souhaité des ressources du cluster et en automatisant de nombreuses tâches complexes. Cet article vous guidera à travers les concepts fondamentaux et les fonctionnalités avancées des contrôleurs Kubernetes, en mettant l’accent sur leur importance et leur fonctionnement pour optimiser la gestion de vos clusters.

Comprendre les Contrôleurs dans Kubernetes

Qu'est-ce qu'un contrôleur dans Kubernetes ?

Un contrôleur dans Kubernetes est un composant logiciel chargé de gérer l’état souhaité d’une ressource ou d’un ensemble de ressources. Il contrôle l’état courant des ressources et prend les mesures correctives si nécessaire pour aligner l’état actuel sur l’état souhaité. Par exemple, un contrôleur de réplicas s’assure que le nombre de pods en cours d’exécution pour une application correspond au nombre de réplicas spécifiées dans une définition de déploiement. S’il arrive qu’un pod échoue, le contrôleur en crée un nouveau pour le remplacer.

Assurer que les applications et services fonctionnent correctement est un rôle crucial des contrôleurs dans le maintien de l’état souhaité du cluster Kubernetes.

Illustration de la boucle pour la gestion des clusters kubernetes

Gestionnaire de contrôleurs Kube (Kube Controller Manager)

Le Kube Controller Manager joue un rôle vital dans Kubernetes en exécutant de nombreux contrôleurs essentiels pour le bon fonctionnement interne du cluster. Il est responsable de :

  • Gestion des contrôleurs: Exécutez différents contrôleurs tels que les contrôleurs de réplicas, de services, de nœuds et de comptes.
  • Gestion des nœuds: Gérez l’état des nœuds du cluster en traitant leur inscription, approbation et suppression.
  • Gestion des ressources: Supervise les ressources du cluster, telles que les attributions de CPU et de mémoire.
  • Gestion des comptes: Gestion des comptes utilisateurs et des autorisations d’accès au cluster.

Le bon fonctionnement de base de Kubernetes dépend du Kube Controller Manager.

Gestionnaire de contrôleurs Cloud (Cloud Controller Manager)

Le Cloud Controller Manager est un élément optionnel de Kubernetes qui gère l’intégration avec un fournisseur de cloud spécifique. Il s’occupe de tâches telles que :

  • Provisionnement d’instances: Gère les instances de calcul sur le cloud et assure leur approvisionnement.
  • Equilibrage de la charge: Configurer l’équilibrage de charge pour les services Kubernetes exposés.
  • Disques persistants: Générer et administrer les disques persistants pour les conteneurs Kubernetes.
  • Réseautage: Mettez en place le réseau pour les conteneurs Kubernetes, avec la gestion des adresses IP et la configuration des routes.

Le Cloud Controller Manager facilite la gestion des applications et des services Kubernetes dans le cloud en tirant parti des fonctionnalités spécifiques d’un fournisseur de cloud.

Schéma de la structure du Cloud Controller Manager pour la gestion des clusters kubernetes

Les Contrôleurs dans la Gestion des Clusters Kubernetes

Les Contrôleurs des Pods dans la gestion des clusters Kubernetes

Les contrôleurs de pods sont responsables de la gestion du cycle de vie des pods, en s’assurant que le nombre et l’état des pods correspondent à l’état désiré défini dans les spécifications de déploiement. Ils jouent un rôle crucial dans le maintien de la disponibilité et de la scalabilité des applications conteneurisées. Voici quelques-uns des contrôleurs les plus couramment utilisés pour gérer les pods :

  • ReplicaSet : Un ReplicaSet assure qu’un nombre donné de répliques identiques de pods est toujours en exécution. Il remplace les répliques qui échouent ou sont supprimées avec de nouvelles pour maintenir le nombre désiré.
  • Deployment : Un Deployment est une ressource de haut niveau dans Kubernetes qui s’occupe de la création, de la mise à jour et du remplacement des ReplicaSets.
  • DaemonSet : Chaque nœud du cluster exécute une copie spécifique d’un pod grâce à un DaemonSet. Il est souvent employé pour les tâches système ou d’infrastructure qui nécessitent d’être exécutées sur chaque nœud.
  • StatefulSet : À la différence de ReplicaSet, un StatefulSet maintient un état stable et unique pour chaque pod géré. Il est employé pour les applications qui ont besoin de stockage durable et d’identifiants uniques.
  • Job : Un Job crée un ou plusieurs pods pour accomplir une tâche spécifique jusqu’à son achèvement. Il est pratique pour les opérations par lots et les tâches occasionnelles.
  • CronJob : Un CronJob ressemble à un Job mais autorise l’exécution régulière de tâches en fonction d’une planification basée sur Cron.

Pour cet article nous allons explorer plus en détail les concepts de déploiement et ReplicaSet en mettant l’accent sur les stratégies de déploiement, la gestion des mises à jour et la réversibilité des déploiements. 

Les Contrôleurs des Autres Ressources dans la gestion des clusters Kubernetes

En plus des contrôleurs des pods, Kubernetes comprend également des contrôleurs pour d’autres ressources clés du cluster :

  • Node : Les nœuds sont surveillés par les contrôleurs pour leur état et leur disponibilité dans le cluster. Ils peuvent prendre des actions telles que démarrer ou arrêter de nouveaux nœuds en fonction des besoins de charge de travail.
  • Service : Les services Kubernetes sont gérés par les contrôleurs de service, ils permettent d’accéder aux applications exécutées sur les pods en tant qu’abstractions de niveau supérieur. Ils assurent que les services sont disponibles et équilibrés en charge.
  • Endpoint : Les enregistrements de points de terminaison des services sont mis à jour par les contrôleurs d’endpoint en fonction des pods disponibles. Cela permet aux services de découvrir les pods dynamiquement et de les contacter.

Fonctionnalités Avancées des Contrôleurs de Déploiement dans la Gestion des Clusters Kubernetes

Dans l’article  précédent, nous avons examiné comment déployer une application en utilisant le concept de déploiement dans Kubernetes, que ce soit de manière déclarative ou impérative. Dans cet article, nous allons approfondir notre compréhension du déploiement et explorer davantage ses avantages ainsi que différents cas d’utilisation.

Stratégies de Mise à Jour dans la gestion des clusters Kubernetes

Les contrôleurs Deployment offrent deux stratégies principales pour mettre à jour les pods d’une application et pour obtenir des informations détaillées sur les différentes stratégies de mise à jour disponibles pour les déploiements nous utilisons la commande

				
					kubectl explain deployment.spec.strategy
				
			
Schéma des stratégies de mise à jour disponibles pour les déploiements Kubernetes
  • RollingUpdate (défaut): Cette stratégie met à jour les pods de manière progressive, en remplaçant un pod par un nouveau à la fois. Cela permet de minimiser les temps d’arrêt et de garantir qu’une version de l’application reste toujours disponible pendant la mise à jour.
  • Recreate: Cette stratégie remplace tous les pods existants par de nouveaux pods en une seule fois. Elle est plus rapide que RollingUpdate, mais elle peut entraîner une brève indisponibilité de l’application. Et pour modifier la stratégie de déploiement en définissant le type de stratégie sur « Recreate » nous tapons la commande suivante :
				
					kubectl patch deployment alphorm-deploiement -p '{"spec": {"strategy": {"type": "Recreate", "rollingUpdate": null}}}'
				
			
Exemple de définition de la stratégie de mise à jour Recreate pour les déploiements de la gestion des clusters Kubernetes

La stratégie de mise à jour dépend des besoins de l’application et de la tolérance aux temps d’arrêt. Pour les applications nécessitant une disponibilité continue, il est généralement recommandé d’utiliser RollingUpdate, tandis que Recreate peut convenir aux applications moins critiques ou lors de mises à jour majeures

Pour découvrir l’intégralité de notre formation complète sur Kubernetes, veuillez suivre ce lien : Formation Kubernetes 2023. Rejoignez-nous et laissez-nous vous accompagner dans l’essor de vos compétences et de votre carrière.

Gestion du déploiement en utilisant maxUnavailable et maxSurge

Les paramètres maxUnavailable et maxSurge sont utilisés pour réguler le nombre de pods indisponibles ou en cours de création simultanément lors d’une mise à jour de déploiement.

  • maxUnavailable: Quel est le nombre maximal de pods qui peut être indisponible lors de la mise à jour ? Cela garantit qu’il y a toujours un nombre minimal de pods en cours d’exécution pour maintenir la disponibilité de l’application.
  • maxSurge: Quel est le nombre maximum de pods supplémentaires qui peuvent être créés pendant la mise à jour, en plus du nombre de réplicas souhaité ? De cette façon,nous accélérons le processus de mise à jour en créant de nouveaux pods avant de supprimer les anciens.

Et pour préciser le nombre maxUnavailable et maxSurge, nous utilisons la commande suivante :

				
					kubectl patch deployment alphorm-deploiement -p '{"spec": {"strategy": {"rollingUpdate": {"maxUnavailable": 2, "maxSurge": 1}}}}'
				
			
Exemple de spécification des paramètres maxUnavailable et maxSurge pour la gestion des clusters Kubernetes

Cela appliquera un patch à la stratégie de déploiement du déploiement alphorm-deploiement, spécifiant que jusqu’à 2 pods peuvent être indisponibles pendant une mise à jour, et qu’un maximum de 1 pod supplémentaire peut être créé pendant la mise à jour.

Utilisation des Sondes de Disponibilité pour des Déploiements Progressifs dans la gestion des clusters Kubernetes

Les probes de disponibilité, appelées également sondes, sont cruciales pour s’assurer que les applications restent disponibles dans un environnement Kubernetes. Elles servent à vérifier l’état et la disponibilité des conteneurs dans un pod, ce qui permet au système de Kubernetes de décider si un conteneur est prêt à recevoir du trafic réseau. Il existe deux types principaux de sondes de disponibilité :

  • Probe de vivacité (Liveness Probe) : Pour vérifier si un conteneur fonctionne correctement. Kubernetes redémarrera automatiquement le conteneur s’il échoue à cette sonde. Et la forme du fichier YAML pour configurer une sonde de vivacité dans la spécification d’un Pod est la suivante :
Exemple de fichier YAML pour configurer une sonde de vivacité dans la gestion des clusters Kubernetes

Cette configuration déclare une sonde de vivacité de type HTTP GET, qui interroge l’endpoint « /index.html » sur le port 8080 toutes les 10 secondes après un délai initial de 15 secondes.

  • Probe de disponibilité (Readiness Probe) : Utilisée pour déterminer si un conteneur est prêt à recevoir du trafic réseau. S’il échoue à cette sonde, le conteneur sera retiré du service et ne recevra pas de trafic avant d’être prêt.Et pour configurer une sonde de disponibilité:

 

Exemple de fichier YAML pour configurer une sonde de disponibilité dans Kubernetes

Cette configuration déclare une sonde de disponibilité de type HTTP GET, qui interroge l’endpoint « /index.html » sur le port 8080 toutes les 10 secondes après un délai initial de 15 secondes.

Historique des Déploiements et Révisions dans la gestion des clusters Kubernetes

Le suivi de l’historique des déploiements et des révisions est essentiel pour gérer efficacement les déploiements Kubernetes. Il permet de retracer les modifications apportées aux déploiements, d’identifier les problèmes potentiels et de revenir aux versions précédentes si nécessaire. Pour afficher l’historique des déploiements nous utilisons la commande suivante:

				
					kubectl rollout history deployment <nom-déploiement>
				
			
Commande kubectl pour afficher l’historique des déploiements Kubernetes

Pour afficher les détails d’une révision spécifique d’un déploiement, vous pouvez utiliser la commande :

				
					kubectl rollout history deployment <nom-déploiement> --revision=<numéro du revision>
				
			
Commande kubectl pour afficher les détails d'une révision spécifique d'un déploiement de la gestion des clusters Kubernetes

Vous pouvez aussi limiter le nombre de révisions conservées dans l’historique d’un déploiement en utilisant l’attribut revisionHistoryLimit dans la spécification du déploiement par défaut à 10 Nombre de Replicasets conservés dans l’historique .

Par exemple, pour limiter l’historique des révisions à 4, vous pouvez ajouter la ligne suivante à la spécification de votre déploiement :

				
					spec:
revisionHistoryLimit: 5
				
			

Cette spécification limitera l’historique des révisions à 4 révisions pour le déploiement.

Annulation et Redémarrage des Déploiements Kubernetes

Pour annuler un déploiement et revenir à une révision précédente, vous pouvez utiliser la commande :

				
					kubectl rollout undo deployment <nom-déploiement> --to-revision=<numéro du revision>.
				
			
Commande kubectl pour annuler un déploiement vers une révision précédente pour la gestion des clusters kubernetes

Pour redémarrer tous les pods d’un déploiement, vous pouvez utiliser la commande:

				
					kubectl rollout restart deployment <nom-déploiement>
				
			
Commande kubectl pour redémarrer tous les pods d'un déploiement de la gestion des clusters Kubernetes

Cette commande redémarrera tous les pods du déploiement, ce qui déclenchera également une nouvelle évaluation des sondes de vivacité et de disponibilité.

Après avoir redémarré un déploiement, vous pouvez utiliser la commande pour vérifier l’état du redémarrage.

				
					kubectl rollout status deployment <nom-déploiement>
				
			
Commande kubectl pour vérifier l'état du redémarrage d'un déploiement de la gestion des clusters Kubernetes

Gestion des Réplicas avec ReplicaSet dans la Gestion des Clusters Kubernetes

Un ReplicaSet, également appelé ensemble de réplicas, est un contrôleur Kubernetes chargé de la création et du maintien d’un nombre spécifié de copies identiques des pods. Assurant que le nombre nécessaire de pods est toujours opérationnel pour répondre à la demande, il joue un rôle crucial dans la mise à l’échelle et la haute disponibilité des applications conteneurisées.

Quelles sont les différences entre ReplicaSets et Deployments ?

Les ReplicaSets et les Deployments sont tous deux des contrôleurs Kubernetes utilisés pour gérer les pods, mais ils ont des rôles distincts :

Tableau comparant les ReplicaSets et les Deployments pour la gestion des clusters Kubernetes

 

  • ReplicaSets: Focalisés sur la création et le maintien d’un nombre spécifique de répliques de pods. Ils ne proposent pas de fonctionnalités avancées telles que les stratégies de déploiement progressif ou les vérifications d’état.
  • Deployments: Ils sont construits sur les ReplicaSets et offrent des fonctionnalités supplémentaires pour le déploiement d’applications. Ils supervisent les mises à jour progressives des pods, les vérifications de l’état et les plans de retour en arrière en cas de problème.

En général, les ReplicaSets sont utilisés pour les situations simples nécessitant une mise à l’échelle de base et une haute disponibilité. Les déploiements pour les mises à jour contrôlées et les fonctionnalités de sécurité pour des applications plus complexes.

Configuration d'un ReplicaSet

Un ReplicaSet est défini dans un fichier YAML avec la structure suivante :

Exemple de fichier YAML pour configurer un ReplicaSet dans Kubernetes

Exécution du fichier ci-dessus avec la commande kubectl apply -f replicaset.yaml crée un ReplicaSet nommé alphorm-replicaset qui gère 3 pods avec l’image nginx .

 

Commande kubectl pour créer un ReplicaSet dans Kubernetes

Consultation des ReplicaSets dans la gestion des clusters Kubernetes

Pour afficher la liste de tous les ReplicaSets dans notre cluster nous utilisons la commande suivante:

				
					kubectl get replicaset
				
			
Commande kubectl pour afficher la liste des ReplicaSets dans Kubernetes

Mise à l'Échelle d'un ReplicaSet

Pour modifier le nombre de répliques d’un ReplicaSet nous utilisons la commande suivante :

				
					kubectl scale replicaset <nom-replicaset> --replicas=<nombre-replicas>
				
			
Commande kubectl pour modifier le nombre de répliques d'un ReplicaSet pour la gestion des clusters Kubernetes

Suppression d'un ReplicaSet

La commande kubectl delete replicaset <nom-replicaset> permet de supprimer le ReplicaSet spécifié et ses pods associés :

Commande kubectl pour supprimer un ReplicaSet dans Kubernetes

Utilisation de ReplicaSet comme Cible d'un Horizontal Pod Autoscaler (HPA) dans la gestion des clusters Kubernetes

Un aspect puissant de l’utilisation des ReplicaSets dans Kubernetes est leur capacité à servir de cible pour le Horizontal Pod Autoscaler (HPA). Le HPA ajuste automatiquement le nombre de répliques d’un ReplicaSet en fonction de métriques définies, telles que l’utilisation du CPU ou la charge mémoire.ce qui permet de garantir des performances optimales de l’application tout en économisant les ressources lorsque la charge est faible.

Pour configurer un ReplicaSet en tant que cible pour le HPA Voici un exemple de définition :

Exemple de fichier YAML pour configurer un Horizontal Pod Autoscaler (HPA) dans Kubernetes

Cette définition spécifie un HPA nommé nommé « alphorm-hpa » qui surveille l’utilisation du CPU des pods gérés par un ReplicaSet spécifié et ajuste le nombre de réplicas entre 3 et 10 pour maintenir l’utilisation moyenne du CPU à 50%.

Une fois le HPA configuré, Kubernetes surveillera automatiquement la charge de travail et ajustera le nombre de répliques du ReplicaSet en conséquence. Pour afficher le HPA que vous avez créé, indiquant qu’il est en cours d’exécution et surveille le ReplicaSet spécifié vous utilisez la commande suivante : 

				
					kubectl get hpa
				
			
Commande kubectl pour afficher la liste des Horizontal Pod Autoscalers (HPA) dans Kubernetes

En utilisant les ReplicaSets comme cibles pour le Horizontal Pod Autoscaler, vous pouvez automatiser la gestion des répliques en fonction de la charge de travail, garantissant ainsi des performances optimales de l’application tout en optimisant l’utilisation des ressources du cluster Kubernetes.

Au cours de cet article, nous avons examiné attentivement les divers aspects des contrôleurs, allant de leur définition et leur fonctionnement à leur utilisation avancée pour la gestion précise des déploiements ainsi que l’ajustement automatique de l’échelle des applications. Nous avons aussi souligné l’importance des ReplicaSets en tant que contrôleurs clés pour assurer la disponibilité et la haute disponibilité des applications.

Conclusion

Maîtriser les contrôleurs Kubernetes est une étape clé pour optimiser la gestion des clusters et garantir la disponibilité, la scalabilité et la résilience de vos applications. En comprenant les différents types de contrôleurs et en utilisant les fonctionnalités avancées des déploiements, vous pouvez automatiser et simplifier la gestion de votre infrastructure Kubernetes. Continuez à explorer et à expérimenter avec les contrôleurs Kubernetes pour améliorer constamment l’efficacité et la performance de vos déploiements. Et par la suite nous allons traiter le volet de pods Kubernetes

Partager cet article
Par L'Équipe Alphorm Démocratiser la Connaissance Informatique pour Tous !
Suivre :
L'Équipe Alphorm, c'est la démocratisation de la connaissance informatique. Passionnés et dévoués, nous sommes là pour vous guider vers le succès en rendant la technologie accessible à tous. Rejoignez notre aventure d'apprentissage et de partage. Avec nous, le savoir IT devient une ressource inspirante et ouverte à tous dans un monde numérique en constante évolution.