Introduction
Les Pods sont éphémères. Un déploiement peut remplacer des Pods lors d'un déploiement progressif, d'un redémarrage ou d'une mise à l'échelle ; les clients ne doivent donc pas se connecter directement aux adresses IP individuelles des Pods. Un Service fournit aux clients un nom stable et une adresse IP virtuelle, puis utilise des étiquettes (labels) pour acheminer le trafic vers les Pods correspondants actuels.
Dans ce laboratoire, vous allez créer un petit déploiement web, l'exposer avec un Service ClusterIP, inspecter comment le Service sélectionne les Pods backend, tester le Service depuis un Pod client et mettre à l'échelle le déploiement pour observer la mise à jour des points de terminaison (endpoints) du Service.
Créer un déploiement web
Dans cette étape, vous allez préparer un espace de noms (namespace) et créer un déploiement qui pourra être exposé ultérieurement par un Service.
Commencez dans /home/labex/project :
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 le nœud n'est pas encore prêt, attendez quelques secondes et relancez la commande.
kubectl get nodes --request-timeout=5s
La sortie attendue inclut :
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Attendez que le Pod réseau du cluster soit prêt (Ready). Ce laboratoire envoie du trafic entre les Pods via un Service, le réseau du cluster doit donc être opérationnel avant de tester l'accès.
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 espace de noms nommé ckad-prep-service et définissez-le comme espace de noms par défaut :
kubectl create namespace ckad-prep-service
kubectl config set-context --current --namespace=ckad-prep-service
Créez un déploiement nommé web-front avec un Pod NGINX. L'option --port=80 enregistre le port du conteneur dans le modèle de Pod. Cela ne crée pas de Service par lui-même.
kubectl create deployment web-front --image=nginx:1.25 --port=80
Attendez que le déploiement soit disponible, puis inspectez l'étiquette du Pod. L'étiquette app=web-front est importante car le Service l'utilisera pour trouver les Pods backend.
kubectl rollout status deployment/web-front --timeout=120s
kubectl get pods -l app=web-front --show-labels
La sortie attendue inclut :
deployment "web-front" successfully rolled out
NAME READY STATUS RESTARTS AGE LABELS
web-front-... 1/1 Running 0 ... app=web-front,...
Exposer le déploiement avec un Service ClusterIP
Dans cette étape, vous allez créer un Service pour le déploiement et inspecter les champs qui connectent le Service aux Pods.
Utilisez kubectl expose deployment pour créer un Service de type ClusterIP. Le port du Service est 80, et --target-port=80 indique au Service de transférer le trafic vers le port 80 des Pods correspondants.
kubectl expose deployment web-front --name=web-front --port=80 --target-port=80
Sortie attendue :
service/web-front exposed
Inspectez le Service :
kubectl get service web-front
La sortie attendue inclut :
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web-front ClusterIP ... <none> 80/TCP ...
Inspectez maintenant le sélecteur du Service et le mappage des ports. Le sélecteur permet au Service de trouver les Pods ; le mappage des ports permet au trafic client d'atteindre le conteneur.
kubectl get service web-front -o jsonpath='{.spec.selector.app}{" "}{.spec.ports[0].port}{":"}{.spec.ports[0].targetPort}{"\n"}'
Sortie attendue :
web-front 80:80
Kubernetes stocke les adresses backend sélectionnées dans des EndpointSlices. Listez l'objet EndpointSlice créé pour ce Service :
kubectl get endpointslice -l kubernetes.io/service-name=web-front
La sortie attendue inclut :
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
web-front-... IPv4 80 ... ...
Tester le Service depuis l'intérieur du cluster
Dans cette étape, vous allez créer un Pod client temporaire et envoyer une requête HTTP au Service. Un Service ClusterIP est destiné à un accès interne au cluster ; tester depuis un autre Pod est donc le moyen le plus direct de le vérifier.
Créez un Pod client qui reste actif :
kubectl run service-client --image=busybox:1.36 --restart=Never --command -- sleep 3600
Attendez que le Pod client soit prêt :
kubectl wait --for=condition=Ready pod/service-client --timeout=120s
Sortie attendue :
pod/service-client condition met
Utilisez wget à l'intérieur du Pod client pour interroger http://web-front. Le nom web-front est résolu en tant que Service à l'intérieur de l'espace de noms.
kubectl exec service-client -- wget -qO- http://web-front | head -n 5
La sortie attendue inclut le début de la page NGINX par défaut :
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
Cela prouve que le client a atteint le nom stable du Service et que le Service a transféré le trafic vers le Pod backend actuel.
Mettre à l'échelle le backend et vérifier les points de terminaison
Dans cette étape, vous allez mettre à l'échelle le déploiement et confirmer que le Service conserve la même porte d'entrée stable alors que ses points de terminaison backend changent.
Mettez à l'échelle le déploiement à deux répliques :
kubectl scale deployment web-front --replicas=2
kubectl rollout status deployment/web-front --timeout=120s
La sortie attendue inclut :
deployment.apps/web-front scaled
deployment "web-front" successfully rolled out
Listez les Pods. Il devrait maintenant y avoir deux Pods backend en cours d'exécution avec la même étiquette app=web-front.
kubectl get pods -l app=web-front
La sortie attendue inclut deux Pods :
NAME READY STATUS RESTARTS AGE
web-front-... 1/1 Running 0 ...
web-front-... 1/1 Running 0 ...
Comptez les points de terminaison derrière le Service. La commande affiche une ligne pour chaque adresse de point de terminaison, puis compte les lignes.
kubectl get endpointslice -l kubernetes.io/service-name=web-front -o jsonpath='{range .items[*].endpoints[*]}{.addresses[0]}{"\n"}{end}' | wc -l
Sortie attendue :
2
Interrogez à nouveau le Service depuis le même Pod client :
kubectl exec service-client -- wget -qO- http://web-front | grep '<title>Welcome to nginx'
Sortie attendue :
<title>Welcome to nginx!</title>
Résumé
Vous avez exposé un déploiement avec un Service ClusterIP et vérifié le chemin d'accès complet au sein du cluster. Vous avez créé un déploiement backend, un Service avec un sélecteur et un mappage de ports, inspecté l'objet EndpointSlice généré pour le Service, testé l'accès depuis un Pod client, puis mis à l'échelle le déploiement et confirmé que le Service continuait d'acheminer le trafic vers l'ensemble des backends mis à jour.
