1. INTERVENANTS

DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨

2. PROBLÉMATIQUE

Une fois les bases posées (choix du CNI, exposition maîtrisée), un autre défi arrive très vite :
le dimensionnement réseau.

Contrairement à ce qu’on pourrait croire, ce n’est pas une étape “one shot”.
→ C’est un choix structurant, qui peut bloquer tes déploiements futurs, impacter la scalabilité, ou t’obliger à reconstruire ton cluster.

🧠 L’espace IP, les subnets, la segmentation des ressources et la gestion fine des flux internes doivent être anticipés dès la phase de design.
Et dans un environnement AKS, ça demande un vrai travail d’architecte réseau — surtout si tu vises une architecture multi-pools, sécurisée et évolutive.

Quelques pièges classiques :

• Sous-réseau trop petit, bloquant les déploiements à cause du manque d’IPs disponibles
• Pas de séparation entre nodes système et applicatifs, ce qui complexifie la supervision et la sécurité
• Pas de logique claire de segmentation : tout est dans le même subnet = gestion et évolutivité compliquées
• Pas ou peu de Network Policies mises en place, laissant tous les pods se parler librement…

📌 À retenir :
Le réseau AKS ne se limite pas à “avoir un VNET qui tourne”.
Il faut anticiper la croissance, isoler les composants critiques, et mettre en place une gouvernance réseau claire, dès le départ.

3. DIMENSIONNEMENT DU RÉSEAU

Hypothèses

La gestion des adresses IP dans AKS est un élément crucial pour éviter les pénuries et garantir la scalabilité du cluster.

Voici les principaux paramètres pris en compte :

• Nombre maximum de nodes : 12
• Nombre d’IP nécessaires pour les nodes : 12
• Nombre maximum de pods par node : 30
• Nombre total de pods : 360
• Nombre total d’IP pour les pods : 360
• maxSurge configuré à 33%
• Ajout de quatre nœuds pendant les phases d’upgrade

Formule de calcul

AKS réserve des adresses IP par anticipation pour les pods et les nodes, ce qui peut vite consommer l’espace d’adressage. La formule de calcul est la suivante :

(nodes + nodes upgrade) + ((nodes + nodes upgrade) * pods par node)

Soit ici : (12 + 4) + ((12 + 4) * 30) = 376 IPs

Taille du subnet AKS

Azure réserve 5 adresses IP par subnet. Il faut prévoir large.

Exemple :

• CIDR /23 = 512 adresses – 5 réservées = 507 IPs utilisables

💡 Bonnes pratiques :

• Prévois large dès le début
• Élargir un subnet ensuite peut nécessiter une reconstruction complète du cluster
• Laisse de la marge pour le scaling et les mises à jour

Besoins additionnels

IPs consommées par les pods système :

• CoreDNS
• Metrics Server
• Kube Proxy
• Autres add-ons internes

Subnets dédiés à certains services :

Certains services nécessitent leur propre subnet pour des raisons d’optimisation et de sécurité :

• Azure Virtual Network Integration : Communication avec d’autres services Azure.
• Azure Application Gateway for Containers : requis pour gérer le trafic entrant vers AKS
• Azure API Management (APIM) : en mode VNET, nécessite un subnet dédié pour l’exposer en privé.

Impact du choix du CNI

Segmentation réseau : pourquoi et comment ?

L’optimisation des subnets est cruciale pour garantir une bonne segmentation réseau, éviter les conflits d’adressage IP et assurer une meilleure isolation des composants AKS

• Pour assurer la segmentation :

1️⃣ Cas n°1 – Isolation node pools

• Pools systèmes séparés des pools utilisateurs
• Meilleure sécurité et observabilité

2️⃣ Cas n°2 – Load Balancer interne

• Sur un subnet dédié
• Empêche l’exposition involontaire des services internes

3️⃣Cas n°3 – Application Gateway for Containers

• Besoin d’un subnet propre pour assurer haute disponibilité
• Nécessaire pour la gestion avancée des flux Ingress

4. SEGMENTATION RESEAU

Azure Network Policy Manager

L’implémentation de politiques réseau est cruciale pour assurer une segmentation fine et renforcer la sécurité des communications entre pods et services.

• Du filtrage réseau mais exprimé en YAML

• On s’exprime sur un scope : Le Namespace
• Pour un ensemble de Pods identifiés par un label particulier
• Pour filtrer des flux entrants (Ingress) voire des flux sortants (Egress)
• Flux que l’on peut identifier en IP ou via des labels

• Filtrage mis en œuvre au niveau du namespace

• Appliqué dans le cadre du déploiement de l’application
• Imposé par le Cluster Admin (RBAC)
• Enforce via policy YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: myapp
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 80

👉 Cela autorise uniquement les pods frontend à parler aux backend sur le port 80.

PROCHAIN ARTICLE

👉 Dans le prochain article, on change de couche pour aborder un sujet tout aussi stratégique : la gestion des identités et des accès dans AKS 🛡️

Au programme :

• Intégration d’Azure AD dans les clusters
• Mise en place de RBAC Kubernetes propre et maintenable
• Sécurisation des credentials et bonnes pratiques pour l’authentification

📎 Pour aller plus loin (docs Microsoft) :

• Plan IP addressing for your AKS cluster
• Best practices for network configuration in AKS
• Use network policies to control traffic flow
• Virtual network and subnet planning
• Azure Network Policy Manager