CNI (Container Networking interfaces) héritées AKS

Dans Azure Kubernetes Service (AKS), bien que la superposition Azure CNI et le sous-réseau de pod Azure CNI sont recommandés pour la plupart des scénarios, les modèles de mise en réseau hérités tels que le sous-réseau de nœud Azure CNI et kubenet sont toujours disponibles et pris en charge. Ces modèles hérités offrent différentes approches de la gestion et de la mise en réseau des adresses IP de pod, chacune avec son propre ensemble de fonctionnalités et de considérations. Cet article fournit une vue d’ensemble de ces options de mise en réseau héritées, détaillant leurs prérequis, paramètres de déploiement et caractéristiques clés pour vous aider à comprendre leurs rôles et comment ils peuvent être utilisés efficacement dans vos clusters AKS.

Prérequis

Les conditions préalables suivantes sont requises pour le sous-réseau de nœud Azure CNI et kubenet :

• Le réseau virtuel du cluster AKS doit autoriser les connexions Internet sortantes.

• Les clusters AKS ne peuvent pas utiliser 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 ou 192.0.2.0/24 pour la plage d’adresses de service Kubernetes, la plage d’adresses de pod ou la plage d’adresses de réseau virtuel de cluster.

• L’identité de cluster utilisée par le cluster AKS doit au moins disposer des autorisations Contributeur de réseau sur le sous-réseau de votre réseau virtuel. Si vous souhaitez définir un rôle personnalisé au lieu d’utiliser le rôle Contributeur de réseau intégré, les autorisations suivantes sont nécessaires :

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read
  • Microsoft.Authorization/roleAssignments/write

• 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 les groupes de sécurité réseau (NSG) à son sous-réseau et ne modifie pas les NSG 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. Pour en savoir plus, reportez-vous aux groupes de sécurité réseau.

Remarque

Kubenet n’est pas disponible pour les conteneurs Windows Server. Pour utiliser des pools de nœuds Windows Server, vous devez utiliser Azure CNI.

Sous-réseau de nœud Azure CNI

Avec l’interface Azure Container Networking Interface (CNI), chaque pod reçoit une adresse IP du sous-réseau et est accessible directement. Les systèmes dans le même réseau virtuel que le cluster AKS voient l’adresse IP du pod comme l’adresse source pour tout trafic en provenance du pod. Les systèmes situés en dehors du réseau virtuel du cluster AKS voient l’adresse IP du nœud en tant qu’adresse source pour tout le trafic en provenance du pod. Ces adresses IP doivent être uniques dans votre espace réseau et doivent être planifiées à l’avance. Chaque nœud possède un paramètre de configuration pour le nombre maximal de pods qu’il prend en charge. Le nombre équivalent d’adresses IP par nœud est alors réservé à l’avance pour ce nœud. Cette approche nécessite davantage de planification. De plus, elle conduit souvent à l’épuisement des adresses IP ou à la nécessité de regénérer les clusters dans un sous-réseau plus vaste à mesure que vos demandes d’applications augmentent.

Avec le sous-réseau de nœud Azure CNI, chaque pod reçoit une adresse IP dans le sous-réseau IP et peut communiquer directement avec d’autres pods et 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. Les scénarios et fonctionnalités réseau avancés comme les nœuds virtuels ou les stratégies réseau (Azure ou Calico) sont pris en charge avec Azure CNI.

Paramètres de déploiement

Quand vous créez un cluster AKS, les paramètres suivants sont configurables pour les réseaux Azure CNI :

Réseau virtuel : réseau virtuel dans lequel vous souhaitez déployer le cluster Kubernetes. Vous pouvez créer un réseau virtuel ou utiliser un réseau virtuel existant. Si vous voulez utiliser un réseau virtuel existant, vérifiez qu’il se trouve au même emplacement et dans le même abonnement Azure que votre cluster Kubernetes. Pour plus d’informations sur les limites et quotas d’un réseau virtuel Azure, voir Abonnement Azure et limites, quotas et contraintes du service.

