Kubernetes network
| Fiche express | |
|---|---|
| Portée de cette page | Pratique : résolution DNS des Pods, panorama CNI, test d'une NetworkPolicy |
| Modèle et concepts | voir Réseau Kubernetes — Modèle et primitives |
| Voir aussi | CNI — Panorama et choix · NetworkPolicies |
Cette page complète Réseau Kubernetes — Modèle et primitives, qui détaille le modèle réseau de Kubernetes (règles IP-per-pod, Services, kube-proxy, CoreDNS) : elle n'y revient pas et se concentre sur trois points pratiques utiles en exploitation ou en préparation de certification — la résolution DNS d'un Pod par son adresse IP, un panorama rapide des plugins CNI courants, et un test pas à pas d'une NetworkPolicy.
Résolution DNS d'un Pod
En plus de la résolution par nom de Service (<service>.<namespace>.svc.cluster.local, voir Réseau Kubernetes — Modèle et primitives), CoreDNS résout aussi automatiquement un enregistrement par Pod, dérivé de son adresse IP :
<ip-du-pod-avec-tirets>.<namespace>.pod.cluster.local
# exemple : 192-168-0-1.default.pod.cluster.local
Vérification pas à pas, avec deux Pods de test dans le même cluster :
# Déployer les deux Pods de test
kubectl create -f dnstest-pods.yml
kubectl get pod nginx-dnstest -o wide
# 1. Joindre le Pod nginx directement par IP
kubectl exec busybox-dnstest -- curl <IP_POD_NGINX_DNSTEST>
# 2. Résoudre le nom DNS dérivé de cette IP
kubectl exec busybox-dnstest -- nslookup <ip-avec-tirets>.default.pod.cluster.local
# 3. Joindre le Pod via ce nom DNS plutôt que par IP
kubectl exec busybox-dnstest -- curl <ip-avec-tirets>.default.pod.cluster.local
Cette résolution par IP est surtout utile pour du diagnostic bas niveau ; en usage applicatif normal, on cible presque toujours un Service plutôt qu'un Pod individuel, dont l'IP est éphémère.
CNI : panorama rapide
L'implémentation concrète du réseau des Pods est déléguée à un plugin CNI. Exemples courants :
- Calico — politiques réseau avancées.
- Flannel — simplicité de mise en œuvre.
- Weave Net — approche orientée SDN.
- Cilium — basé sur eBPF, performances et fonctionnalités avancées (dont le remplacement de kube-proxy).
Pour le détail des critères de choix entre ces options, voir CNI — Panorama et choix.
NetworkPolicies : test pas à pas
Le modèle et la syntaxe des NetworkPolicies sont couverts par NetworkPolicies ; voici un scénario de validation concret, utile pour vérifier qu'une policy produit bien l'effet attendu sur un cluster de test.
# 1. Namespace de test, étiqueté (utile pour les namespaceSelector)
kubectl create namespace np-test
kubectl label namespace np-test team=np-test
# 2. Un serveur (nginx) et un client (busybox) dans ce namespace
kubectl create -f np-nginx.yml
kubectl create -f np-busybox.yml
# 3. Relever l'IP du serveur
kubectl get pods -n np-test -o wide
NGINX_IP=<IP_DU_POD_NGINX>
# 4. Sans aucune NetworkPolicy, l'accès doit réussir
kubectl exec -n np-test np-busybox -- curl $NGINX_IP
# 5. Appliquer une NetworkPolicy qui sélectionne le Pod nginx
kubectl create -f ma-networkpolicy.yml
# 6. Une policy qui ne définit aucune règle d'ingress autorisée bloque
# tout le trafic entrant vers les Pods sélectionnés : l'accès doit échouer
kubectl exec -n np-test np-busybox -- curl $NGINX_IP
# 7. Ajouter une règle d'ingress explicite (ex. port 80 pour tous les Pods du namespace)
kubectl edit networkpolicy -n np-test ma-networkpolicy
# 8. L'accès doit maintenant réussir de nouveau
kubectl exec -n np-test np-busybox -- curl $NGINX_IP
Ce cycle bloqué → débloqué illustre le modèle additif des NetworkPolicies décrit dans NetworkPolicies : dès qu'un Pod est sélectionné par au moins une policy, seul ce que cette policy autorise explicitement passe.