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 CNIs sont responsables de l’attribution d’adresses IP à des pods, du routage réseau entre les pods, du routage de service Kubernetes, etc.
AKS fournit plusieurs plug-ins CNI que vous pouvez utiliser dans vos clusters en fonction de vos besoins en réseau.
Modèles de mise en réseau dans AKS
Le choix d’un plug-in CNI 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 et réseau plat.
Les deux modèles de mise en réseau ont plusieurs options de plug-in CNI pris en charge. Les principales différences entre les modèles concernent la façon dont les adresses IP de pod sont affectées et la façon dont le trafic quitte le cluster.
Réseaux superposés
La mise en réseau par superposition est le modèle de mise en réseau le plus courant utilisé dans Kubernetes. Dans les réseaux de superposition, les pods reçoivent une adresse IP d’un CIDR privé et logiquement distinct du sous-réseau de réseau virtuel Azure où les nœuds AKS sont déployés. Cela permet une scalabilité plus simple et souvent meilleure que le modèle de réseau plat.
Dans les réseaux de superposition, les pods communiquent entre eux directement. Pour le trafic sortant du cluster, l’adresse réseau source est traduite (SNAT) vers l’adresse IP du nœud, et le trafic IP du pod entrant est acheminé via un service, tel qu’un équilibreur de charge. Cela signifie que l’adresse IP du pod est « masquée » derrière l’adresse IP du nœud. Cette approche réduit le nombre d’adresses IP de réseau virtuel requises pour vos clusters.
Azure Kubernetes Service fournit les plug-ins CNI suivants pour la mise en réseau de superposition :
- Superposition Azure CNI, le plug-in CNI recommandé pour la plupart des scénarios.
- kubenet, le modèle de superposition hérité CNI.
Réseaux plats
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 du même réseau virtuel Azure que les nœuds AKS. Cela signifie que le trafic sortant de vos clusters n’est pas traduit (SNAT) et que l’adresse IP du pod est directement exposée à la destination. Cela peut être utile pour certains scénarios, par exemple lorsque vous devez exposer des adresses IP de pod à des services externes.
Azure Kubernetes Service fournit deux plug-ins CNI pour la mise en réseau de superposition. Cet article n’entre pas en profondeur pour chaque option de plug-in. Pour plus d’informations, consultez la documentation liée :
- Sous-réseau de pod Azure CNI, le plug-in CNI recommandé pour les scénarios de mise en réseau plat.
- Sous-réseau de nœud Azure CNI, un modèle de réseau plat hérité CNI que nous vous recommandons généralement d’utiliser uniquement si vous avez besoin d’un réseau virtuel managé pour votre cluster.
Choix d’un CNI
Il y a plusieurs facteurs à prendre en compte lors du choix d’un CNI. Chaque modèle de mise en réseau présente ses propres avantages et inconvénients, et le meilleur choix pour votre cluster dépend de vos besoins spécifiques.
Choix d’un modèle de mise en réseau
Les deux modèles de mise en réseau principaux dans AKS sont le réseau de superposition et le réseau plat.
Réseaux de superposition :
- 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 simple des adresses IP.
Réseaux plats :
- Les pods bénéficient de la connectivité complète du réseau virtuel et sont directement accessibles via leur adresse IP privée depuis des réseaux connectés.
- Exige un espace d’adressage IP de réseau virtuel volumineux et non fragmenté.
Comparaison des cas d’usage
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 réseau | Points forts de cas d’usage |
|---|---|---|
| Superposition Azure CNI | Overlay | – 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 pods Azure CNI | Plat | – Accès de pod externe direct – Modes pour la prise en charge d’une utilisation efficace des adresses IP de réseau virtuel ou des grandes échelles de cluster (préversion) |
| Kubenet (hérité) | Overlay | – Hiérarchise la conservation des adresses IP – Échelle limitée – Gestion manuelle des itinéraires |
| Sous-réseau de nœuds Azure CNI (hérité) | Plat | – Accès de pod externe direct – Configuration plus simple – Échelle limitée – Utilisation inefficace des adresses IP de réseau virtuel |
Comparaison des fonctionnalités
Vous pouvez également comparer les fonctionnalités de chaque plug-in CNI. Le tableau suivant fournit une comparaison générale des fonctionnalités prises en charge par chaque plug-in CNI :
| Fonctionnalité | Superposition Azure CNI | Sous-réseau de pods Azure CNI | Sous-réseau de nœuds Azure CNI (hérité) | Kubenet |
|---|---|---|---|---|
| Déployer un cluster dans un réseau virtuel nouveau ou existant | Prise en charge | Prise en charge | Prise en charge | Pris en charge – UDR manuels |
| Connectivité entre le pod et la machine virtuelle avec une machine virtuelle dans un réseau virtuel appairé ou dans le même réseau virtuel | Initié par le pod | S’applique dans les deux sens | S’applique dans les deux sens | Initié par le pod |
| Accès local à l’aide d’un VPN ou d’Express Route | Initié par le pod | S’applique dans les deux sens | S’applique dans les deux sens | Initié par le pod |
| Accès aux points de terminaison de service | Prise en charge | Prise en charge | Prise en charge | Prise en charge |
| Exposer des services à l’aide de l’équilibreur de charge | Prise en charge | Prise en charge | Prise en charge | Prise en charge |
| Exposer des services à l’aide d’App Gateway | Actuellement non pris en charge | Prise en charge | Prise en charge | Prise en charge |
| Exposer des services à l’aide du contrôleur d’entrée | Prise en charge | Prise en charge | Prise en charge | Prise en charge |
| les pools de nœuds Windows ; | Prise en charge | Prise en charge | Prise en charge | Non pris en charge |
| Azure DNS et zones privées par défaut | Prise en charge | Prise en charge | Prise en charge | Prise en charge |
| Partage de sous-réseau de réseau virtuel entre plusieurs clusters | Prise en charge | Prise en charge | Prise en charge | Non pris en charge |
Étendue du support entre des modèles de réseaux
Selon le CNI que vous utilisez, vos ressources de réseau virtuel de cluster peuvent être déployées de l’une des manières suivantes :
- La plateforme Azure peut automatiquement créer et configurer les ressources de réseau virtuel lorsque vous créez un cluster AKS. comme dans la Superposition Azure CNI, le Sous-réseau de nœuds Azure CNI et Kubenet.
- 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. Par 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.
Prérequis
Il existe plusieurs exigences et considérations à prendre en compte lors de la planification de votre configuration réseau pour AKS :
- 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/16ou192.0.2.0/24pour la plage d’adresses de service Kubernetes, la plage d’adresses de pod ou la plage d’adresses de réseau virtuel de cluster. - Dans les scénarios BYO VNet, l’identité de cluster utilisée par le cluster AKS doit disposer au moins des autorisations de contributeur 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/actionMicrosoft.Authorization/roleAssignments/writeMicrosoft.Network/virtualNetworks/subnets/read(nécessaire uniquement si vous définissez 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 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.
Étapes suivantes
Azure Kubernetes Service