Introduction
Dans les labs précédents, vous avez créé un seul Pod. Les Pods sont les éléments de base de Kubernetes, mais leur gestion manuelle devient vite fastidieuse. Si un Pod s’arrête, vous devez le redémarrer manuellement. Si vous avez besoin de plusieurs instances, vous devez également créer chaque Pod manuellement.
C’est là qu’intervient le Deployment.
Un Deployment est un contrôleur de niveau supérieur qui gère les ReplicaSets et les Pods à votre place. Vous indiquez le nombre de réplicas souhaité ainsi que le modèle à utiliser pour les Pods, puis Kubernetes veille à maintenir l’état réel conforme à cette déclaration.
L’idée essentielle est de passer de la gestion d’un Pod individuel à celle d’une charge de travail reproductible. Un Pod seul est fragile, car il ne représente qu’une instance. Un Deployment décrit un modèle de création des Pods et indique combien d’instances doivent exister. C’est ce modèle qui permet la mise à l’échelle et l’auto-réparation.
Dans ce lab, vous apprendrez à :
- Créer un Manager strict (Deployment) avec un objectif précis (3 réplicas).
- Observer le Manager recruter des travailleurs (Pods).
- « Tuer » un travailleur pour tester la réaction du Manager (auto-réparation).
- Demander au Manager de recruter davantage de travailleurs (mise à l’échelle).
Créer le fichier YAML du Deployment
Dans cette étape, vous allez rédiger la description de poste de votre Manager. Il s’agit d’un fichier YAML qui définit l’image à exécuter et le nombre d’instances souhaité (les réplicas).
Notez la structure supplémentaire par rapport à un manifeste de Pod simple. Un Deployment contient un selector et un template. Le selector indique à Kubernetes quels Pods appartiennent à ce Deployment, tandis que le template décrit comment créer les nouveaux Pods. Ces deux éléments doivent rester cohérents ; sinon, le Deployment ne gérera pas correctement les Pods prévus.
Commencez par vérifier que vous êtes dans le répertoire du projet :
cd ~/project
Créez un fichier nommé deployment.yaml avec nano :
nano deployment.yaml
Collez la configuration suivante dans le fichier. Faites particulièrement attention à la ligne replicas: 3 : c’est ici que vous définissez l’effectif de votre équipe.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
Pour enregistrer le fichier, appuyez sur Ctrl+X, puis sur Y, puis sur Enter.
Ce fichier indique à Kubernetes : « Créez un Deployment nommé nginx-deployment. Assurez-vous que 3 Pods exécutant l’image nginx:1.14.2 soient toujours actifs. Pour trouver ces Pods, recherchez ceux qui portent le label app: nginx. »
Appliquer la configuration et observer le résultat
Maintenant que vous avez la description de poste, recrutons le manager. Appliquez la configuration au cluster :
Lorsque vous créez un Deployment, Kubernetes crée généralement en arrière-plan un autre objet appelé ReplicaSet. Le ReplicaSet est le composant directement responsable du maintien du nombre demandé de Pods actifs. Pour le moment, les débutants n’ont pas besoin de gérer directement les ReplicaSets, mais il est utile de savoir qu’ils existent, car vous les verrez souvent dans la sortie des commandes.
kubectl apply -f deployment.yaml
Kubernetes confirme généralement la création avec le message suivant : deployment.apps/nginx-deployment created.
Le Deployment (Manager) commence immédiatement à créer 3 Pods. Pour les afficher rapidement, exécutez :
kubectl get pods
Vous devez voir 3 Pods différents, dont les noms commencent tous par nginx-deployment- :
NAME READY STATUS RESTARTS AGE
nginx-deployment-66b6c48dd5-8j64w 1/1 Running 0 5s
nginx-deployment-66b6c48dd5-d95l2 1/1 Running 0 5s
nginx-deployment-66b6c48dd5-lzr5w 1/1 Running 0 5s
Vous pouvez également vérifier l’état du Deployment lui-même :
kubectl get deployments
La colonne READY doit afficher 3/3, ce qui confirme que les 3 réplicas demandés sont actifs et en cours d’exécution.
Tester l’auto-réparation
L’une des fonctions les plus puissantes de Kubernetes est l’auto-réparation. Le Deployment garantit que le nombre réel de Pods correspond toujours au nombre souhaité (3). Si un Pod disparaît, Kubernetes le remplace immédiatement.
Cela fonctionne parce que Kubernetes compare en permanence l’état réel à l’état souhaité. La suppression d’un Pod ne modifie pas le nombre de réplicas souhaité enregistré dans le Deployment. Le système interprète donc cette suppression comme un écart et crée un remplacement.
Testons ce comportement en supprimant manuellement l’un des Pods.
Commencez par afficher de nouveau la liste des Pods :
kubectl get pods
Copiez le nom complet de l’un des Pods, par exemple nginx-deployment-66b6c48dd5-8j64w.
Supprimez ensuite ce Pod précis :
kubectl delete pod <paste-pod-name-here>
Kubernetes indique que le Pod a été supprimé. Exécutez immédiatement kubectl get pods une nouvelle fois :
kubectl get pods
Vous observerez un résultat intéressant :
- L’ancien Pod est en cours de terminaison ou a déjà disparu.
- Un nouveau Pod, avec un nom différent et un âge très faible (par exemple, 2 secondes), est déjà apparu.
Le Deployment a détecté l’absence d’un travailleur et en a immédiatement recruté un nouveau afin de maintenir l’effectif à 3. Votre application reste ainsi disponible même si des serveurs ou des conteneurs individuels rencontrent une défaillance.
Augmenter la taille du déploiement
Imaginez que votre site gagne en popularité. 3 serveurs web ne suffisent plus : vous en avez besoin de 5. Devez-vous créer manuellement de nouveaux fichiers ou vous dépêcher de créer de nouveaux Pods ?
La mise à l’échelle d’un Deployment modifie le nombre souhaité déclaré, et pas seulement l’ensemble actuel des processus en cours d’exécution. C’est pourquoi la nouvelle taille reste appliquée au-delà d’une action manuelle unique. Les contrôleurs continuent de considérer le nombre de réplicas mis à jour comme la valeur de référence jusqu’à ce que vous le modifiiez à nouveau.
Non. Il vous suffit de demander au Manager d’augmenter l’effectif.
Vous pouvez modifier le nombre de réplicas à la volée avec la commande kubectl scale.
Faites passer le nombre de réplicas de 3 à 5 :
kubectl scale deployment/nginx-deployment --replicas=5
Observez maintenant le résultat :
kubectl get pods
Vous devez maintenant voir 5 Pods en cours d’exécution. Deux nouveaux Pods ont été démarrés pour répondre à la nouvelle exigence.
Vous pouvez également réduire la taille du déploiement. Si le trafic diminue, vous pouvez économiser des ressources en réduisant le nombre de réplicas :
kubectl scale deployment/nginx-deployment --replicas=2
Exécutez de nouveau kubectl get pods. Kubernetes doit terminer les Pods supplémentaires jusqu’à ce qu’il n’en reste plus que 2.
Cette mise à l’échelle dynamique explique pourquoi les entreprises apprécient Kubernetes.
Résumé
Dans ce lab, vous avez découvert le Deployment, le gestionnaire intelligent qui maintient vos applications en fonctionnement.
Vous avez réussi à :
- Créer un Deployment avec 3 Pods travailleurs.
- Vérifier que le Deployment remplace automatiquement les Pods défaillants (auto-réparation).
- Augmenter et réduire le nombre de réplicas avec une seule commande (mise à l’échelle).
Vous comprenez maintenant pourquoi nous créons rarement des Pods autonomes. Les Deployments vous offrent fiabilité et flexibilité en prenant en charge la planification et le redémarrage complexes à votre place.
