Déploiements Kubernetes : guide complet
Kubernetes, très apprécié par la communauté des développeurs, est une plateforme largement utilisée pour exécuter des conteneurs Docker en clusters. Cette plateforme puissante offre différentes méthodes pour déployer et mettre à jour des applications s’exécutant dans des conteneurs, offrant ainsi un haut niveau de flexibilité pour différents scénarios. Dans Kubernetes, les conteneurs s’exécutent dans des pods, et leur déploiement est défini par les déploiements Kubernetes. Cet article de blog traite des déploiements Kubernetes, de leurs types, des stratégies de déploiement et des bonnes pratiques.
Qu’est-ce qu’un déploiement Kubernetes ?
Un déploiement dans Kubernetes est un objet ressource qui gère le déploiement et le cycle de vie des applications conteneurisées dans des clusters. Il fournit des mises à jour aux applications, garantissant que le nombre nécessaire de pods identiques est en cours d’exécution et disponible à tout moment. Il fournit également des mises à jour déclaratives pour les pods et les réplicasets. Les déploiements sont une fonctionnalité clé de Kubernetes pour automatiser l’évolutivité, les mises à jour progressives et les retours en arrière.Le déploiement est un objet Kubernetes qui spécifie l’état souhaité pour les pods. Il crée et gère des réplicasets afin de garantir le maintien de cet état. Un ReplicaSet gère directement les pods, y compris leur état et leur nombre. Le déploiement indique à Kubernetes comment modifier ou créer les instances de pods qui contiennent les conteneurs avec les applications. L’état du déploiement des pods est décrit dans un manifeste.Les administrateurs peuvent assurer l’évolutivité du nombre de pods répliqués, déployer le code applicatif mis à jour avec un niveau de contrôle élevé et revenir à des versions antérieures des déploiements si nécessaire. Pour gérer les déploiements Kubernetes, les administrateurs utilisent la ligne de commande kubectl outil sous Linux et autres systèmes d’exploitation pris en charge. Chaque pod créé avec un déploiement dispose d’un ensemble de répliques associé à ce pod. Un ensemble de répliques dispose quant à lui d’un pointeur vers le déploiement qui l’a créé.
Principes fondamentaux des déploiements Kubernetes
Les déploiements Kubernetes sont développés pour déployer et assurer l’évolutivité d’applications conteneurisées dans des clusters. Les déploiements fournissent un moyen déclaratif de définir l’état souhaité de votre application et d’automatiser le processus permettant d’atteindre et de maintenir cet état. Les concepts et composants fondamentaux liés aux déploiements Kubernetes sont les suivants :
- État souhaitéLe déploiement définit l’état souhaité d’une application, tel que le nombre de réplicas d’un pod, les images de conteneur à utiliser et les ressources allouées à chaque pod.
- Configuration déclarativeLes déploiements utilisent généralement une approche déclarative, dans laquelle les administrateurs spécifient l’état dans un fichier JSON ou YAML. Alors que l’approche impérative permet aux administrateurs de définir directement ce qu’il faut faire, l’approche déclarative dans Kubernetes leur permet de définir le résultat souhaité, et Kubernetes l’atteindra grâce à ses mécanismes internes. Le contrôleur de déploiement Kubernetes surveille la santé des nœuds et des pods. En cas de changements en temps réel, tels qu’une défaillance d’un pod, celui-ci peut être remplacé. Ainsi, Kubernetes surveille l’état du cluster en temps réel et effectue des ajustements pour correspondre à l’état souhaité.
- Réplique de jeu. Un déploiement gère un ensemble de répliques. L’ensemble de répliques crée et supprime des pods selon les besoins afin de maintenir le nombre souhaité de répliques. Cette approche permet à Kubernetes de s’assurer que les répliques de pods spécifiées sont exécutées à tout moment.
- Mises à jour continuesLes déploiements prennent en charge les mises à jour progressives, qui vous permettent de mettre à jour l’application sans interruption de service. Kubernetes remplace progressivement les anciens pods par de nouveaux, ce qui permet de garantir que l’application conteneurisée reste disponible pendant le processus de mise à jour du déploiement.
- Retour en arrièreSi un problème survient lors d’une mise à jour dans Kubernetes, vous pouvez revenir à une version précédente du déploiement, rétablissant ainsi l’application dans un état satisfaisant et fonctionnel.
Configuration déclarative
Dans Kubernetes, une approche déclarative signifie que vous spécifiez l’état souhaité du système, et Kubernetes prend les actions nécessaires pour atteindre et maintenir cet état. Vous décrivez l’objectif final à l’aide de fichiers de configuration (généralement écrits en YAML ou JSON), et Kubernetes veille en permanence à ce que l’état réel corresponde à l’état souhaité.L’approche déclarative est généralement préférée dans Kubernetes, car elle permet de maintenir la cohérence de l’état souhaité, de faciliter l’automatisation et de favoriser une meilleure collaboration et un meilleur contrôle des versions. L’approche impérative peut être utile pour des tâches rapides et ponctuelles, mais elle est moins adaptée à la gestion de déploiements d’applications complexes et à long terme.
Comment les déploiements, les pods et les réplicasets fonctionnent ensemble
Dans Kubernetes, les déploiements, les pods et les réplicasets sont des composants étroitement liés qui gèrent collectivement le déploiement, l’évolutivité et le cycle de vie des applications. Il est important de comprendre la relation qui les unit et de savoir comment ils fonctionnent ensemble dans Kubernetes pour une configuration adéquate.
- A Pod est l’objet le plus simple et le plus petit d’un cluster Kubernetes. Il représente une instance unique d’un processus en cours d’exécution. Un pod peut contenir un ou plusieurs conteneurs qui partagent les mêmes volumes de stockage et le même espace de noms réseau. Les pods sont éphémères de par leur conception, car ils peuvent être créés et détruits selon les besoins afin de correspondre à l’état souhaité spécifié par des objets de niveau supérieur tels que les déploiements.
- A Réplique de jeu garantit qu’un nombre spécifié de pods identiques sont exécutés à tout moment. Il gère la création et la suppression des pods afin de maintenir le nombre souhaité de répliques. Chaque ReplicaSet utilise des sélecteurs d’étiquettes pour identifier et gérer les pods sous son contrôle, garantissant ainsi le maintien des pods corrects. Bien que vous puissiez créer et gérer directement des ReplicaSets, ceux-ci sont généralement gérés par des déploiements, qui offrent des fonctionnalités supplémentaires.
- A Déploiement est un objet Kubernetes de niveau supérieur qui gère les ReplicaSets et fournit des mises à jour déclaratives aux applications. Les déploiements permettent aux administrateurs de définir l’état requis de votre application et d’autres paramètres, comme expliqué ci-dessus.
Lorsque vous créez ou mettez à jour un déploiement, celui-ci crée automatiquement un nouveau ReplicaSet pour gérer les pods selon les spécifications définies. Chaque fois que vous mettez à jour un déploiement, un nouveau ReplicaSet est créé pour gérer la nouvelle version des pods, tandis que l’ancien ReplicaSet reste en place jusqu’à ce que les nouveaux pods soient déployés avec succès. Cela garantit que les mises à jour sont mises en œuvre de manière contrôlée, tout en maintenant la disponibilité de l’application.Le déploiement gère indirectement le cycle de vie des pods via ses réplicasets. Par la définition de l’état souhaité dans le déploiement, vous spécifiez les caractéristiques et le nombre de pods que vous souhaitez exécuter. Le déploiement garantit ensuite cet état en gérant les réplicasets appropriés, qui à leur tour gèrent les pods.Ainsi, les pods sont les unités d’exécution qui exécutent les conteneurs, les ReplicaSets garantissent que le nombre nécessaire de pods est en cours d’exécution et les déploiements fournissent une gestion déclarative et des mises à jour pour les applications en contrôlant les ReplicaSets. Cette structure hiérarchique garantit que vos applications sont évolutives, résilientes et faciles à gérer. Les déploiements abstraient les complexités de la gestion directe des ReplicaSets et des pods, offrant un moyen puissant de gérer les mises à jour et l’évolutivité des applications.
Détails de la configuration du déploiement
L’utilisation de YAML pour la configuration du déploiement dans Kubernetes est une pratique courante en raison de sa lisibilité et de sa simplicité. Kubernetes prend en charge les formats YAML et JSON pour les fichiers de configuration, mais YAML est plus largement utilisé en raison de sa syntaxe conviviale.YAML (YAML Ain’t Markup Language) est une norme de sérialisation de données à la fois lisible par l’homme et facile à écrire. Il est couramment utilisé pour les fichiers de configuration et l’échange de données entre des langages ayant des structures de données différentes. Dans Kubernetes, YAML est utilisé pour définir l’état souhaité de divers objets, notamment les déploiements, les services, les pods, etc.Composants clés d’un fichier de déploiement YAML :
- apiVersion est utilisé pour spécifier la version de l’API (par exemple, apps/v1) de l’objet Kubernetes.
- gentil spécifie le type d’objet Kubernetes (par exemple, déploiement).
- métadonnées contient des métadonnées sur l’objet, telles que son nom et ses étiquettes.
- spécification (spécification) est utilisé pour définir l’état souhaité de l’objet Kubernetes, notamment :
- réplicas spécifie le nombre de réplicas de pod à conserver.
- sélecteur spécifie comment identifier les pods gérés par le déploiement.
- modèle définit le modèle de pod, y compris les métadonnées et les spécifications des pods.
- conteneurs répertorie les conteneurs dans le pod, notamment :
- nom: le nom du conteneur
- image: l’image Docker à utiliser
- ports: les ports à exposer
Les différences entre YAML et JSON pour la syntaxe de configuration du déploiement Kubernetes sont les suivantes :
- YAML est plus lisible pour l’homme, utilisant l’indentation et des paires clé-valeur sans accolades ni crochets.
- JSON utilise une structure plus rigide avec des accolades ({}) et des crochets ([]), ce qui le rend moins lisible pour les configurations complexes.
YAML est généralement préféré pour les déploiements Kubernetes.
Exemple de déploiement YAML
Vous trouverez ci-dessous un exemple de déploiement Kubernetes au format YAML avec des configurations détaillées pour les pods et les conteneurs.apiVersion : apps/v1type : Déploiementmétadonnées : nom : nom-du-déploiementspécification : réplicas : 3 sélecteur : matchLabels : application : nom-de-l’application modèle : métadonnées : étiquettes : application : nom-de-l’application spécification : conteneurs : – nom : nom-du-conteneur image : nom-de-l’image : 1.0 ports: – port du conteneur : 80 ressources: demandes : mémoire : « 128 Mi » processeur : « 250 m » limites : mémoire : « 256 Mi » processeur : « 500 m » env : – Nom : MY_ENV_VAR valeur : « une-valeur » volumeMounts : – mountPath : « /chemin/volume » Nom : nom-du-volume volumes : – Nom : nom-du-volume persistentVolumeClaim : claimName : nom-pvcExpliquons chaque section en détail pour plus de clarté. Par la configuration de ces sections, vous pouvez définir un déploiement d’application robuste et évolutif dans Kubernetes, garantissant que vos pods et conteneurs sont configurés selon vos conditions à remplir.
Sections clés de configuration
1. Métadonnéesmétadonnées : nom : nom-du-déploiementOù :Nom : le nom du déploiement2. Spec (spécification de déploiement)spécification : réplicas : 3 sélecteur : matchLabels : application : nom-de-l’applicationOù :réplicas: le nombre de réplicas de pod à conserversélecteur : définit comment identifier les pods gérés par le déploiement à l’aide d’étiquettes3. Modèle de pod (spécification de pod)modèle : métadonnées : étiquettes : application : nom-de-l’application spécification : conteneurs : – Nom : nom-du-conteneur image : nom-de-l’image : 1.0Où :métadonnées : étiquettes pour identifier les goussesspécification : configuration des pods et de leurs conteneurs
Configuration des conteneurs
Dans cette partie, vous pouvez voir les sections YAML des déploiements pour configurer les conteneurs.1. Image du conteneurimage : nom-de-l’image : 1.0Où :image : l’image du conteneur à utiliser. Elle peut inclure une balise (par exemple, 1.0) pour spécifier la version.2. Ports.ports:– port du conteneur : 80Où :port du conteneur : le port sur lequel le conteneur écoutera le trafic3. Demandes et limites de ressourcesressources : demandes : mémoire : « 128 Mi » processeur : « 250 m » limites : mémoire : « 256 Mi » processeur : « 500 m »Où :demandes : les conditions à remplir pour obtenir les ressources minimaleslimites : les ressources maximales que le conteneur peut utiliser4. Variables d’environnementenv :– Nom : MY_ENV_VAR valeur : « une-valeur »Où :env : définit les variables d’environnement pour le conteneur5. Montages de volumesvolumeMounts :– mountPath : « /chemin/volume » Nom : nom-du-volumeOù :volumeMounts : spécifie les volumes à monter à l’intérieur du conteneurcheminD’accès: le chemin à l’intérieur du conteneur où le volume sera monté
Configuration des volumes
Le volumes La section est responsable de la configuration des volumes.volumes :– Nom : nom-du-volume persistentVolumeClaim : claimName : nom-pvcOù :volumes : définit les volumes disponibles pour être montésNom : le nom du volumepersistentVolumeClaim : spécifie un PersistentVolumeClaim (PVC) à utiliser pour le volume
Configurations avancées
1. Sondes de vivacité et de disponibilitélivenessProbe : httpGet : chemin : /healthz port : 8080 délai initial en secondes : 3 duréeEnSecondes : 3readinessProbe : httpGet : chemin : /prêt port : 8080 délai initial en secondes : 5 duréeEnSecondes : 10Où :livenessProbe : vérifie si le conteneur est actifreadinessProbe : est utilisé pour vérifier si le conteneur actuel est prêt à accepter le trafic2. Commande et argumentscommande : [« my-command »]args : [« arg1 », « arg2 »]Où :commande : remplace le point d’entrée par défaut du conteneurargs : spécifie les arguments de la commande3. ConfigMaps et secretsenvDe :– configMapRef : Nom : ma-configmap– secretRef : Nom : mon-secretOù :envDe : importe les variables d’environnement à partir d’un ConfigMap ou d’un secret
La stratégie de déploiement Kubernetes
Il existe plusieurs stratégies (types) de déploiement Kubernetes, et vous pouvez sélectionner celle qui est la plus efficace pour votre scénario actuel. Les applications ont des conditions à remplir différentes en matière de disponibilité et de temps de fonctionnement. En choisissant la bonne stratégie, vous pouvez éviter les temps d’arrêt et les interruptions de service, tout en utilisant efficacement les ressources. Vous trouverez ci-dessous les types de déploiement Kubernetes les plus courants.
Mises à jour et retours en arrière progressifs
Un déploiement progressif suppose la migration d’une version d’application vers une autre, la version la plus récente dans l’ordre défini. Un nouveau ReplicaSet est lancé avec la nouvelle version de l’application. Les réplicas de l’ancienne version sont supprimées. En conséquence, les pods de l’ancienne version sont remplacés par les nouveaux. Le déploiement progressif permet une transition en douceur de l’ancienne version vers la nouvelle, mais l’opération nécessite un certain temps.
Recréer le déploiement
Les pods actuellement en cours d’exécution sont arrêtés, puis recréés avec une nouvelle version. Cette stratégie de déploiement est couramment utilisée dans les environnements Kubernetes pour les développeurs, où l’activité des utilisateurs n’est pas un problème. Il y a un temps d’arrêt lorsque l’ancien déploiement est arrêté, la stratégie de recréation du déploiement lance les nouvelles instances de déploiement et recrée les pods et l’état de l’application.
Déploiements bleu-vert
Le déploiement bleu-vert est une autre façon de mettre à jour les applications dans Kubernetes, mais avec une transition rapide. Le déploiement bleu-vert Kubernetes suppose l’exécution de deux environnements : l’ancienne version (bleue) et la nouvelle version (verte). Les deux sont déployées « côte à côte » ou en parallèle. Une fois que la nouvelle version a été testée et que son bon fonctionnement a été confirmé (elle fonctionne comme prévu), le label de version est remplacé en mettant à jour le sélecteur de service. Cette action est effectuée pour un objet Kubernetes Service qui effectue l’équilibrage de charge dans un cluster. Après cela, le trafic est immédiatement basculé vers la nouvelle version.La stratégie de déploiement Blue-Green de Kubernetes permet aux administrateurs d’effectuer un déploiement rapide sans les problèmes causés par les différentes versions lors de la transition entre celles-ci. Gardez à l’esprit que l’utilisation des ressources est plus élevée, car deux environnements fonctionnent en parallèle pendant un certain temps.
Déploiements Canary
Le déploiement canary Kubernetes suppose que seul un petit groupe d’utilisateurs est redirigé vers la nouvelle version d’une application conteneurisée. La nouvelle version fonctionne sur un sous-ensemble de pods plus petit que l’ancienne version qui fonctionnait jusqu’alors. L’objectif principal des déploiements canary est de tester les fonctionnalités des nouvelles versions d’applications dans un environnement de production. Si aucune erreur n’est détectée dans la nouvelle version, les administrateurs procèdent à la mise à l’échelle de la nouvelle version et la version précédente est remplacée dans l’ordre approprié.Si un problème survient après le déploiement de la nouvelle version pour un petit groupe d’utilisateurs, les administrateurs peuvent revenir à l’ancienne version. L’avantage réside dans la possibilité de tester les nouvelles fonctionnalités sur un petit groupe d’utilisateurs sans risque d’effets négatifs sur le fonctionnement global du système.
Recréer le déploiement Kubernetes
Lorsque vous utilisez la fonction « Recréer le déploiement », tous les pods sont arrêtés et remplacés par la nouvelle version. Cette stratégie peut être utilisée lorsque l’ancienne et la nouvelle version ne peuvent pas fonctionner simultanément. Le temps d’indisponibilité dépend du temps nécessaire pour arrêter l’ancienne application et démarrer la nouvelle application dans les conteneurs. Une fois cette opération terminée, l’état de l’application est entièrement renouvelé.
Évolutivité et gestion
L’évolutivité et la gestion des déploiements Kubernetes sont essentielles pour garantir que vos applications conteneurisées puissent fonctionner avec des Workloads variables et maintenir une haute disponibilité. Kubernetes fournit des mécanismes robustes pour l’évolutivité manuelle et automatisée, ainsi que des outils pour gérer efficacement les déploiements.
Évolutivité manuelle
L’évolutivité manuelle permet d’ajuster manuellement le nombre de répliques (instances) de votre application à l’aide de la commande kubectl outil en ligne de commande.
- Évolutivité :
kubectl scale déploiement nom-du-déploiement ––réplicas=10
Cette commande augmente le nombre de réplicas pour le déploiement my-deployment à 10.
- Évolutivité :
kubectl scale déploiement nom-du-déploiement ––réplicas=2
Cette commande réduit le nombre de réplicas pour le déploiement my-deployment à 2.
Autoscaler horizontal à pods (HPA)
Le Horizontal Pod Autoscaler (HPA) ajuste automatiquement le nombre de réplicas de pods en fonction de l’utilisation observée du processeur ou d’autres métriques sélectionnées.
- La commande pour créer un HPA est :
kubectl autoscale déploiement nom-du-déploiement ––cpu-percent=50 ––min=2 ––max=10
Cette commande configure un HPA pour nom-du-déploiement maintenir l’utilisation du processeur à environ 50 %, avec une évolutivité allant de 2 à 10 réplicas.
- La configuration HPA dans YAML est une méthode plus avancée. Un exemple de configuration de déploiement YAML pour l’autoscaling horizontal est expliqué ci-dessous.
apiVersion : autoscaling/v1
type : HorizontalPodAutoscaler
métadonnées :
nom : nom-du-HPA-du-déploiement
spécification :
scaleTargetRef :
apiVersion : apps/v1
type : Déploiement
nom : nom-du-déploiement
minReplicas : 2
maxReplicas : 10
targetCPUUtilizationPercentage : 50
Appliquez la configuration YAML avec :
ubectl apply -f hpa.yaml
Autoscaler vertical à pods (VPA)
Le Vertical Pod Autoscaler (VPA) ajuste automatiquement les demandes de ressources et les limites des pods afin de les adapter à l’utilisation réelle. La configuration VPA dans YAML est la suivante :apiVersion : autoscaling.k8s.io/v1type : VerticalPodAutoscalermétadonnées : nom : nom-du-déploiement-vpaspécification : référence cible : apiVersion : « apps/v1 » type : Déploiement nom : nom-du-déploiement updatePolicy : mode de mise à jour : « Auto »Pour appliquer la configuration YAML, utilisez la commande :kubectl apply -f vpa.yaml
Bonnes pratiques pour les déploiements Kubernetes
La configuration correcte des déploiements Kubernetes garantit un environnement fiable et performant pour l’exécution d’applications conteneurisées. Une configuration incorrecte ou une stratégie de gestion des déploiements inadaptée peut entraîner des temps d’arrêt, des pertes de données, entre autres problèmes. Les bonnes pratiques en matière de déploiements Kubernetes contribuent à garantir la résilience, l’évolutivité et la maintenabilité de vos applications.
- Utiliser la configuration déclarative. Stockez vos configurations Kubernetes dans des fichiers contrôlés par version au format YAML/JSON. Cela facilite la gestion des modifications et la restauration si nécessaire. Utilisez kubectl apply -f pour appliquer ces configurations, car cela permet des opérations idempotentes, garantissant que l’état du cluster correspond aux fichiers de configuration.
- Utiliser l’isolation des espaces de noms. Utilisez des espaces de noms pour isoler logiquement différents environnements (par exemple, développement, préproduction, production) et équipes. Cela permet de gérer plus efficacement les ressources et les autorisations.
- Demandes de ressources et limites. Définissez les demandes et les limites de ressources pour vos pods afin de vous assurer qu’ils disposent des ressources nécessaires et d’éviter les conflits d’accès aux ressources.
- Sondes de vivacité et de disponibilitéConfigurez des sondes de vivacité pour redémarrer les conteneurs défectueux et des sondes de disponibilité pour contrôler le trafic vers les conteneurs.
- Utilisez des étiquettes et des sélecteurs pour organiser et sélectionner les ressources. Les étiquettes peuvent être utilisées pour regrouper les ressources par application, environnement, version, etc.
- Utilisez les ConfigMaps et les secrets. Stockez les données de configuration non sensibles dans ConfigMaps. Stockez les données sensibles, y compris les mots de passe et les clés API, dans Secrets.
- Surveillez et consignez votre environnement. Mettez en place une surveillance à l’aide d’outils tels que Grafana et Prometheus pour vérifier les performances et l’état de vos applications conteneurisées. Utilisez des solutions de journalisation centralisées telles que la pile ELK (Elasticsearch, Logstash, Kibana) ou Fluentd pour collecter et analyser les journaux.
- Suivez les bonnes pratiques en matière de sécurité. Mettez en œuvre des politiques de sécurité des pods afin d’appliquer les normes de sécurité à vos pods. Utilisez les politiques réseau pour les déploiements Kubernetes afin de contrôler le trafic entre les pods.
- Préparez-vous pour les sauvegardes et la reprise après sinistreEffectuez des sauvegardes régulières de vos ressources Kubernetes et de vos données persistantes. Planifiez et testez des stratégies de reprise après sinistre afin de garantir que les applications et les services puissent être rapidement restaurés en cas de panne.
Conclusion
Les déploiements Kubernetes jouent un rôle crucial dans la gestion du cycle de vie des applications au sein d’un cluster Kubernetes. Ils fournissent une approche déclarative pour définir l’état souhaité des applications, y compris le nombre de réplicas, les images de conteneurs et les paramètres de configuration. Par l’orchestration des ReplicaSets, les déploiements garantissent que le nombre spécifié de pods est en cours d’exécution et gèrent automatiquement les mises à jour et les retours en arrière de manière contrôlée et transparente. Il en résulte une évolutivité, une résilience et une facilité de gestion améliorées pour les applications, ce qui fait des déploiements Kubernetes un outil essentiel pour le déploiement et l’exploitation des applications modernes.
