Vue d’ensemble de la mise en réseau CNI dans Azure Kubernetes Service (AKS)

Kubernetes utilise des plug-ins CNI (Container Networking Interface) pour gérer la mise en réseau dans les clusters Kubernetes. Les plug-ins CNI gèrent l’attribution d’adresses IP aux pods, le routage du trafic réseau entre les pods, le routage du trafic du service Kubernetes, etc.

Azure Kubernetes Service (AKS) fournit plusieurs configurations réseau CNI que vous pouvez utiliser dans vos clusters, en fonction de vos besoins en réseau. Lorsque vous planifiez la mise en réseau des pods, vous choisissez une option de gestion des adresses IP (IPAM) et une technologie de routage et de transport pour le plan de données réseau.

Modèles de mise en réseau dans AKS

Le choix d’une option IPAM pour votre cluster AKS dépend en grande partie du modèle de mise en réseau adapté à vos besoins. Chaque modèle présente ses propres avantages et inconvénients que vous devez prendre en compte lors de la planification de votre cluster AKS.

AKS utilise deux modèles de mise en réseau principaux :

• Réseau de superposition :

  • Préserve l’espace d’adresses IP des réseaux virtuels (VNets) grâce à l’utilisation de plages CIDR logiquement distinctes pour les pods.
  • Fournit un support maximal de la mise à l’échelle du cluster.
  • Fournit une gestion simple des adresses IP.

• Réseau plat :

  • Fournit une connectivité complète au réseau virtuel pour les pods. Les pods peuvent être directement accessibles via leur adresse IP privée à partir de réseaux connectés.
  • Nécessite un espace d’adressage IP volumineux et non fragmenté pour les réseaux virtuels.

Les deux modèles réseau prennent en charge plusieurs options IPAM. Les principales différences entre les modèles sont la façon dont vous affectez des adresses IP de pod et la façon dont le trafic quitte le cluster.

Pour Azure CNI, l’option IPAM est distincte du plan de données réseau. Vous pouvez utiliser le plan de données CNI Azure optimisé par Cilium avec Azure superposition CNI, Azure sous-réseau de pod CNI ou Azure sous-réseau de nœud CNI. Pour plus d’informations sur les options IPAM et de plan de données, consultez Planifier la mise en réseau des pods pour AKS.

Réseaux superposés

La mise en réseau de superposition dans AKS affecte des adresses IP de pod à partir d’un CIDR de pod distinct du sous-réseau de nœud dans le réseau virtuel. Cette configuration permet une scalabilité plus simple et souvent meilleure que le modèle de réseau plat.

Dans les réseaux superposés, les pods communiquent entre eux directement. Le trafic qui quitte le cluster fait l'objet d'une traduction d'adresse réseau source (SNAT) vers l'adresse IP du nœud. Le trafic IP des pods entrants est acheminé via un service, tel qu’un équilibreur de charge. L’adresse IP du pod est alors « masquée » derrière l’adresse IP du nœud. Cette approche réduit le nombre d’adresses IP requises pour les réseaux virtuels de vos clusters.

Pour la mise en réseau de superposition, AKS fournit Azure superposition CNI. Utilisez cette option IPAM pour la plupart des scénarios.

Réseaux à plat

Contrairement à un réseau de superposition, un modèle de réseau plat dans AKS affecte des adresses IP aux pods à partir d’un sous-réseau dans le même réseau virtuel Azure que les nœuds AKS. Pour le trafic réseau privé, l’adresse IP source qu’une destination voit dépend de l’option IPAM. Azure sous-réseau de pod CNI conserve l’adresse IP du pod sur les réseaux virtuels connectés. Avec Azure sous-réseau de nœud CNI, les destinations du réseau virtuel de cluster voient l’adresse IP du pod, mais les destinations en dehors du réseau virtuel du cluster voient l’adresse IP du nœud. Lorsque la sortie Internet est activée, la méthode sortante configurée du cluster détermine l’adresse IP source publique que les destinations Internet voient.

AKS fournit deux options Azure IPAM CNI pour la mise en réseau plate :

• Azure sous-réseau de pod CNI, l’option IPAM recommandée pour les scénarios de mise en réseau plat.
• Sous-réseau de nœud Azure CNI, un modèle CNI ancien pour les réseaux plats. En général, nous vous recommandons de l’utiliser uniquement si vous avez besoin d’un réseau virtuel managé pour votre cluster.

Choisir une option IPAM pour AKS

Lorsque vous choisissez une option IPAM, tenez compte de plusieurs facteurs. Chaque modèle de mise en réseau présente ses propres avantages et inconvénients. Le meilleur choix pour votre cluster dépend de vos besoins spécifiques.

Comparaison des cas d’usage