Sous-réseau : sous-réseau du réseau virtuel dans lequel vous souhaitez déployer le cluster. Vous pouvez ajouter de nouveaux sous-réseaux au réseau virtuel pendant le processus de création du cluster. Pour une connectivité hybride, la plage d’adresses ne doit pas chevaucher d’autres réseaux virtuels dans votre environnement.

Plug-in Réseau Azure : quand le plug-in Réseau Azure est utilisé, le service LoadBalancer interne avec le paramètre « externalTrafficPolicy=Local » n’est pas accessible à partir de machines virtuelles ayant une adresse IP dans clusterCIDR qui n’appartient pas au cluster AKS.

Plage d’adresses du service Kubernetes : ce paramètre est l’ensemble d’adresses IP virtuelles que Kubernetes attribue aux services internes dans votre cluster. Cette plage ne peut pas être mise à jour après la création de votre cluster. Vous pouvez utiliser n’importe quelle plage d’adresses privées répondant aux exigences suivantes :

• Ne peut pas figurer dans la plage d’adresses IP de réseau virtuel de votre cluster.
• Ne peut pas présenter de chevauchement avec d’autres réseaux virtuels avec lequel le réseau virtuel du cluster s’apparie.
• Ne doit pas chevaucher les adresses IP locales.
• Ne doit pas être dans les plages 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 ou 192.0.2.0/24.

Bien qu’il soit possible de spécifier une plage d’adresses de service au sein du même réseau virtuel que votre cluster, nous ne le recommandons pas. Les plages d’adresses IP qui se chevauchent peuvent entraîner un comportement imprévisible. Pour plus d’informations, visitez le FAQ. Pour plus d’informations sur les services Kubernetes, consultezServices dans la documentation de Kubernetes.

Adresse IP du service DNS Kubernetes :l’adresse IP du service DNS du cluster. Cette adresse doit se situer dans la plage d’adresses du service Kubernetes. N’utilisez pas la première adresse IP de votre plage d’adresses. La première adresse de votre plage de sous-réseaux est utilisée pour l’adresse kubernetes.default.svc.cluster.local.

Kubenet

Les clusters AKS utilisent kubenet et créent un réseau et un sous-réseau virtuels Azure automatiquement par défaut. Avec kubenet, les nœuds obtiennent une adresse IP du sous-réseau du réseau virtuel Azure. Les pods reçoivent une adresse IP du sous-réseau de réseau virtuel Azure des nœuds à partir d’un espace d’adressage logiquement différent. La traduction d’adresses réseau (NAT) est ensuite configurée afin que les pods puissent accéder aux ressources sur le réseau virtuel Azure. L’adresse IP source du trafic fait l’objet d’une opération NAT sur l’adresse IP principale du nœud. Cette approche réduit considérablement le nombre d’adresses IP que vous devez réserver dans votre espace réseau pour que les pods les utilisent.

Vous pouvez configurer le nombre maximal de modules pouvant être déployés sur un nœud au moment de la création du cluster ou lors de la création de pools de nœuds. Si vous ne spécifiez pas maxPods lors de la création de pools de nœuds, vous recevez la valeur par défaut de 110 pour kubenet.

Vue d’ensemble de la mise en réseau kubenet avec votre propre sous-réseau

Dans de nombreux environnements, vous avez défini des réseaux virtuels et des sous-réseaux avec des plages d’adresses IP allouées, et vous utilisez ces ressources pour prendre en charge plusieurs services et applications. Pour fournir une connectivité réseau, les clusters AKS peuvent utiliser kubenet (mise en réseau de base) ou Azure CNI (mise en réseau avancée).

Avec kubenet, seuls les nœuds reçoivent une adresse IP dans le sous-réseau de réseau virtuel. 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 gère la connectivité entre les pods sur les nœuds. 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 par défaut, mais vous pouvezutiliser votre propre table de routage pour la gestion des itinéraires personnalisés si vous le souhaitez. Vous pouvez également déployer des pods derrière un service qui reçoit une adresse IP attribuée et équilibre la charge du trafic pour l’application. Le diagramme suivant illustre la façon dont les nœuds AKS reçoivent une adresse IP dans le sous-réseau de réseau virtuel, mais pas les pods :

