Réseau Kubernetes en pratique : CNI, Services et Ingress

Le réseau est souvent le point d''achoppement numéro un quand on déploie un cluster Kubernetes. Pods qui ne communiquent pas entre eux, Services inaccessibles, Ingress mal configuré : les symptômes sont variés, mais la cause revient presque toujours à une incompréhension du modèle réseau de Kubernetes. Pour bien comprendre ce mécanisme, il faut partir des fondations : le CNI.

Avant de plonger dans les plugins, posons les règles du jeu. Kubernetes impose un modèle réseau plat avec trois contraintes fondamentales :

1. Chaque Pod reçoit sa propre adresse IP, sans NAT entre Pods.
2. Tous les Pods peuvent communiquer entre eux, quel que soit le node sur lequel ils tournent.
3. Les agents sur un node (kubelet, kube-proxy) peuvent communiquer avec tous les Pods de ce node.

Concrètement, cela signifie que Kubernetes ne fournit pas lui-meme l''implémentation réseau. Il délègue cette responsabilité à un plugin CNI (Container Network Interface). C''est ce plugin qui crée les interfaces réseau dans les Pods, attribue les adresses IP et gère le routage entre nodes.

Flannel : la simplicité avant tout

Flannel est le CNI le plus simple. Il crée un overlay réseau VXLAN qui permet aux Pods de communiquer entre nodes. C''est souvent le défaut sur les distributions légères comme K3s.

# Installation Flannel via kubectl
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

Ses avantages : installation en une commande, faible consommation mémoire, idéal pour du lab ou du développement. Ses limites : aucune NetworkPolicy native, pas de chiffrement intégré, pas d''observabilité. Pour de la production, Flannel est insuffisant.

Calico : le standard production

Calico ajoute ce qui manque à Flannel : les NetworkPolicies, le support BGP pour le routage L3, et plusieurs backends (VXLAN, IPIP, BGP direct). C''est le choix éprouvé pour les environnements on-premises et hybrides.

# Exemple de NetworkPolicy Calico
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Pour bien comprendre ce mécanisme : Calico fonctionne en mode L3 par défaut. Chaque node annonce ses routes Pod via BGP, ce qui élimine l''encapsulation VXLAN et réduit la latence. En environnement multi-datacenter, cette approche est particulièrement efficace.

Cilium : la nouvelle référence eBPF

Cilium repose sur eBPF (extended Berkeley Packet Filter), une technologie qui permet d''exécuter du code directement dans le noyau Linux sans passer par les chaines iptables traditionnelles. Concrètement, cela signifie que le traitement réseau est plus rapide, plus observable et plus programmable.

# Installation Cilium via Helm
helm install cilium cilium/cilium --version 1.16.5 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true

Les atouts de Cilium en 2026 :

• Remplacement de kube-proxy : Cilium gère le load balancing directement en eBPF, supprimant les milliers de règles iptables.
• Observabilité avec Hubble : visualisation des flux réseau L3/L4/L7 en temps réel.
• Policies L7 : filtrage au niveau HTTP, gRPC, Kafka (pas seulement IP/port).
• Service mesh sans sidecar : alternative à Istio sans les proxies Envoy.

Pour approfondir l''architecture eBPF et ses cas d''usage en sécurité, consultez notre article sur Cilium et eBPF.

Quel CNI choisir ?

Si vous démarrez un nouveau cluster en 2026, Cilium est la recommandation. Pour un cluster existant sous Calico qui fonctionne bien, la migration n''est justifiée que si vous avez besoin d''observabilité L7 ou de service mesh intégré.

Une fois le CNI en place, Kubernetes expose les Pods via des Services. Il en existe trois types principaux.

ClusterIP : communication interne

Le type par défaut. ClusterIP attribue une IP virtuelle accessible uniquement depuis l''intérieur du cluster. C''est le mécanisme utilisé pour que vos microservices communiquent entre eux.

apiVersion: v1
kind: Service
metadata:
  name: api-backend
spec:
  type: ClusterIP
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080

Le DNS interne résout api-backend.default.svc.cluster.local vers cette IP virtuelle. kube-proxy (ou Cilium en mode kube-proxy replacement) redirige ensuite le trafic vers les Pods correspondants.

NodePort : exposition basique

