Les développeurs rencontrent souvent des défis lorsqu’ils doivent assurer la disponibilité et la scalabilité des applications sur Kubernetes, notamment lors de la gestion des réplicas et des déploiements.
Sans une compréhension claire des contrôleurs Kubernetes comme les ReplicaSets et Deployments, les applications risquent des interruptions de service, une mauvaise gestion des ressources et des échecs de mise à jour.
Cet article vous guide à travers les concepts clés des contrôleurs Kubernetes, en détaillant comment optimiser les déploiements et gérer efficacement les réplicas pour des applications robustes et évolutives.
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.
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.
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
- 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}}}'
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
Initiez-vous aux bases de Kubernetes et devenez un professionnel recherché!
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}}}}'
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 :
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é:
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>
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>
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>.
Pour redémarrer tous les pods d’un déploiement, vous pouvez utiliser la commande:
kubectl rollout restart deployment <nom-déploiement>
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>
Gestion des Réplicas avec ReplicaSet dans la Gestion des Clusters Kubernetes
Exploration Complète de Kubernetes pour les DevOps et Administrateurs Systèmes
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 :
- 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 :
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 .
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
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>
Suppression d'un ReplicaSet
La commande kubectl delete replicaset <nom-replicaset> permet de supprimer le ReplicaSet spécifié et ses pods associés :
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 :
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
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.
Formez-vous gratuitement avec Alphorm !
Maîtrisez les compétences clés en IT grâce à nos formations gratuites et accélérez votre carrière dès aujourd'hui. Découvrez des cours variés pour tous les niveaux !
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
