Introduction
Un Pod exécute des conteneurs, mais un Pod seul n'est pas la méthode habituelle pour exécuter une application dans Kubernetes. Un déploiement (Deployment) décrit l'état souhaité d'une application et crée un ReplicaSet, qui se charge ensuite de créer et de maintenir les Pods.
Dans ce laboratoire, vous allez créer votre premier déploiement, attendre qu'il soit disponible, inspecter le déploiement, le ReplicaSet et les Pods créés, puis observer comment le déploiement restaure les Pods après leur suppression. Il s'agit des bases nécessaires pour aborder les sujets CKAD ultérieurs tels que la mise à l'échelle (scaling), les mises à jour progressives (rolling updates), les retours en arrière (rollback) et l'exposition d'applications.
Préparer un namespace pour le déploiement
Dans cette étape, vous allez préparer un namespace propre pour vous entraîner aux déploiements et en faire le namespace par défaut pour vos commandes.
Commencez dans /home/labex/project. Vous n'aurez pas besoin d'écrire de manifeste dans ce laboratoire, mais utiliser le même espace de travail permet de maintenir la cohérence du cours.
mkdir -p /home/labex/project
cd /home/labex/project
Vérifiez que le serveur API Kubernetes est accessible. Si la machine virtuelle vient de démarrer et que cette commande échoue, attendez quelques secondes et réessayez jusqu'à ce que le nœud soit à l'état Ready.
kubectl get nodes --request-timeout=5s
La sortie attendue inclut :
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Les Pods ont besoin du plugin réseau du cluster avant de pouvoir devenir Ready. Attendez le Pod Calico avant de créer des charges de travail applicatives.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Sortie attendue :
pod/calico-node-... condition met
Créez un namespace nommé ckad-prep-deployments :
kubectl create namespace ckad-prep-deployments
La commande doit confirmer la création :
namespace/ckad-prep-deployments created
Définissez ce namespace comme namespace du contexte actuel :
kubectl config set-context --current --namespace=ckad-prep-deployments
Confirmez le namespace actuel :
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Sortie attendue :
ckad-prep-deployments
Créer le déploiement
Dans cette étape, vous allez créer un déploiement nommé web-demo avec deux répliques.
La commande kubectl create deployment demande à Kubernetes de créer un objet Deployment. L'option --image définit l'image du conteneur dans le modèle de Pod, et --replicas=2 demande au déploiement de maintenir deux Pods correspondants en cours d'exécution.
kubectl create deployment web-demo --image=registry.k8s.io/pause:3.10.1 --replicas=2
Sortie attendue :
deployment.apps/web-demo created
Attendez que le déploiement soit terminé. Pour un nouveau déploiement, le statut de déploiement signifie que Kubernetes a créé le ReplicaSet et que les Pods demandés sont devenus disponibles.
kubectl rollout status deployment/web-demo --timeout=90s
La sortie peut inclure de courts messages d'attente pendant que les Pods deviennent disponibles. Elle devrait se terminer par :
deployment "web-demo" successfully rolled out
Inspectez maintenant le résumé du déploiement :
kubectl get deployment web-demo
La sortie attendue inclut :
NAME READY UP-TO-DATE AVAILABLE AGE
web-demo 2/2 2 2 ...
Inspecter le ReplicaSet et les Pods
Dans cette étape, vous allez inspecter les objets créés sous le déploiement.
Un déploiement n'exécute pas directement les conteneurs. Il crée un ReplicaSet, et le ReplicaSet crée les Pods. Le sélecteur du déploiement et les labels du modèle de Pod relient ces objets entre eux.
Tout d'abord, inspectez le label du sélecteur et le label du modèle sur le déploiement. JSONPath affiche uniquement les champs sélectionnés, ce qui permet de garder une sortie ciblée.
kubectl get deployment web-demo -o 'jsonpath={.spec.selector.matchLabels.app}{" "}{.spec.template.metadata.labels.app}{"\n"}'
Sortie attendue :
web-demo web-demo
La première valeur est le label du sélecteur du déploiement. La seconde valeur est le label placé sur les Pods à partir du modèle. Ils correspondent, le déploiement peut donc gérer ces Pods.
Listez le ReplicaSet créé par le déploiement :
kubectl get replicasets -l app=web-demo
La sortie attendue inclut :
NAME DESIRED CURRENT READY AGE
web-demo-... 2 2 2 ...
Listez maintenant les Pods sélectionnés par le même label :
kubectl get pods -l app=web-demo --show-labels
La sortie attendue inclut deux Pods en cours d'exécution :
NAME READY STATUS RESTARTS AGE LABELS
web-demo-... 1/1 Running 0 ... app=web-demo,pod-template-hash=...
web-demo-... 1/1 Running 0 ... app=web-demo,pod-template-hash=...
Enfin, affichez le type de propriétaire (owner kind) pour chaque Pod. Chaque Pod appartient à un ReplicaSet, et non directement au déploiement.
kubectl get pods -l app=web-demo -o 'custom-columns=NAME:.metadata.name,OWNER:.metadata.ownerReferences[0].kind,PHASE:.status.phase'
Sortie attendue :
NAME OWNER PHASE
web-demo-... ReplicaSet Running
web-demo-... ReplicaSet Running
Observer la restauration de l'état souhaité
Dans cette étape, vous allez supprimer les Pods actuels et observer le déploiement restaurer l'état souhaité.
C'est la différence clé entre un Pod isolé et un déploiement. Si vous supprimez des Pods isolés, ils disparaissent. Si vous supprimez des Pods gérés par un déploiement, celui-ci remarque que l'état réel ne correspond plus à l'état souhaité et crée des remplaçants.
Supprimez les Pods sélectionnés par app=web-demo. L'option --wait=false rend la main immédiatement après l'envoi de la requête de suppression, vous permettant ainsi d'observer la récupération sans attendre que chaque ancien Pod ne disparaisse d'abord.
kubectl delete pods -l app=web-demo --wait=false
La sortie attendue inclut :
pod "web-demo-..." deleted from ckad-prep-deployments namespace
pod "web-demo-..." deleted from ckad-prep-deployments namespace
Attendez que le déploiement redevienne disponible :
kubectl wait --for=condition=Available deployment/web-demo --timeout=90s
Sortie attendue :
deployment.apps/web-demo condition met
Listez à nouveau les Pods :
kubectl get pods -l app=web-demo
La sortie attendue inclut deux Pods en cours d'exécution. Les noms peuvent être différents car le ReplicaSet a créé des remplaçants.
NAME READY STATUS RESTARTS AGE
web-demo-... 1/1 Running 0 ...
web-demo-... 1/1 Running 0 ...
Vérifiez une fois de plus le résumé du déploiement :
kubectl get deployment web-demo
La sortie attendue inclut :
NAME READY UP-TO-DATE AVAILABLE AGE
web-demo 2/2 2 2 ...
Résumé
Vous avez créé un déploiement, attendu son déploiement complet, inspecté ses labels de sélecteur et de modèle de Pod, identifié le ReplicaSet et les Pods créés, et observé la restauration de l'état souhaité après la suppression des Pods. Ces concepts vous préparent aux prochains laboratoires sur les déploiements, où vous modifierez le nombre de répliques, mettrez à jour des applications et gérerez le comportement des déploiements.