NodePort ouvre un port statique (30000-32767) sur chaque node du cluster. Tout trafic arrivant sur node-ip:node-port est redirigé vers le Service.

apiVersion: v1
kind: Service
metadata:
  name: api-backend
spec:
  type: NodePort
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 31080

En pratique, NodePort est rarement utilisé directement en production. Il sert surtout de brique de base pour les LoadBalancer et certains Ingress controllers.

LoadBalancer : intégration cloud

En environnement cloud (AWS, GCP, Azure), le type LoadBalancer provisionne automatiquement un load balancer externe. Sur bare-metal, des solutions comme MetalLB remplissent ce role.

apiVersion: v1
kind: Service
metadata:
  name: api-public
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - port: 443
      targetPort: 8080

Concrètement, cela signifie que chaque Service de type LoadBalancer crée un load balancer dédié, ce qui peut devenir couteux en cloud. C''est pourquoi on privilégie un Ingress controller unique devant plusieurs Services.

L''Ingress est une ressource Kubernetes qui définit des règles de routage HTTP/HTTPS vers vos Services. Mais un Ingress sans controller, c''est comme un fichier de configuration sans le logiciel qui le lit.

Nginx Ingress Controller

Le plus déployé. Il gère le routage basé sur les hostnames et les paths, la terminaison TLS, le rate limiting, et s''intègre avec cert-manager pour les certificats Let''s Encrypt.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: 'true'
    nginx.ingress.kubernetes.io/rate-limit: '10'
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-backend
                port:
                  number: 80

Traefik : configuration dynamique

Traefik se distingue par sa découverte automatique des services et son support natif des CRDs Kubernetes (IngressRoute). Sa configuration est souvent plus concise et son dashboard intégré facilite le debugging.

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: api-route
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`api.example.com`)
      kind: Rule
      services:
        - name: api-backend
          port: 80
  tls:
    certResolver: letsencrypt

Pour bien comprendre ce mécanisme : Nginx est un proxy inverse classique reconfiguré dynamiquement par son controller. Traefik est un reverse proxy cloud-native concu pour la découverte de services. Les deux sont solides en production ; Traefik est souvent préféré dans les stacks modernes pour sa simplicité de configuration.

Quand le réseau ne fonctionne pas, voici une approche méthodique en quatre étapes.

1. Vérifier la connectivité Pod-to-Pod

# Lancer un Pod de debug
kubectl run debug --image=nicolaka/netshoot -it --rm -- bash

# Tester la résolution DNS
nslookup api-backend.default.svc.cluster.local

# Tester la connectivité
curl -v http://api-backend.default.svc.cluster.local

2. Inspecter les endpoints

# Vérifier que le Service a bien des endpoints
kubectl get endpoints api-backend

# Si vide : le selector ne matche aucun Pod
kubectl get pods -l app=api -o wide

3. Vérifier les NetworkPolicies

# Lister les policies dans le namespace
kubectl get networkpolicies -n production

# Décrire une policy spécifique
kubectl describe networkpolicy deny-all-ingress -n production

4. Utiliser Hubble (si Cilium)

# Observer les flux en temps réel
hubble observe --namespace production

# Filtrer les drops
hubble observe --verdict DROPPED --namespace production

Hubble est un atout majeur de Cilium pour le debugging : il montre exactement quel paquet est bloqué, par quelle policy, à quel niveau (L3, L4, L7).

Le réseau Kubernetes repose sur trois couches : le CNI pour la connectivité Pod-to-Pod, les Services pour l''abstraction d''accès, et l''Ingress pour l''exposition externe. En 2026, Cilium s''impose comme le CNI de référence grace à eBPF, mais Calico reste un choix solide pour les environnements existants. Coté Ingress, Nginx et Traefik couvrent la majorité des besoins, le choix dépendant surtout de votre stack existante.

Le plus important : investissez du temps dans la compréhension du modèle réseau avant de déployer. Un CNI mal choisi ou mal configuré, c''est des heures de debugging évitables.

• Kubernetes Services Documentation
• Kubernetes Ingress Documentation
• Comparing Kubernetes CNI Plugins: Calico, Cilium, Flannel
• Cilium vs Calico vs Flannel (Civo)
• Calico vs Cilium: 9 Key Differences (Tigera)