Comparaison des fonctionnalités

Étendue du support entre des modèles de réseaux

Selon l’option IPAM que vous utilisez, vous pouvez déployer les ressources de réseau virtuel pour votre cluster de l’une des manières suivantes :

• La plateforme Azure peut créer et configurer automatiquement les ressources de réseau virtuel lorsque vous créez un cluster AKS.
• Vous pouvez créer et configurer manuellement les ressources de réseau virtuel et joindre à ces ressources lorsque vous créez votre cluster AKS.

Bien que des fonctionnalités telles que les points de terminaison de service ou les UDR soient prises en charge, les stratégies de support pour AKS définissent les modifications que vous pouvez apporter. Voici un exemple :

• Si vous créez manuellement les ressources de réseau virtuel pour un cluster AKS, une prise en charge est assurée lorsque vous configurez vos propres UDR ou points de terminaison de service.
• Si la plateforme Azure crée automatiquement les ressources de réseau virtuel pour votre cluster AKS, vous ne pouvez pas modifier manuellement ces ressources managées par AKS pour configurer vos propres UDR ou points de terminaison de service.

Conditions préalables à la mise en réseau AKS CNI

Lorsque vous planifiez votre configuration réseau pour AKS, gardez à l’esprit ces exigences et considérations :

• Sauf si vous utilisez un cluster isolé de réseau, le réseau virtuel du cluster AKS doit autoriser la connectivité Internet sortante aux points de terminaison requis. Les clusters isolés réseau peuvent démarrer sans connectivité Internet sortante.

• Les plages d’adresses AKS ont les restrictions suivantes :

  Plage CIDR réservée	S’applique à	Pathologie
  169.254.0.0/16	Plages d’adresses de réseau virtuel Kubernetes service, pod et cluster	Tous les clusters AKS
  192.0.2.0/24	Plages d’adresses de réseau virtuel Kubernetes service, pod et cluster	Tous les clusters AKS
  172.30.0.0/16	Plages d’adresses de réseau virtuel Kubernetes service, pod et cluster	Tous les clusters AKS
  172.31.0.0/16	Plages d’adresses de réseau virtuel Kubernetes service, pod et cluster	Tous les clusters AKS

  AKS rejette les CIDR de pod qui chevauchent une plage réservée lors de la création ou de la mise à jour du cluster. Par exemple, 172.16.0.0/12 n’est pas valide, car la plage inclut 172.30.0.0/16 et 172.31.0.0/16.

• Dans les scénarios où vous apportez votre propre réseau virtuel, l’identité de cluster utilisée par le cluster AKS doit avoir au moins des autorisations Contributeur réseau sur le sous-réseau au sein de votre réseau virtuel.

• Si vous définissez un rôle personnalisé au lieu d’utiliser le rôle Contributeur réseau intégré, incluez les autorisations suivantes :

  Autorisation	Quand cela est nécessaire
  Microsoft.Network/virtualNetworks/subnets/join/action	Toujours lors de l’utilisation d’un rôle personnalisé
  Microsoft.Authorization/roleAssignments/write	Toujours lors de l’utilisation d’un rôle personnalisé
  Microsoft.Network/virtualNetworks/subnets/read	Uniquement lors de la définition de vos propres sous-réseaux et CIDR

• Le sous-réseau affecté au pool de nœuds AKS ne peut pas être un sous-réseau délégué.

• AKS n’applique pas de groupes de sécurité réseau (NSG) à son sous-réseau et ne modifie aucun des groupes de sécurité réseau associés à ce sous-réseau. Si vous fournissez votre propre sous-réseau et ajoutez des groupes de sécurité réseau associés à ce sous-réseau, vous devez vous assurer que les règles de sécurité dans les groupes de sécurité réseau autorisent le trafic dans la plage CIDR du nœud. Avec Azure superposition CNI, si une règle de refus NSG affecte le trafic CIDR des pods, vous devez également autoriser le trafic du CIDR du nœud vers le CIDR du pod et du CIDR de pod vers le CIDR de pod sur tous les ports et protocoles. Pour plus d’informations, consultez Groupes de sécurité réseau avec Azure superposition CNI.

• Le Container Network Service (CNS) est un service local aux nœuds dans le réseau CNI d’Azure Kubernetes Service, qui alloue, suit et configure le réseau pour les pods. Ce composant envoie par défaut des données de télémétrie (métriques et journaux) en dehors du cluster vers un point de terminaison Application Insights géré par Microsoft afin de permettre un dépannage plus rapide de tout problème d’attribution d’adresses IP pour la mise en réseau des pods.

Contenu connexe

• Superposition Azure CNI
• Sous-réseau de pods Azure CNI
• Options CNI héritées
• Planification d’adresses IP pour vos clusters