Azure prend en charge un maximum de 400 routes dans une route UDR. Vous ne pouvez donc pas avoir un cluster AKS comportant plus de 400 nœuds. Les nœuds virtuels AKS et les stratégies réseau Azure ne sont pas pris en charge avec kubenet. Les stratégies réseau Calico sont prises en charge.

Limitations et considérations relatives à kubenet

• Un tronçon supplémentaire est nécessaire dans la conception de kubenet, ce qui ajoute une latence mineure à la communication des pods.
• L’utilisation de kubenet requiert des tables de routage et des itinéraires définis par l’utilisateur, ce qui complique les opérations.
  • Pour plus d’informations, consultez Personnaliser la sortie du cluster avec une table de routage définie par l’utilisateur dans AKS et Personnaliser la sortie du cluster avec des types sortants dans AKS.
• Le design de kubenet ne permet pas la prise en charge de l’adressage direct aux pods.
• Contrairement aux clusters Azure CNI, plusieurs clusters kubenet ne peuvent pas partager un sous-réseau.
• AKS n’applique pas les groupes de sécurité réseau (NSG) à son sous-réseau et ne modifie pas les NSG associés à ce sous-réseau. Si vous fournissez votre propre sous-réseau et ajoutez des groupes associés à ce sous-réseau, vous devez vous assurer que les règles de sécurité dans les groupes autorisent le trafic entre le CIDR du nœud et celui du pod. Pour plus d’informations, consultez Groupes de sécurité réseau.
• Les fonctionnalités non prises en charge sur kubenet comprennent :
  • Stratégies réseau Azure
  • les pools de nœuds Windows ;
  • le module complémentaire de nœuds virtuels.

Remarque

Certains pods système tels que konnectivity dans le cluster utilisent l’adresse IP du nœud hôte plutôt qu’une adresse IP de l’espace d’adressage de superposition. Les pods système n’utilisent que l’adresse IP du nœud et non une adresse IP du réseau virtuel.

Disponibilité et épuisement des adresses IP

Avec Azure CNI, une plage d’adresses IP attribuée trop petite pour ensuite ajouter des nœuds supplémentaires quand vous mettez à l’échelle ou mettez à niveau un cluster constitue un problème courant. L’équipe réseau peut également ne pas être en mesure d’émettre une plage d’adresses IP suffisamment grande pour prendre en charge vos demandes d’applications attendues. À titre de compromis, vous pouvez créer un cluster AKS qui utilise kubenet et vous connecter à un sous-réseau de réseau virtuel existant. Cette approche permet aux nœuds de recevoir des adresses IP définies sans avoir besoin de réserver un grand nombre d’adresses IP à l’avance pour tous les pods potentiels qui pourraient s’exécuter dans le cluster.

Avec kubenet, vous pouvez utiliser une plage d’adresses IP beaucoup plus petite et prendre en charge de grands clusters et les demandes d’applications. Par exemple, avec une plage d’adresses IP /27sur votre sous-réseau, vous pouvez exécuter un cluster de 20 à 25 nœuds avec suffisamment de place pour effectuer une mise à l’échelle ou une mise à niveau. Cette taille de cluster prend en charge jusqu’à 2 200 à 2 750 pods (avec un maximum par défaut de 110 pods par nœud). Le nombre maximal de pods par nœud que vous pouvez configurer avec kubenet dans AKS est 250.

Les calculs de base suivants comparent la différence entre les modèles de réseaux :

