Vue d’ensemble de la mise en réseau Azure CNI dans Azure Kubernetes Service (AKS)
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.
Remarque
Cet article présente uniquement azure CNI traditionnel. Pour la superposition Azure CNI, le réseau virtuel Azure CNI pour l’allocation d’adresses IP dynamiques et le réseau virtuel Azure CNI – Allocation de blocs statiques (préversion). Veuillez vous reporter à leur documentation à la place.
Prérequis
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
ou192.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 de 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 associés à ce sous-réseau, vous devez vous assurer que les règles de sécurité dans les groupes autorisent le trafic dans la plage du noeud CIDR. Pour plus d’informations, consultez Groupes de sécurité réseau.
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. Si vous souhaitez créer un réseau virtuel pour votre cluster, sélectionnez Créer un nouveau, puis suivez la procédure décrite dans la section Créer un réseau virtuel. Si vous voulez sélectionner 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. Si vous souhaitez créer un nouveau sous-réseau dans le réseau virtuel pour votre cluster, sélectionnez Créer un nouveau, puis exécutez la procédure décrite dans la section Créer un sous-réseau. 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 un autre réseau virtuel avec lequel le réseau virtuel du cluster s’apparie ;
- ne doit avoir aucun élément en commun avec des 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
ou192.0.2.0/24
Bien qu’il soit techniquement possible de spécifier une plage d’adresses de service dans le même réseau virtuel que votre cluster, cette procédure n’est pas recommandée. Tout chevauchement entre des plages d’adresses IP est susceptible d’entraîner des comportements imprévisibles. Pour plus d’informations, consultez la section FAQ de cet article. 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.
Forum aux questions
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 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é ?
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.
Vous ne pouvez pas modifier le nombre maximal de pods par nœud sur un cluster existant.
Comment configurer des propriétés supplémentaires pour le sous-réseau développé lors de la création du cluster AKS ? Par exemple, des points de terminaison du service.
La liste complète des propriétés pour le réseau virtuel et les sous- réseaux développés durant la création du cluster AKS peut être configurée dans la page de configuration du réseau virtuel standard du portail Azure.
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.
Étape suivante
Pour plus d’informations sur la mise en réseau dans AKS, consultez les articles suivants :
Azure Kubernetes Service