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.
Kubernetes utilise des plug-ins CNI (Container Networking Interface) pour gérer la mise en réseau dans les clusters Kubernetes. Les CNIs sont responsables de l’attribution d’adresses IP à des pods, du routage réseau entre les pods, du routage Kubernetes Service, etc.
Azure Kubernetes Service (AKS) utilise deux modèles de mise en réseau principaux : le réseau de superposition et le réseau plat .
Superposition de réseaux :
- Conservez l’espace d’adressage IP du réseau virtuel à l’aide de plages CIDR séparées logiquement pour les pods.
- Prise en charge maximale de la mise à l’échelle du cluster.
- Gestion des adresses IP simples.
Réseaux plats :
- Les pods obtiennent une connectivité complète de réseau virtuel et peuvent être directement accessibles via leur adresse IP privée à partir de réseaux connectés.
- Nécessite un espace d’adressage IP de réseau virtuel volumineux et nonfragmenté.
Lorsque vous choisissez un modèle de mise en réseau, tenez compte des cas d’usage pour chaque plug-in CNI et du type de modèle réseau qu’il utilise :
| Plug-in CNI | Modèle de mise en réseau | Points forts de cas d’usage |
|---|---|---|
| Superposition Azure CNI | Superposer | - Meilleur pour la conservation des adresses IP de réseau virtuel - Nombre maximal de nœuds pris en charge par le serveur d’API + 250 pods par nœud - Configuration plus simple - Aucun accès IP de pod externe direct |
| Sous-réseau de pod Azure CNI | Plat | - Accès direct aux pods externes - Modes de prise en charge efficace de l’adresse IP du réseau virtuel ou de la prise en charge des grandes échelles de cluster |
| Sous-réseau de nœud Azure CNI | Plat | - Accès direct aux pods externes - Configuration plus simple - Échelle limitée - Utilisation inefficace des adresses IP de réseau virtuel |
Lors de l’approvisionnement d’Application Gateway pour conteneurs dans un cluster sur lequel la superposition CNI ou CNI est activée, Application Gateway pour conteneurs détecte automatiquement la configuration réseau prévue. Aucune modification n’est nécessaire dans la configuration de l’API passerelle ou d’entrée pour spécifier la superposition CNI ou CNI.
Superposition CNI et Application Gateway pour conteneurs
Un domaine de routage distinct est créé dans la pile Azure Networking pour l’espace CIDR privé du pod, ce qui crée un réseau Overlay pour la communication directe entre les pods. Quand Application Gateway pour conteneurs est provisionné, le domaine de routage de superposition est étendu à l’infrastructure Application Gateway pour conteneurs, ce qui permet le proxy des requêtes d’Application Gateway pour conteneurs directement vers les pods.
Application Gateway pour conteneurs prend en charge les stratégies réseau Azure, Calico et Cilium Kubernetes s’exécutant dans le cluster.
Limites
- Contrôleur ALB : Vous devez exécuter la version 1.7.9 ou ultérieure pour tirer parti de la superposition CNI.
- Taille du sous-réseau : le sous-réseau Application Gateway pour conteneurs doit être un préfixe /24 ; un seul déploiement est pris en charge par sous-réseau. Un préfixe plus grand ou plus petit n’est pas pris en charge.
- Peering de réseaux virtuels régionaux : Application Gateway pour conteneurs déployés dans un réseau virtuel dans la région A et les nœuds de cluster AKS d’un réseau virtuel dans la région A ne sont pas pris en charge.
- Peering de réseau virtuel global : Application Gateway pour conteneurs déployés dans une région A et les nœuds de cluster AKS dans une région B ne sont pas pris en charge.
CNI et Application Gateway pour conteneurs
Application Gateway pour conteneurs prend en charge différents déploiements d’Azure CNI exécutés dans votre cluster Kubernetes.
- Azure CNI pour l’allocation d’adresses IP dynamiques
- Azure CNI pour l’allocation de blocs statiques
Dans les deux cas, Application Gateway pour conteneurs prend en charge les stratégies réseau Azure, Calico et Cilium Kubernetes s’exécutant dans le cluster.
Kubenet et Application Gateway pour conteneurs
Kubenet n’est pas pris en charge par Application Gateway pour conteneurs. Si vous utilisez Kubenet, nous vous recommandons de procéder à la mise à niveau vers la superposition CNI.
Questions fréquentes (FAQ)
Q : Puis-je mettre à niveau un cluster existant avec Application Gateway pour conteneurs de CNI vers CNI Overlay ?
R : Oui, la mise à niveau du cluster AKS de CNI vers CNI Overlay et Application Gateway pour conteneurs détecte automatiquement la modification. Il est recommandé de planifier la mise à niveau pendant une fenêtre de maintenance, car une interruption du trafic peut se produire. La mise à niveau du contrôleur peut prendre quelques minutes après la mise à niveau du cluster pour détecter et configurer la prise en charge de CNI Overlay.
Avertissement
Vérifiez que le sous-réseau Application Gateway pour conteneurs est un /24 avant la mise à niveau. La mise à niveau de CNI vers la superposition CNI avec un sous-réseau plus grand (/23 ou plus) entraîne une panne et nécessite que le sous-réseau Application Gateway pour conteneurs soit recréé avec une taille de sous-réseau /24.
Q : Puis-je mettre à niveau un cluster existant avec Kubenet vers la superposition CNI ?
R : Toutefois, l’installation d’Application Gateway pour conteneurs sur un cluster avec Kubenet n’est pas prise en charge. Installez Application Gateway pour conteneurs après la mise à niveau vers la superposition CNI.