Identifier les options de plug-in

  • 5 minutes

Un plug-in réseau est requis par un cluster AKS afin de faciliter la communication de pod à pod, de pod à nœud et dans certains cas, de nœud à pod. Deux modèles réseau sont disponibles sur AKS : kubenet et Azure CNI. Il existe d’autres évolutions d’Azure CNI, notamment Superposition Azure CNI, Azure CNI pour l’allocation d’adresses IP dynamiques et Azure CNI avec Cilium. Chacun de ces modèles a son propre ensemble de fonctionnalités et de limitations.

Kubenet

Par défaut, les clusters AKS utilisent kubenet. Avec kubenet, un réseau virtuel, un sous-réseau et une table de routage Azure sont créés automatiquement quand le cluster est déployé, mais des ressources réseau existantes peuvent être fournies. Avec kubenet :

  • Les nœuds reçoivent une adresse IP du sous-réseau du réseau virtuel Azure.
  • Les pods reçoivent une adresse IP d’un espace d’adressage logiquement différent du sous-réseau du pool de nœuds.
  • La traduction d’adresses réseau (NAT) est ensuite configurée pour que les pods puissent atteindre les ressources situées sur le réseau virtuel Azure.
  • L’adresse IP source du trafic est traduite en adresse IP principale du nœud.

Les pods ne peuvent pas communiquer directement entre eux. Au lieu de cela, les routes définies par l’utilisateur (UDR) et le transfert IP sont utilisés pour la connectivité entre les pods sur les nœuds. Par défaut, la configuration des itinéraires définis par l’utilisateur et des transferts IP est créée et gérée par le service AKS, mais vous avez la possibilité d’utiliser votre propre table de routage pour la gestion des itinéraires personnalisés.

Si votre sous-réseau personnalisé ne contient pas de table de route, AKS en crée une pour vous et y ajoute des règles tout au long du cycle de vie du cluster. Si votre sous-réseau personnalisé contient une table de route lorsque vous créez votre cluster, AKS la reconnaît lors des opérations de cluster et ajoute/met à jour les règles en conséquence pour les opérations du fournisseur de cloud.

Diagramme du modèle réseau kubenet avec un cluster AKS. Deux nœuds sont affichés à l’aide de kubenet pour le trafic d’itinéraire/NAT sur le sous-réseau de nœud du réseau virtuel.

Azure CNI

Le plug-in Azure CNI est une option réseau plus complexe avec une plus grande configurabilité et davantage de fonctionnalités prises en charge. Avec Azure CNI, un sous-réseau préexistant et un réseau virtuel sont nécessaires pour utiliser les clusters. L’utilisation des fonctionnalités d’Azure CNI nécessite une planification supplémentaire. La taille de votre réseau virtuel et de son sous-réseau doit être suffisante pour prendre en charge le nombre de pods que vous envisagez d’exécuter, ainsi que le nombre de nœuds du cluster. Avec Azure CNI :

  • Les nœuds reçoivent un espace d’adressage IP du sous-réseau du réseau virtuel Azure.
  • Chaque pod reçoit une adresse IP dans le sous-réseau du pool de nœuds, et peut communiquer directement avec d’autres pods et d’autres services.
  • La taille de vos clusters peut être identique à la plage d’adresses IP que vous spécifiez. Toutefois, la plage d’adresses IP doit être planifiée à l’avance, et toutes les adresses IP sont consommées par les nœuds AKS en fonction du nombre maximal de pods qu’ils peuvent prendre en charge.

Avec Azure CNI, un sous-réseau préexistant et un réseau virtuel sont nécessaires pour pouvoir utiliser le plug-in réseau Azure CNI. Ce sous-réseau et ce réseau virtuel peuvent être créés au moment de la création du cluster AKS.

Diagramme du modèle réseau Azure CNI. Les pods sont affichés en communiquant par le biais d’un pont. Chaque pod a une adresse IP unique affectée à partir du sous-réseau de nœud du réseau virtuel.

Superposition Azure CNI

La Superposition Azure CNI représente une évolution d’Azure CNI, qui répond aux défis de scalabilité et de planification liés à l’affectation d’adresses IP de réseau virtuel à des pods. Azure CNI Overlay affecte des adresses IP CIDR privées aux pods. Les adresses IP privées sont distinctes du réseau virtuel et peuvent être réutilisées sur plusieurs clusters. La superposition Azure CNI peut être mise à l’échelle au-delà de la limite de 400 nœuds appliquée dans les clusters Kubenet. La superposition Azure CNI est l’option recommandée pour la plupart des clusters.

Azure CNI avec Cilium

Azure CNI avec Cilium utilise Cilium pour fournir une mise en réseau, une observabilité et une application de stratégie réseau hautes performances. Il s’intègre en mode natif à la superposition Azure CNI pour la gestion évolutive des adresses IP (IPAM).

En outre, Cilium applique les stratégies réseau par défaut, sans nécessiter de moteur de stratégie réseau distinct. Azure CNI avec Cilium peut être mis à l’échelle au-delà des limites d’Azure Network Policy Manager de 250 nœuds / 20-K pods avec des programmes eBPF et d’une structure d’objets API plus efficace.

Azure CNI avec Cilium est l’option recommandée pour les clusters qui nécessitent une application de stratégie réseau.

Utiliser un plug-in personnalisé

Pour les clients qui envisagent d’utiliser une configuration réseau personnalisée, il n’existe aucune configuration requise pour les plug-ins réseau. Vous pouvez choisir parmi les fournisseurs CNI tels que Cilium ou Flannel. Toutefois, il est préférable de se tourner vers leur propre documentation, car elle n’est pas couverte par Microsoft.