Kubernetes (6/12) — Networking : selector, endpoints, DNS

L’idée reçue

« Le Service route vers les Pods grâce aux ports. »

Non : les ports ne choisissent pas les Pods. Un Service a deux tâches distinctes — sélectionner les Pods (par labels) et acheminer le trafic (par ports). Confondre les deux empêche de comprendre le routage. On va tout prouver, étape par étape.

À la fin de ce module, tu sauras…

Distinguer le rôle des labels (qui) et des ports (où)
Lire la chaîne Service → selector → endpoints → Pods
Prouver que le Service répartit le trafic (load-balancing)
Comprendre le DNS interne du cluster

01Labels choisissent QUI, ports décident OÙ

Un Service a deux jobs séparés : (1) sélectionner les Pods derrière lui — par les labels ; (2) acheminer le trafic une fois les Pods choisis — par les ports.

Comprends le mécanisme réel, à mémoriser

La chaîne exacte : Service → selector → labels des Pods → liste d’endpoints → trafic acheminé vers ces endpoints. Les ports n’interviennent qu’après la sélection : ils disent où dans le Pod livrer le trafic (le targetPort). Labels = QUI reçoit ; ports = OÙ à l’intérieur.

02La carte du routage : Service → endpoints → Pods

Expérience 1

Voir selector, ports et endpoints d’un coup

Manipule

kubectl describe svc demo-service
kubectl get endpoints demo-service -o wide
kubectl get pods --show-labels

Observe

Selector:    app=demo-deploy
Port:        8092/TCP
TargetPort:  80/TCP
Endpoints:   10.42.0.9:80,10.42.1.7:80,...

# get endpoints :
NAME           ENDPOINTS                              AGE
demo-service   10.42.0.9:80,10.42.1.7:80,...          5m

Le selector (app=demo-deploy) correspond aux labels des Pods ; les endpoints sont la liste des PodIP:targetPort qui reçoivent le trafic. Tu vois toute l’histoire.

Comprends ce que sont les endpoints

Les endpoints sont la liste, tenue à jour automatiquement, des Pods qui correspondent au selector — sous forme IP:port. Si des endpoints apparaissent, c’est la preuve que le selector matche des Pods. Quand un Pod est recréé avec une nouvelle IP, cette liste se met à jour toute seule : voilà pourquoi le Service reste stable.

03Prouver le load-balancing

Expérience 2

« Qui m’a répondu ? »

La page nginx par défaut ne montre pas quel Pod répond. On ajoute un petit marqueur par Pod, puis on interroge plusieurs fois :

Manipule

for p in $(kubectl get pods -l app=demo-deploy -o name); do
kubectl exec $p -- sh -c 'echo "Servi par: $(hostname)" > /usr/share/nginx/html/whoami.txt'
done

Puis, depuis un Pod avec curl :

Manipule

for i in 1 2 3 4 5 6; do curl -s http://demo-service:8092/whoami.txt; done

Observe

Servi par: demo-deploy-59d8c7f2a-aaaaa
Servi par: demo-deploy-59d8c7f2a-bbbbb
Servi par: demo-deploy-59d8c7f2a-aaaaa
Servi par: demo-deploy-59d8c7f2a-ccccc
...

Des hostnames différents répondent selon les appels : le Service répartit le trafic entre les Pods correspondants. C’est le load-balancing, prouvé concrètement.

Comprends pourquoi ça équilibre

Le Service distribue les connexions entre tous les endpoints valides. Comme tes Pods sont plusieurs (replicas), les requêtes atterrissent sur différents Pods. Plus de replicas = plus de capacité, sans changer l’adresse d’accès.

04Le DNS interne

Expérience 3

Pourquoi « demo-service » se résout

Depuis n’importe quel Pod :

Manipule

cat /etc/resolv.conf
getent hosts demo-service || nslookup demo-service

Observe

Le résolveur DNS interne du cluster est configuré dans le Pod, et le nom demo-service se résout en l’IP du Service. C’est pourquoi tu peux écrire http://demo-service:8092 sans jamais connaître d’IP.

Comprends le DNS de cluster

Kubernetes fournit un DNS interne (CoreDNS). Chaque Service y obtient un nom résolvable depuis les Pods. C’est le mécanisme de découverte de services : une application se connecte à http://demo-service (ou son nom complet demo-service.lab-soria.svc.cluster.local), sans IP en dur. La même idée que le DNS entre services de Docker Compose (Phase 3), mais à l’échelle du cluster.

✓Ce que tu retiens

Le routage d’un Service suit la chaîne selector → labels → endpoints → Pods : les labels choisissent QUI reçoit, les ports disent OÙ livrer. La liste d’endpoints se met à jour toute seule, le trafic est réparti entre les Pods, et un DNS interne résout les noms de Services. Voilà comment un cluster communique en interne.

Mini-projet

Ouvre le capot du routage

À faire

Affiche selector, ports et endpoints de ton Service, et les labels des Pods.
Vérifie que chaque endpoint correspond bien à une IP de Pod.
Ajoute le marqueur whoami.txt et prouve le load-balancing en plusieurs appels.
Depuis un Pod, montre le resolv.conf et la résolution du nom de Service.
Documente dans BookStack la chaîne selector → endpoints → Pods.

Fil rouge — Ton Service fonctionne à l’intérieur du cluster. Mais SORIA Web doit être joignable depuis Internet, en HTTPS. Au module suivant : l’Ingress (avec Traefik, intégré à K3s) et le TLS automatique.

?Auto-évaluation

1. Les ports servent-ils à choisir les Pods ?

Non. Les labels (selector) choisissent les Pods ; les ports n’interviennent qu’après, pour dire où livrer le trafic dans le Pod.

2. Que contient la liste d’endpoints d’un Service ?

Les IP:port des Pods qui correspondent au selector. Elle se met à jour automatiquement quand les Pods changent.

3. Comment un Pod résout-il le nom « demo-service » ?

Via le DNS interne du cluster (CoreDNS), qui donne à chaque Service un nom résolvable — la découverte de services.