Kubernetes est l’une des plateformes d’automatisation les plus populaires pour le déploiement, la mise à l’échelle et l’exploitation de conteneurs d’applications sur un cluster d’hôtes ou de nœuds.
Cet article aborde l’un des objets centraux de Kubernetes : le déploiement. L’objectif est de comprendre son comportement et comment le créer, le mettre à jour et le supprimer.
Qu’est-ce qu’un déploiement ?
Un déploiement est l’un des objets utilisés pour lancer des pods. Les meilleures pratiques de Kubernetes encouragent l’utilisation de déploiements pour les applications sans état. Sans déploiement, vous devriez créer, mettre à jour et supprimer manuellement plusieurs Pods, ce qui serait fastidieux et irréalisable pour de nombreux Pods.
Un déploiement déclare un seul objet en YAML qui non seulement crée les Pods mais s’assure également qu’ils sont à jour et en cours d’exécution. Vous pouvez également facilement procéder à une mise à l’échelle automatique de vos applications à l’aide d’un déploiement sur Kubernetes. Ainsi, un déploiement est utilisé pour mettre à l’échelle, déployer et rétablir les versions de vos applications dans les Pods.
Un déploiement indique également à Kubernetes le nombre de copies d’un Pod que nous voulons exécuter, et Kubernetes s’occupe du reste. Le contrôleur associé créera un ReplicaSet à partir de votre configuration lors de la création d’un déploiement. Le contrôleur associé au ReplicaSet créera une série de Pods à partir de la configuration du ReplicaSet.
Les avantages de l’utilisation d’un déploiement au lieu de la création directe d’un ReplicaSet sont les suivants :
- Historisation de l’objet : chaque modification de l’objet (via un “apply” ou un “edit”) créera une sauvegarde de la version précédente.
- Gestion du rollout et du rollback : Vous pouvez revenir sur une configuration en lien avec le point précédent.
Création d’un déploiement
Il existe deux méthodes que nous pouvons utiliser pour créer un déploiement Kubernetes :
Méthode impérative
Les API de Kubernetes permettent une approche plus directe et impérative sans nécessiter de fichiers de configuration ou de manifestes formatés en YAML. Dans cette approche, il suffit de dire ce que l’on veut faire, et Kubernetes se chargera de définir ce qui doit être fait pour obtenir le résultat attendu.
Pour utiliser la méthode impérative, il suffit d’utiliser la commande ci-dessous :
kubectl create deployment nginx-deployment --image nginx --port=80
Méthode déclarative
Dans cette méthode, vous devez tout déclarer, et lorsque vous utilisez ce code, Kubernetes lit simplement vos définitions et crée exactement ce qui a été présenté ou déclaré.
Pour utiliser le déploiement déclaratif, vous devez créer un fichier YAML.
Fichier YAML pour le déploiement avec le nom new_deployment.yaml
:
apiVersion : apps/v1
kind : Déploiement
metadata :
name : nginx-deployment
spec :
#Spécifie le nombre de copies de pods
répliques : 3
#Sélectionne le Pod à gérer par le déploiement
selector :
#Correspond aux étiquettes définies
matchLabels :
deploy : exemple
template :
metadata :
#Spécifie les étiquettes sur le Pod.
labels :
deploy : example
spec :
conteneurs :
- name : nginx
image : nginx:1.20.2
Dans ce fichier YAML, après avoir défini la version de l’API Kubernetes, le type d’objet que vous créez et le nom du déploiement, il y a la section spec. Dans cette section, vous définissez d’abord la clé replicas, qui indique le nombre d’instances Pod que le déploiement doit garder actives.
Utilisez une étiquette de sélection pour identifier les Pods dans le déploiement. Pour cela, vous pouvez utiliser l’étiquette deploy, qui indique que tous les Pods qui correspondent à ces étiquettes sont regroupés dans le déploiement.
Ensuite, vous avez l’objet modèle dans lequel vous avez un modèle de pod dans votre spécification de déploiement. Lorsque le déploiement crée des modules, il les crée à l’aide de ce modèle. La spécification d’un pod normal se trouve sous la clé du modèle.
Avec ce déploiement, les images Nginx avec les étiquettes seront déployées dans les Pods. De plus, vous devez également être prudent sur ce point, et le Pod est l’unité de scalabilité dans Kubernetes, vous devez donc réfléchir au modèle que vous voulez utiliser si vous mettez plusieurs conteneurs dans le même Pod.
Ensuite, appliquez le fichier Yaml new_deployment.yaml
, en utilisant la commande suivante :
kubectl apply -f new_deployment.yaml
Après quelques secondes, vous pouvez obtenir l’état du déploiement en utilisant la commande suivante :
kubectl get all
Récupérer et mettre à jour le déploiement
Notez que vous avez créé les Pods, le déploiement et aussi un Replicaset. Ainsi, un déploiement crée et gère toujours un Replicaset. Vous pouvez maintenant utiliser la commande suivante pour décrire le déploiement :
kubectl describe deployment nginx-deployment
Vous disposez maintenant d’une description complète du déploiement. Elle met en évidence la stratégie utilisée pour créer/reconstruire les pods lorsqu’une mise à jour a été définie comme RollingUpdate.
La stratégie RollingUpdate permet une migration ordonnée d’une version d’une application vers une version plus récente. C’est la stratégie par défaut utilisée dans Kubernetes.
En outre, nous disposons également des stratégies suivantes :
- Recreate : Met fin aux instances Pod en cours d’exécution et les “recrée” avec la nouvelle version ;
- Blue/Green : Cette stratégie crée deux environnements distincts mais identiques. Dans l’environnement bleu, l’application est exécutée telle quelle, tandis que dans l’environnement vert, l’application est exécutée telle qu’elle le sera à l’avenir ;
- Canari : Stratégie de déploiement dans laquelle un sous-ensemble d’utilisateurs est impliqué dans la mise à disposition progressive d’une application ou d’un service.
Si vous optez pour le “rolling-update”, vous pouvez configurer son comportement quant au nombre de répliques souhaitées.
maxSurge
vous permet d’indiquer (en pourcentage ou en valeur absolue) le nombre de Pods qu’il peut créer en plus du nombre de répliques actuellement configurées.maxUnavailable
vous permet d’indiquer (en pourcentage ou en valeur absolue) combien de Pods peuvent être “indisponibles” pendant la mise à jour, en fonction du nombre de réplicas configurés.
En fonction de votre application et de votre autoscaler, ces configurations vous permettront d’assurer la QoS ou d’accélérer vos déploiements.
Ensuite, vous devez mettre à l’échelle les Pods à 10 et changer l’image tag de Nginx pour la plus récente.
kubectl scale deployment nginx-deployment --replicas=10
Notez que nous avons 5 conteneurs créés, et sur 10 Pods, nous en avons 5 de disponibles.
Après quelques secondes, utilisez la commande suivante :
kubectl get all
Vous pouvez voir ici que tous les Pods ont été créés et que les conteneurs sont en cours d’exécution.
Suppression de votre déploiement
Pour supprimer un déploiement Kubernetes, vous pouvez utiliser les commandes suivantes :
kubectl delete deploy nginx-deployment
kubectl delete deploy new_deployment.yaml
Helm : Simplifier les déploiements
Lorsque vous souhaitez déployer une application complexe qui utilise des dizaines voire des centaines de ressources Kubernetes, l’outil kubectl devient inadapté, c’est pourquoi l’outil Helm a été développé. Helm est un gestionnaire de paquets pour Kubernetes qui s’appuie sur kubectl et simplifie les déploiements d’applications.
Dans le vocabulaire Helm, une application est appelée release. Elle est associée à un chart, c’est-à-dire un ensemble de fichiers de configuration au format YAML contenant des variables globales et des templates décrivant les ressources Kubernetes.
Conclusion
Le déploiement est un objet essentiel de Kubernetes. Comme un grand pouvoir implique une grande responsabilité, il faut être prudent lors de sa configuration sous peine d’avoir des comportements inattendus. Pour aller plus loin dans les configurations du déploiement, vous pouvez vous référer à la documentation de Kubernetes.
Vous pouvez également explorer certains des meilleurs tutoriels Kubernetes pour apprendre à partir de zéro et devenir un expert.