« Je note l’IP de mon Pod et je m’y connecte. »
Mauvaise idée : les Pods sont des cibles instables. Leur nom change quand ils sont recréés, leur IP aussi, ils vont et viennent pendant les rollouts et le scaling. En Kubernetes, on ne se connecte jamais à un Pod directement pour du long terme. On passe par un Service : une porte d’entrée stable.
À la fin de ce module, tu sauras…
- Expliquer pourquoi un Pod n’est pas une adresse fiable
- Créer un Service qui expose un Deployment
- Comprendre que le lien Service → Pods se fait par labels, pas par nom
- Tester l’accès et diagnostiquer une erreur de port
01Pourquoi un Pod n’est pas une adresse fiable
Comprends le besoin d’une couche stable
Pendant un rollout ou un scaling, les Pods apparaissent et disparaissent. Une adresse qui pointe sur un Pod donné devient fausse dès la prochaine réconciliation. Il faut une couche d’accès stable qui, elle, ne bouge pas — et qui sait toujours où sont les Pods du moment.
02Créer un Service
Une porte d’entrée pour demo-deploy
Manipulekubectl expose deployment demo-deploy --port=8092 --target-port=80 --name=demo-service
kubectl get svcservice/demo-service exposed
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
demo-service ClusterIP 10.43.51.65 <none> 8092/TCP 64sdemo-service), une IP de cluster fixe, et un port d’entrée (ici 8092). Cette adresse ne changera pas, même si les Pods derrière changent.Comprends port vs target-port, et ClusterIP
–port=8092 est le port d’entrée du Service ; –target-port=80 est le port des Pods (nginx écoute sur 80). Le type ClusterIP signifie « accessible à l’intérieur du cluster » — parfait pour les communications entre services. L’exposition vers l’extérieur (Internet) viendra avec l’Ingress.
03Le point clé : Service → labels → Pods
Comprends pourquoi le lien par labels est génial
Le Deployment crée des Pods portant certains labels. Le Service sélectionne les Pods qui correspondent à ces labels, et route le trafic vers eux. La relation est label-based, pas name-based. C’est pourquoi le Service reste stable quand les Pods sont recréés, changent d’IP, ou pendant rollouts et scaling : il vise « les bons Pods », jamais des noms précis.
04Tester l’accès (et un échec instructif)
curl depuis l’intérieur du cluster
Entre dans un Pod et interroge le Service par son nom :
Manipulekubectl exec -it demo-deploy-59d8c7f2a-aaaaa -- /bin/sh
curl http://demo-servicecurl: (28) Failed to connect to demo-service port 80 ...curl http://demo-service:8092Comprends ce que l’échec prouve
Que le nom se résolve prouve qu’il existe un DNS interne dans le cluster (on l’explore au module suivant). L’erreur de port rappelle que –port définit précisément par où entrer. Un « échec » bien lu enseigne souvent plus qu’un succès.
✓Ce que tu retiens
Un Service est la porte d’entrée stable devant un groupe de Pods : un nom et une IP fixes, un routage automatique. Le lien Service → Pods se fait par labels/selector, jamais par nom de Pod — c’est ce qui le rend insensible aux recréations, rollouts et scaling. Un ClusterIP est accessible à l’intérieur du cluster.
Une porte stable devant tes Pods
À faire
- Expose
demo-deployavec un Service (port d’entrée de ton choix, target-port 80). - Vérifie son ClusterIP et son port avec
kubectl get svc. - Depuis un Pod, teste l’accès par le nom du Service et le bon port.
- Supprime un Pod, laisse-le se recréer, et prouve que le Service répond toujours.
- Documente dans BookStack : pourquoi le lien par labels rend le Service stable.
?Auto-évaluation
1. Pourquoi ne se connecte-t-on pas directement à un Pod sur le long terme ?
Parce que son nom et son IP changent à chaque recréation, pendant les rollouts et le scaling. Le Service offre une adresse stable.
2. Comment un Service sait-il quels Pods viser ?
Par un selector de labels : il route vers tous les Pods dont les labels correspondent, pas vers des noms de Pods.
3. Que signifie le type ClusterIP ?
Le Service est accessible à l’intérieur du cluster. L’exposition vers l’extérieur se fait via un Ingress (à venir).