📚 Sommaire de la série
- Partie 1 : Bien poser les bases réseau d’AKS (CNI, exposition, architecture de départ)
- Partie 2 : Sécuriser et maîtriser l’exposition réseau (control plane, egress/ingress, Gateway API)
- Partie 3 : Dimensionnement, segmentation et bonnes pratiques (IPs, subnets, network policies)
1. INTERVENANTS
DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨
2. PROBLÉMATIQUE
Un écosystème vaste – Network
L’un des grands défis du réseau dans Kubernetes est la diversité des solutions disponibles.
Si l’on regarde le Landscape de la CNCF (Cloud Native Computing Foundation), on trouve une quantité impressionnante d’outils dédiés au réseau
Dès que l’on explore la section Cloud Native Network, on constate un vaste choix de solutions, allant des Containers Network Interfaces (CNI) aux stratégies d’exposition des services. Ce large éventail peut paraître intimidant, mais il est essentiel de comprendre les catégories principales avant de faire un choix
Beaucoup de solutions, mais comment choisir ?
- Kubernetes permet d’utiliser le CNI natif du cloud provider (ex: Azure CNI sur Azure, AWS CNI sur AWS) ou d’opter pour une solution indépendante
- Parmi les solutions populaires, on retrouve Cilium, Calico, et OVN-Kubernetes, qui sont agnostiques du cloud provider et adaptées aux environnements hybrides et multi-cloud.
- Si le besoin est simple et limité à un seul cluster, utiliser le CNI du cloud provider est souvent le choix le plus efficace.
- Si le besoin implique des architectures multi-cloud ou on-premise, des solutions comme Cilium ou Istio peuvent apporter une flexibilité supplémentaire.
- Certaines solutions comme Cilium et Istio sont aussi utilisées pour les environnements multi-clusters, facilitant l’interconnexion entre plusieurs déploiements.
3. CHOISIR UN CNI
Le choix du CNI (Container Network Interface) est un élément fondamental lors de la mise en place d’un cluster Kubernetes.
Il détermine la manière dont les pods communiquent entre eux et avec l’extérieur, influençant directement la gestion du réseau, la scalabilité et la sécurité du cluster.
Un bon choix de CNI doit prendre en compte l’architecture réseau existante, les contraintes d’adressage IP et les besoins en segmentation du trafic
3.1. KubeNet
Le modèle le plus simple
- 🟢Deux address spaces distincts nodes & pods
- 🟢Peu gourmand en IPs
- 🔵NAT entre les deux
Mais des limites
- 🔴 Limité à 400 nodes
- 🔴 Pas de support de Network Policies
- 🔴 Incompatible avec Windows / Virtual Nodes
| ⚠️ Remarque importante : Microsoft a annoncé que le réseau kubenet pour Azure Kubernetes Service (AKS) sera retiré le 31 mars 2028. |
3.2. Azure CNI Classic
Le modèle Azure intégré
- 🟢 Un address space unifié nodes & pods
Mais des contraintes
- 🔴 Très consommateur en IPs (1 pod = 1 IP VNET)
- 🔴 Besoin d’un subnet large
- 🔴 Planification complexe des nodes/pods
3.3. Azure CNI with Overlay
• Le meilleur des deux mondes
- 🟢 Address space distinct Nodes / Pods
- 🟢 Optimisation IP, pas de limite à 400 nodes
- 🔵 Moins de complexité que Bring Your Own CNI
Mais des contraintes
- 🔴 Pas Compatible avec les Windows Nodes Pools
3.4. Bring your own CNI
Azure CNI – Powered by Cilium
- 🟢 Flexible, hautement configurable
- 🔵 Combinaison de Azure CNI avec Cilium CNI (eBPF)
- 🔵 Large choix des fournisseurs de CNI
Mais des contraintes
- 🔴 Version limitée comparée à Bring your own CNI
- 🔴 La solution la plus configurable, mais implique de la maintenir
3.5 Arbre de décision
Le choix du Container Network Interface (CNI) est crucial car il impacte directement la gestion des adresses IP, la scalabilité et l’interopérabilité du cluster.
• Ce que l’on exclut d’emblée
- Bring-Your-Own CNI : Pas nécessaire ici, car aucun besoin exprimé.
- IPv6 (Dual Stack) : Possible sur Azure, mais non 100% compatible pour l’exposition publique.
• Les choix qui restent
- Azure CNI Overlay ✅ (Recommandé)
- Meilleur équilibre entre consommation d’IP et flexibilité.
- Convient aux clusters de grande taille.
- Azure CNI Dynamic ⚠️ (à envisager uniquement si Windows Nodes sont requis)
- Adapté aux architectures avec des besoins spécifiques en Windows Nodes.
PROCHAIN ARTICLE
👉 Dans la prochaine partie, on met les mains dans le cambouis 🔧 pour aborder un sujet aussi passionnant que critique : l’exposition réseau d’un cluster AKS.
On parlera de :
- l’exposition (trop) généreuse du Control Plane
- la gestion fine des flux Egress & Ingress
- et les meilleurs outils pour ça : Ingress Controllers, API Gateway et la fameuse Gateway API
Spoiler alert ⚠️ : on va parler de PrivateLink, NAT Gateway, et de comment éviter les galères d’IP publiques mal contrôlées… bref, du sérieux.
