Déploiements Kubernetes : guide complet
Kubernetes, très apprécié de la communauté des développeurs, est une plateforme largement utilisée pour exécuter des conteneurs Docker au sein de clusters. Cette puissante plateforme propose différentes méthodes pour déployer et mettre à jour les applications s’exécutant dans des conteneurs, offrant ainsi un haut niveau de flexibilité pour divers scénarios. Dans Kubernetes, les conteneurs s’exécutent dans des pods, et leur déploiement est défini par les « Deployments » de Kubernetes. Cet article de blog traite des « Deployments » de Kubernetes, de leurs différents 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 de ressource qui gère le déploiement et le cycle de vie des applications conteneurisées au sein des clusters. Il fournit des mises à jour aux applications, en garantissant que le nombre requis 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 ReplicaSets. Les déploiements constituent une fonctionnalité clé de Kubernetes pour l’automatisation de l’évolutivité, des mises à jour progressives et des retours en arrière.
Un déploiement est un objet Kubernetes qui spécifie l’état souhaité pour les pods ; il crée et gère des ReplicaSets 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 pod qui contiennent les conteneurs avec les applications. L’état du déploiement d’un Pod est décrit dans un manifeste.
Les administrateurs peuvent assurer l’évolutivité du nombre de Pods répliqués, effectuer le déploiement du code d’application mis à jour avec un haut niveau de contrôle, et revenir à des versions antérieures des déploiements si nécessaire. Pour gérer les Déploiements Kubernetes, les administrateurs utilisent l’outil en ligne de commande kubectl sous Linux et sur d’autres systèmes d’exploitation pris en charge. Chaque pod créé avec un Déploiement dispose d’un ReplicaSet associé à ce pod. Un ReplicaSet, quant à lui, contient un pointeur vers le Déploiement qui l’a créé.
Principes fondamentaux des Déploiements Kubernetes
Les Déploiements Kubernetes sont conçus pour déployer et assurer l’évolutivité des applications conteneurisées au sein de clusters. Les Déploiements offrent une méthode déclarative pour définir l’état souhaité de votre application et 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 :
Desired state. 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.Declarative configuration. Les 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 les actions à effectuer, l’approche déclarative de Kubernetes leur permet de définir le résultat souhaité, et Kubernetes s’charge de l’atteindre grâce à ses mécanismes internes. Le contrôleur de déploiement de Kubernetes surveille l’état de 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 effectue la surveillance de l’état du cluster en temps réel et procède à des ajustements pour qu’il corresponde à l’état souhaité.ReplicaSet. Un déploiement gère un ReplicaSet. Le ReplicaSet crée et supprime des pods selon les besoins afin de maintenir le nombre souhaité de réplicas. Cette approche permet à Kubernetes de garantir que les réplicas de pods spécifiées sont en cours d’exécution à tout moment.Rolling updates. Les déploiements prennent en charge les mises à jour progressives, qui vous permettent de mettre à jour les applications sans temps d’arrêt. 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.Rollback. Si 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 connu et satisfaisant.
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 privilégiée dans Kubernetes car elle permet de maintenir la cohérence de l’état souhaité, facilite l’automatisation et favorise une meilleure collaboration ainsi qu’un meilleur contrôle des versions. L’approche impérative peut s’avérer 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 Deployments, les Pods et les ReplicaSets fonctionnent ensemble
Dans Kubernetes, les Deployments, les Pods et les ReplicaSets 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 correcte.
- Un
Podest 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 partageant les mêmes volumes de stockage et le même espace de noms réseau. Les pods sont éphémères par nature, 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. - Un
ReplicaSetgarantit qu’un nombre spécifié de pods identiques s’exécutent à 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 appropriés. 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. - Un
Deploymentest un objet Kubernetes de niveau supérieur qui gère les ReplicaSets et permet des mises à jour déclaratives des applications. Les déploiements permettent aux administrateurs de définir l’état souhaité de votre application ainsi que 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 conformément aux 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 préservant la disponibilité de l’application.
Le déploiement gère indirectement le cycle de vie des Pods via ses ReplicaSets. En définissant 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 ReplicaSets appropriés, qui gèrent à leur tour les Pods.
Ainsi, les Pods sont les unités d’exécution exécutant les conteneurs, les ReplicaSets garantissent que le nombre requis de Pods est en cours d’exécution, et les Déploiements assurent la gestion déclarative et les mises à jour des 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 masquent la complexité liée à la gestion directe des ReplicaSets et des pods, offrant ainsi un moyen puissant de gérer les mises à jour et l’évolutivité des applications.
Détails de la configuration des Déploiements
L’utilisation de YAML pour la configuration des Déploiements 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 des données à la fois lisible par l’homme et facile à écrire. Elle est couramment utilisée pour les fichiers de configuration et l’échange de données entre des langages présentant des structures de données différentes. Dans Kubernetes, YAML sert à définir l’état souhaité de divers objets, notamment les déploiements, les services, les pods, etc. Éléments clés d’un fichier de déploiement YAML :
apiVersionsert à spécifier la version de l’API (par exemple, apps/v1) de l’objet Kubernetes.kindspécifie le type d’objet Kubernetes (par exemple, Deployment).metadatacontient des métadonnées sur l’objet, telles que son nom et ses étiquettes.spec(spécification) sert à définir l’état souhaité de l’objet Kubernetes, notamment :replicasspécifie le nombre de réplicas de pod à maintenir.selectorspécifie comment identifier les pods gérés par le déploiement.templatedéfinit le modèle de pod, y compris les métadonnées et les spécifications des pods.containersrépertorie les conteneurs au sein du pod, notamment :name: le nom du conteneurimage: l’image Docker à utiliserports: les ports à exposer
Les différences entre YAML et JSON pour la syntaxe de configuration des déploiements Kubernetes sont les suivantes :
- YAML est plus lisible par l’utilisateur, 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.
Le format YAML est généralement préféré pour les déploissements Kubernetes.
Exemple de déploiement en 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/v1
kind: Deployment
metadata:
name: deployment-name
spec:
replicas: 3
selector:
matchLabels:
app: app-name
template:
metadata:
labels:
app: app-name
spec:
containers:
- name: container-name
image: image-name:1.0
ports:
- containerPort: 80
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
env:
- name: MY_ENV_VAR
value: "some-value"
volumeMounts:
- mountPath: "/path/volume"
name: volume-name
volumes:
- name: volume-name
persistentVolumeClaim:
claimName: pvc-name
Expliquons 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, en vous assurant que vos pods et conteneurs sont configurés conformément aux conditions à remplir.
Sections de configuration clés
1. Métadonnées
metadata:
name: deployment-name
Où :
name: le nom du déploiement
2. Spec (spécification du déploiement)
spec:
replicas: 3
selector:
matchLabels:
app: app-name
Où :
replicas: le nombre de réplicas de pods à maintenir
selector: définit comment identifier les pods gérés par le déploiement à l’aide d’étiquettes
3. Modèle de pod (spécification du pod)
template:
metadata:
labels:
app: app-name
spec:
containers:
- name: container-name
image: image-name:1.0
Où : metadata: étiquettes pour identifier les pods
spec: configuration des pods et de leurs conteneurs
Configuration des conteneurs
Dans cette partie, vous pouvez consulter les sections YAML des déploiements permettant de configurer les conteneurs.
1. Image du conteneur
image: image-name:1.0
Où :
image: l’image du conteneur à utiliser. Elle peut inclure une balise (par exemple, 1.0) pour spécifier la version.
2. Ports.
ports:
- containerPort: 80
Où :
containerPort: le port sur lequel le conteneur écoutera le trafic
3. Demandes et limites de ressources
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
Où :
requests: les ressources minimales à remplir
limits: les ressources maximales que le conteneur peut utiliser
4. Variables d’environnement
env:
- name: MY_ENV_VAR
value: "some-value"
Où :
env: définit les variables d’environnement pour le conteneur
5. Montages de volumes
volumeMounts:
- mountPath: "/path/volume"
name: volume-name
Où :
volumeMounts: spécifie les volumes à monter à l’intérieur du conteneur
mountPath: le chemin d’accès à l’intérieur du conteneur où le volume sera monté
Configuration des volumes
La section est chargée de configurer les volumes.
volumes:
- name: volume-name
persistentVolumeClaim:
claimName: pvc-name
Où :
volumes: définit les volumes disponibles à monter
name: le nom du volume
persistentVolumeClaim: spécifie un PersistentVolumeClaim (PVC) à utiliser pour le volume
Configurations avancées
1. Tests de vitalité et de disponibilité
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
Où :
livenessProbe: vérifie si le conteneur est actif
readinessProbe: sert à vérifier si le conteneur actuel est prêt à accepter du trafic
2. Commande et arguments
command: ["my-command"]
args: ["arg1", "arg2"]
Où :
command: remplace le point d’entrée par défaut du conteneur
args: spécifie les arguments de la commande
3. ConfigMaps et secrets
envFrom:
- configMapRef:
name: my-configmap
- secretRef:
name: my-secret
Où :
envFrom: importe des variables d’environnement depuis un ConfigMap ou 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 métier ont des conditions à remplir différentes en matière de disponibilité et de temps de fonctionnement. Choisir la bonne stratégie vous permet d’é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 progressives et retours en arrière
Un déploiement avec mise à jour progressive implique la migration d’une version de l’application vers une autre, la version la plus récente, selon l’ordre défini. Un nouveau ReplicaSet est lancé avec la nouvelle version de l’application. Les réplicas de l’ancienne version sont arrêtées. Par conséquent, les pods de l’ancienne version sont remplacés par ceux de la nouvelle. La mise à jour progressive permet une transition en douceur des anciennes versions vers les nouvelles, mais l’opération nécessite un certain temps pour s’achever.
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 destinés aux développeurs, où l’activité des utilisateurs ne pose pas de problème. Il y a un temps d’indisponibilité 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 ainsi que l’état de l’application.
Déploiements bleu-vert
Le déploiement bleu-vert est une autre méthode permettant de mettre à jour des applications dans Kubernetes, mais avec une transition rapide. Le déploiement bleu-vert dans 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 s’effectue sur un objet Service Kubernetes chargé de l’équilibrage de charge au sein d’un cluster. Après, le trafic est immédiatement redirigé 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 liés aux différences entre les versions lors de la transition entre celles-ci. Il faut garder à 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 » de Kubernetes consiste à acheminer uniquement un petit groupe d’utilisateurs vers la nouvelle version d’une application conteneurisée. La nouvelle version s’exécute sur un sous-ensemble de pods plus restreint 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’application dans un environnement de production. Si la nouvelle version ne présente pas d’erreurs, les administrateurs étendent alors 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 alors revenir à l’ancienne version. L’avantage réside dans la possibilité de tester la nouvelle fonctionnalité auprès d’un petit groupe d’utilisateurs sans risquer de perturber le fonctionnement global du système.
Kubernetes : « Recreate Deployment »
Lorsque l’on utilise la commande « Recreate Deployment », 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 dans des conteneurs. Une fois l’opération terminée, l’état de l’application est entièrement renouvelé.
Évolutivité et gestion
Évolutivité et gestion des déploiements Kubernetes sont essentielles pour garantir que vos applications conteneurisées puissent s’adapter à des Workloads variables et maintenir une haute disponibilité. Kubernetes fournit des mécanismes robustes pour la mise à l’échelle manuelle et automatisée, ainsi que des outils permettant de gérer efficacement les déploiements.
Mise à l’échelle manuelle
La mise à l’échelle manuelle permet d’ajuster manuellement le nombre de réplicas (instances) de votre application à l’aide de l’outil en ligne de commande kubectl .
- Augmentation de l’évolutivité :
kubectl scale deployment deployment-name --replicas=10Cette commande porte le nombre de réplicas du déploiement « my-deployment » à 10.
- Réduction de l’évolutivité :
kubectl scale deployment deployment-name --replicas=2Cette commande ramène le nombre de réplicas du déploiement « my-deployment » à 2.
Horizontal Pod Autoscaler (HPA)
L’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 permettant de créer un HPA est la suivante :
kubectl autoscale deployment deployment-name --cpu-percent=50 --min=2 --max=10Cette commande configure un HPA pour
deployment-nameafin de maintenir l’utilisation du processeur à environ 50 %, avec une évolutivité du nombre de réplicas comprise entre 2 et 10. - La configuration HPA en YAML constitue une approche plus avancée. Un exemple de configuration de déploiement YAML pour la mise à l’échelle horizontale automatique est expliqué ci-dessous.
apiVersion: autoscaling/v1kind: HorizontalPodAutoscalermetadata:name: deployment-hpa-namespec:scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: deployment-nameminReplicas: 2maxReplicas: 10targetCPUUtilizationPercentage: 50Appliquez la configuration YAML à l’aide de :
ubectl apply -f hpa.yaml
Vertical Pod Autoscaler (VPA)
Le Vertical Pod Autoscaler (VPA) ajuste automatiquement les demandes et les limites de ressources des pods en fonction de l’utilisation réelle. La configuration du VPA en YAML est la suivante :
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: deployment-vpa-name
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: deployment-name
updatePolicy:
updateMode: "Auto"
Pour appliquer la configuration YAML, utilisez la commande : kubectl apply -f vpa.yaml
Bonnes pratiques pour les déploiements Kubernetes
Une configuration correcte des déploiements Kubernetes garantit un environnement performant et fiable 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 pour les déploiements Kubernetes contribuent à garantir la résilience, l’évolutivité et la facilité de maintenance de vos applications.
Use declarative configuration. Stockez vos configurations Kubernetes dans des fichiers sous contrôle de version au format YAML/JSON. Cela facilite la gestion des modifications et la restauration en cas de besoin. Utilisezkubectl apply -fpour appliquer ces configurations, car cet outil permet d’effectuer des opérations idempotentes, garantissant ainsi que l’état du cluster correspond aux fichiers de configuration.Use namespace isolation. Utilisez les espaces de noms pour isoler logiquement les différents environnements (par exemple, développement, préproduction, production) et les équipes. Cela permet de gérer plus efficacement les ressources et les autorisations.Resource requests and limits. 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.Liveness and readiness probes. Configurez des sondes de vitalité (liveness probes) pour redémarrer les conteneurs défaillants et des sondes de disponibilité (readiness probes) pour contrôler le trafic vers les conteneurs.Use labels and selectorspour organiser et sélectionner les ressources. Les étiquettes (labels) peuvent être utilisées pour regrouper les ressources par application, environnement, version, etc.Use ConfigMaps and secrets. Stockez les données de configuration non sensibles dans des ConfigMaps. Stockez les données sensibles, notamment les mots de passe et les clés API, dans des Secrets.Monitor and log your environment. Mettez en place une surveillance à l’aide d’outils tels que Grafana et Prometheus pour vérifier les performances et l’état de santé 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.Follow security best practices. Mettez en œuvre des politiques de sécurité des pods (Pod Security Policies) pour appliquer les normes de sécurité à vos pods. Utilisez des politiques réseau pour les déploiements Kubernetes afin de contrôler le trafic entre les pods.Prepare for backups and disaster recovery. Effectuez 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 pour 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 offrent une approche déclarative permettant de définir l’état souhaité des applications, notamment 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 accrues pour les applications, ce qui fait des Déploiements Kubernetes un outil essentiel pour le déploiement et l’exploitation des applications modernes.
