Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Choisissez une configuration de mise en réseau de pods selon que les pods ont besoin d’un accès IP direct à partir de réseaux connectés et de vos exigences d’échelle d’adresse IP.
Avez-vous besoin d'un accès direct à l'IP du pod ?
La mise en réseau des pods contrôle la façon dont les pods obtiennent des adresses IP et définissent la façon dont les pods communiquent entre eux, les nœuds de cluster et les destinations en dehors du cluster. Kubernetes implémente la mise en réseau des pods via un plug-in CNI (Container Network Interface), qui gère les adresses IP de pod et la connectivité réseau.
Lors de la configuration de la mise en réseau des pods, vous devez planifier la gestion des adresses IP (IPAM) et le routage et le transport (plan de données).
Si vos charges de travail nécessitent que les pods soient accessibles par adresse IP privée à partir de réseaux connectés au réseau virtuel du cluster Azure Kubernetes Service (AKS), utilisez un modèle de mise en réseau plat. Sinon, utilisez Azure CNI Overlay.
Options de gestion des adresses IP (IPAM)
Lors de la configuration d’IPAM, vous pouvez choisir entre un modèle de mise en réseau de superposition avec superposition Azure CNI et un modèle de mise en réseau plat avec un sous-réseau de pod Azure CNI ou un sous-réseau de nœud Azure CNI :
Le tableau suivant compare les options IPAM disponibles pour la mise en réseau des pods AKS, notamment leurs principales fonctionnalités et limites d’échelle.
| Options IPAM | Diagramme des composants réseau | Caractéristiques et fonctionnalités |
|---|---|---|
| Modèle de mise en réseau par surcouche (avec surcouche Azure CNI) |
|
• Les adresses IP de pod proviennent d’une plage de superposition qui ne fait pas partie de l’espace du réseau virtuel. • Mise en réseau hautement évolutive, avec jusqu’à 5 000 nœuds et 200 000 pods par cluster. Les limites du nœud, les limites de pods par nœud et les limites globales de pods sont indépendantes. • L’espace d’adressage overlay des pods peut être réutilisé dans des clusters indépendants. La plage CIDR des pods ne doit pas se chevaucher avec les réseaux directement connectés, notamment les réseaux virtuels appairés, les réseaux connectés via ExpressRoute ou un VPN, ainsi que d’autres routes exposant l’espace d’adressage privé. • Prise en charge de double pile (IPv4/IPv6). • Les pods ne sont pas accessibles directement à partir de l’extérieur du cluster. |
| Modèle de mise en réseau fixe (avec sous-réseau de pods ou sous-réseau de nœuds Azure CNI) |
|
• Les adresses IP de nœud et de pod proviennent de l’espace de réseau virtuel. • Les pods sont accessibles par leurs adresses IP privées à partir de réseaux connectés. Azure CNI Pod Subnet préserve l’adresse IP source du pod sur les réseaux virtuels connectés, tandis que les destinations situées en dehors du réseau virtuel du cluster voient l’adresse IP source du nœud avec Azure CNI Node Subnet. • Les options de sous-réseau de pod Azure CNI incluent l’allocation IP dynamique pour l’efficacité ou l’allocation de blocs statiques pour la mise à l’échelle. |
Considérations relatives aux options de modèle de mise en réseau plat
Gardez à l’esprit les considérations suivantes lors de la décision entre le sous-réseau de pod Azure CNI avec l’allocation IP dynamique, le sous-réseau de pod Azure CNI avec l’allocation de bloc statique et le sous-réseau de nœud Azure CNI :
| Option Modèle de mise en réseau plat | Considérations |
|---|---|
| Sous-réseau Azure CNI pour les pods avec allocation IP dynamique | • Nécessite des sous-réseaux distincts pour les nœuds et les pods, que vous pouvez dimensionner et faire évoluer indépendamment. • Alloue des adresses IP de pod aux nœuds du sous-réseau de pods par lots de 16. • Soumis aux limites d’adresses IP privées configurées par le réseau virtuel. |
| Sous-réseau de pod Azure CNI avec allocation de bloc statique | • Nécessite une planification minutieuse, car vous devez allouer une plage spécifique d’adresses IP pour vos pods et vous assurer qu’elle ne chevauche pas d’autres sous-réseaux. • Peut obtenir jusqu’à 1 000 000 adresses IP. • Les adresses IP peuvent ne pas être utilisées aussi efficacement, ce qui pourrait entraîner une perte de temps. |
| Sous-réseau de Azure CNI Node | • Option héritée qui peut utiliser un réseau virtuel géré par AKS ou un réseau virtuel géré par le client et un sous-réseau. • Les nœuds et les pods partagent le sous-réseau de nœud. Vous devez donc planifier la capacité à l’avance pour les nœuds, les pods, la mise à l’échelle et les mises à niveau. • Soumis aux limites d’adresses IP privées configurées par le réseau virtuel. |
Options de routage et de transport (plan de données)
Lors de la configuration de votre plan de données, vous pouvez choisir entre Azure CNI optimisé par Cilium, Azure plan de données iptables et BYO CNI :
Le tableau suivant compare les options de plan de données disponibles pour la mise en réseau des pods AKS et leurs fonctionnalités clés.
| Options du plan de données | Caractéristiques et fonctionnalités |
|---|---|
| Azure CNI propulsé par Cilium | • Amélioration de la mise à l’échelle et des performances pour les pools de nœuds Linux. Les pools de nœuds Windows ne sont pas pris en charge. • Application de la stratégie réseau Cilium intégrée. • Le filtrage FQDN nécessite Advanced Container Networking Services ainsi que Kubernetes 1.29 ou une version ultérieure. |
| Azure iptables | • Utilisez Calico pour l’application de la stratégie réseau sous Windows. La prise en charge d’Azure Network Policy Manager (NPM) prend fin le 30 septembre 2026 pour Windows et le 30 septembre 2028 pour Linux. Les nouveaux abonnements ne peuvent plus activer Azure NPM. • Pour les clusters Linux, utilisez Azure CNI optimisé par Cilium au lieu de Azure NPM. • Prend en charge Kubernetes NetworkPolicy. |
| BYO CNI | • Aucun plug-in CNI managé installé : vous pouvez utiliser n’importe quelle option prenant en charge AKS. • Microsoft ne prend pas en charge les problèmes liés à CNI. |
Recommandations en matière de mise en réseau des pods AKS
Notre recommandation générale est d’utiliser la superposition Azure CNI. Si vous avez besoin d’un accès IP de pod direct à partir de réseaux connectés et avez des exigences d’efficacité ou d’échelle, envisagez d’utiliser Azure sous-réseau de pod CNI avec allocation d’adresses IP dynamiques ou Azure sous-réseau de pod CNI avec allocation de bloc statique. Azure CNI Node Subnet est une option héritée ; de manière générale, utilisez-la uniquement si vous avez besoin d’un réseau virtuel (VNet) géré par AKS pour votre cluster.