• kubenet : une plage d’adresses IP /24 simple peut prendre en charge jusqu’à 251 nœuds dans le cluster. Chaque sous-réseau de réseau virtuel Azure réserve les trois premières adresses IP pour les opérations de gestion. Ce nombre de nœuds peut prendre en charge jusqu’à 27 610 pods (avec un maximum par défaut de 110 pods par nœud.
• Azure CNI : cette même plage de sous-réseau /24 de base peut seulement prendre en charge un maximum de 8 nœuds dans le cluster. Ce nombre de nœuds peut prendre en charge jusqu’à 240 pods, avec un maximum par défaut de 30 pods par nœud.

Remarque

Ces valeurs maximales ne prennent pas en compte les opérations de mise à niveau ou de mise à l’échelle. Dans la pratique, vous ne pouvez pas exécuter le nombre maximal de nœuds que la plage d’adresses IP de sous-réseau prend en charge. Vous devez laisser certaines adresses IP disponibles pour qu’elles puissent être utilisées pendant les opérations de mise à l’échelle et de mise à niveau.

Peering de réseau virtuel et connexions ExpressRoute

Vous pouvez utiliser l’appairage de réseaux virtuels Azure ou les connexions ExpressRoute avec Azure CNI et kubenet pour fournir une connectivité locale. Planifiez vos plages d’adresses IP avec soin pour éviter le chevauchement et un routage incorrect du trafic. Par exemple, de nombreux réseaux locaux utilisent une plage d’adresses 10.0.0.0/8 qui est publiée sur la connexion ExpressRoute. Nous vous recommandons de créer vos clusters AKS dans des sous-réseaux de réseau virtuel Azure en dehors de cette plage d’adresses, comme 172.16.0.0/16.

Pour plus d’informations, consultez Comparer les modèles réseau et leurs étendues de prise en charge.

Forum aux questions sur le sous-réseau de pod Azure CNI

• Puis-je déployer des machines virtuelles dans le sous-réseau de mon cluster ?

  Oui pour le sous-réseau de nœud Azure CNI, les machines virtuelles peuvent être déployées dans le même sous-réseau que le cluster AKS.

• Quelle adresse IP source les systèmes externes voient-ils pour le trafic en provenance d’un pod compatible avec Azure CNI ?

  Les systèmes dans le même réseau virtuel que le cluster AKS voient l’adresse IP du pod comme l’adresse source pour tout trafic en provenance du pod. Les systèmes situés en dehors du réseau virtuel du cluster AKS voient l’adresse IP du nœud en tant qu’adresse source pour tout le trafic en provenance du pod. Toutefois, pour l’allocation d’adresses IP dynamiques Azure CNI, quelle que soit la connexion se trouvant dans le même réseau virtuel ou entre réseaux virtuels, l’adresse IP du pod est toujours l’adresse source pour tout trafic provenant du pod. Cela est dû au fait que Azure CNI pour l’allocation d’adresses IP dynamiques implémente l’infrastructure de mise en réseau de conteneurs Microsoft Azure, qui offre une expérience de bout en bout. Par conséquent, il élimine l’utilisation de ip-masq-agent, qui est toujours utilisée par Azure CNI traditionnel.

• Puis-je configurer des stratégies de réseau spécifiques aux pods ?

  Oui, la stratégie de réseau Kubernetes est disponible dans AKS. Pour la prise en main, consultez Sécuriser le trafic entre les pods avec des stratégies réseau dans Azure Kubernetes Service (AKS).

• Le nombre maximal de pods pouvant être déployés sur un nœud peut-il être configuré ?

  Par défaut, les clusters AKS utilisent kubenet, et un réseau et un sous-réseau virtuels sont créés. Avec kubenet, les nœuds obtiennent une adresse IP d’un sous-réseau du réseau virtuel. La traduction d’adresses réseau (NAT) est ensuite configurée sur les nœuds, et les pods reçoivent une adresse IP « cachée » derrière l’adresse IP du nœud. Cette approche réduit le nombre d’adresses IP que vous avez besoin de réserver dans votre espace réseau à l’usage des pods.

  Avec l’interface Azure Container Networking Interface (CNI), chaque pod reçoit une adresse IP du sous-réseau et est accessible directement. Les systèmes dans le même réseau virtuel que le cluster AKS voient l’adresse IP du pod comme l’adresse source pour tout trafic en provenance du pod. Les systèmes situés en dehors du réseau virtuel du cluster AKS voient l’adresse IP du nœud en tant qu’adresse source pour tout le trafic en provenance du pod. Ces adresses IP doivent être uniques dans votre espace réseau et doivent être planifiées à l’avance. Chaque nœud possède un paramètre de configuration pour le nombre maximal de pods qu’il prend en charge. Le nombre équivalent d’adresses IP par nœud est alors réservé à l’avance pour ce nœud. Cette approche nécessite davantage de planification. De plus, elle conduit souvent à l’épuisement des adresses IP ou à la nécessité de regénérer les clusters dans un sous-réseau plus vaste à mesure que vos demandes d’applications augmentent.

• Puis-je déployer des machines virtuelles dans le sous-réseau de mon cluster ?

  Oui. Toutefois, pour Azure CNI pour l’allocation d’adresses IP dynamiques, les machines virtuelles ne peuvent pas être déployées dans le sous-réseau du pod.

• Quelle adresse IP source les systèmes externes voient-ils pour le trafic en provenance d’un pod compatible avec Azure CNI ?

  Les systèmes dans le même réseau virtuel que le cluster AKS voient l’adresse IP du pod comme l’adresse source pour tout trafic en provenance du pod. Les systèmes situés en dehors du réseau virtuel du cluster AKS voient l’adresse IP du nœud en tant qu’adresse source pour tout le trafic en provenance du pod.

  Toutefois, pour Azure CNI pour l’allocation d’adresses IP dynamiques, quelle que soit la connexion se trouvant dans le même réseau virtuel ou entre réseaux virtuels, l’adresse IP du pod est toujours l’adresse source pour tout trafic provenant du pod. Cela est dû au fait que Azure CNI pour l’allocation d’adresses IP dynamiques implémente l’infrastructure de mise en réseau de conteneurs Microsoft Azure, qui offre une expérience de bout en bout. Par conséquent, il élimine l’utilisation de ip-masq-agent, qui est toujours utilisée par Azure CNI traditionnel.

• Puis-je utiliser un autre sous-réseau dans le réseau virtuel de Mon cluster pour laplage d’adresses du service Kubernetes?

  Cette configuration, bien que possible, n’est pas recommandée. La plage d’adresses du service est un jeu d’adresses IP virtuelles que Kubernetes attribue aux services internes dans votre cluster. Azure Networking ne peut pas voir la plage d’adresses IP de service du cluster Kubernetes. Le manque de visibilité de la plage d’adresses de service du cluster peut entraîner des problèmes. Il est possible de créer ultérieurement un sous-réseau dans le réseau virtuel du cluster qui chevauche la plage d’adresses de service. Si un chevauchement de ce type se produit, Kubernetes peut affecter à un service une adresse IP déjà utilisée par une autre ressource dans le sous-réseau, ce qui provoque un comportement imprévisible ou des échecs. Utilisez une plage d’adresses en dehors du réseau virtuel du cluster pour éviter tout risque de chevauchement. Oui, lorsque vous déployez un cluster avec l’interface CLI Azure ou un modèle Resource Manager. Consultez Nombre maximal de pods par nœud.

• Puis-je utiliser un autre sous-réseau dans le réseau virtuel de Mon cluster pour laplage d’adresses du service Kubernetes?

  Cette configuration, bien que possible, n’est pas recommandée. La plage d’adresses du service est un jeu d’adresses IP virtuelles que Kubernetes attribue aux services internes dans votre cluster. Azure Networking ne peut pas voir la plage d’adresses IP de service du cluster Kubernetes. Le manque de visibilité de la plage d’adresses de service du cluster peut entraîner des problèmes. Il est possible de créer ultérieurement un sous-réseau dans le réseau virtuel du cluster qui chevauche la plage d’adresses de service. Si un chevauchement de ce type se produit, Kubernetes peut affecter à un service une adresse IP déjà utilisée par une autre ressource dans le sous-réseau, ce qui provoque un comportement imprévisible ou des échecs. Utilisez une plage d’adresses en dehors du réseau virtuel du cluster pour éviter tout risque de chevauchement.