Réseau, ingress et stockage persistant
Comprendre le modèle réseau plat de Kubernetes, le rôle de l'Ingress et les options de stockage persistant.
À retenir
- Le CNI implémente le modèle réseau plat de Kubernetes et conditionne le support des NetworkPolicy.
- L'Ingress permet un routage HTTP/HTTPS mutualisé mais nécessite un contrôleur Ingress installé.
- PersistentVolumeClaim et StorageClass découplent la demande de stockage de son implémentation via CSI.
- Le mode d'accès (RWO/RWX) doit être compatible avec le backend de stockage choisi.
Le modèle réseau Kubernetes
Kubernetes impose un modèle réseau simple en apparence : chaque pod reçoit une adresse IP unique et tous les pods peuvent se joindre directement sans NAT, quel que soit le nœud qui les héberge. Cette contrainte est implémentée par un plugin CNI (Container Network Interface) — Calico, Cilium ou Flannel étant parmi les plus répandus — qui gère le routage effectif entre nœuds, parfois via un réseau overlay (VXLAN) ou du routage natif (BGP).
Point clé
le choix du CNI conditionne directement les fonctionnalités de sécurité réseau disponibles ; seuls certains plugins (Cilium, Calico) implémentent les NetworkPolicy Kubernetes qui permettent de restreindre les flux entre pods.
De l'exposition interne à l'exposition externe
| Objet | Portée | Cas d'usage |
|---|---|---|
| ClusterIP | Interne au cluster | Communication service-à-service |
| NodePort | Port statique sur chaque nœud | Tests, environnements simples |
| LoadBalancer | Équilibreur externe du cloud provider | Exposition publique directe |
| Ingress | Couche 7 (HTTP/HTTPS) | Routage par nom d'hôte et chemin, TLS |
Un contrôleur Ingress (NGINX Ingress Controller, Traefik) lit les objets Ingress déclarés et configure un reverse proxy en conséquence, ce qui évite de provisionner un LoadBalancer cloud coûteux par service exposé.
Attention
l'objet Ingress seul ne fait rien : sans contrôleur Ingress installé dans le cluster, les règles déclarées restent inertes et aucun trafic n'est routé.
Stockage persistant
Les pods sont éphémères par nature ; tout ce qui est écrit sur le système de fichiers d'un conteneur disparaît à son redémarrage. Kubernetes découple la demande de stockage (PersistentVolumeClaim) de sa fourniture (PersistentVolume), via des StorageClass qui définissent le type de stockage sous-jacent (SSD réseau, NFS, stockage bloc cloud) et permettent le provisionnement dynamique.
- Bloc (RWO — ReadWriteOnce) : monté par un seul nœud à la fois, adapté aux bases de données.
- Fichier partagé (RWX — ReadWriteMany) : plusieurs pods peuvent monter le même volume, utile pour du contenu partagé.
- CSI (Container Storage Interface) : standard permettant à Kubernetes de piloter n'importe quel backend de stockage via des drivers tiers.
Sur le terrain
un pod bloqué en ContainerCreating avec un message lié au volume est très souvent dû à un PersistentVolumeClaim en attente parce que le mode d'accès demandé (RWX) n'est pas supporté par la StorageClass par défaut du cluster.
Astuce
pour les charges avec état critique, préférez un opérateur Kubernetes dédié (ex. pour PostgreSQL ou Kafka) plutôt qu'un StatefulSet manuel : il encapsule les procédures de sauvegarde, de bascule et de mise à jour propres au moteur.