Concepts de mise en réseau de conteneurs
S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server
Dans une approche de microservices basés sur les conteneurs, les composants d’application doivent collaborer pour traiter leurs tâches. Kubernetes fournit des ressources qui permettent cette communication entre applications. En outre, il vous permet de vous connecter à des applications et de les exposer en interne ou en externe. Pour créer des applications hautement disponibles, vous pouvez équilibrer leurs charges.
Des applications plus complexes peuvent nécessiter la configuration du trafic d’entrée pour l’arrêt SSL/TLS ou le routage de plusieurs composants. Vous devrez peut-être également restreindre le flux de trafic réseau vers ou entre des pods et des nœuds pour la sécurité.
Cet article présente les concepts fondamentaux qui fournissent une mise en réseau à vos applications dans AKS activé par Arc :
- Services Kubernetes
- Contrôleur d’entrée
- Stratégies réseau
Services Kubernetes
Pour simplifier la configuration du réseau pour les charges de travail d’applications, Kubernetes utilise des services pour regrouper logiquement un ensemble de pods et fournir une connectivité réseau. Les types de services disponibles sont les suivants :
Adresse IP du cluster : crée une adresse IP interne à utiliser dans le cluster Kubernetes. Utilisez une adresse IP de cluster pour les applications exclusivement internes qui prennent en charge d’autres charges de travail au sein du cluster.
NodePort : crée un mappage de port sur le nœud sous-jacent qui permet à l’application d’être directement accessible avec l’adresse IP et le port du nœud.
LoadBalancer : crée une ressource d’équilibreur de charge Azure, configure une adresse IP externe et connecte les pods demandés au pool principal de l’équilibreur de charge. Pour que le trafic des clients puisse atteindre l’application, des règles d’équilibrage de charge sont créées sur les ports souhaités.
Pour d’autres contrôles et routage du trafic entrant, vous pouvez utiliser un contrôleur d’entrée.
Remarque
Lorsque vous déployez un cluster cible qui partage un réseau avec un autre cluster cible, il existe la possibilité d’un conflit d’adresse IP de l’équilibreur de charge.
Cela peut se produire si vous déployez deux charges de travail qui utilisent des ports différents dans des clusters cibles partageant le même objet AksHciClusterNetwork. En raison de la façon dont les adresses IP et les mappages de ports sont alloués à l’intérieur du proxy haute disponibilité, cela peut entraîner une attribution d’adresse IP en double. Si cela se produit, une ou les deux charges de travail peuvent rencontrer des problèmes de connectivité réseau aléatoires jusqu’à ce que vous redéployiez vos charges de travail. Lorsque vous redéployez vos charges de travail, vous pouvez utiliser le même port que chaque charge de travail pour recevoir une adresse IP de service distincte, ou vous pouvez redéployer vos charges de travail sur des clusters cibles qui utilisent différents AksHciClusterNetwork objets.
ExternalName : crée une entrée DNS spécifique pour faciliter l’accès aux applications. Les adresses IP des équilibreurs de charge et des services peuvent être internes ou externes, en fonction de la configuration globale de votre réseau, et peuvent être attribuées de façon dynamique. Vous pouvez également spécifier une adresse IP statique existante à utiliser. Une adresse IP statique existante est souvent liée à une entrée DNS. Les équilibreurs de charge internes ne recevant qu'une adresse IP privée, ils ne sont pas accessibles à partir d'Internet.
Principes de base de la mise en réseau Kubernetes sur Azure Local
Pour autoriser l’accès à vos applications ou pour que les composants d’application communiquent entre eux, Kubernetes fournit une couche d’abstraction à la mise en réseau virtuelle. Les nœuds Kubernetes sont connectés au réseau virtuel et peuvent fournir la connectivité entrante et sortante pour les pods. Le composant kube-proxy s’exécutant sur chaque nœud fournit ces fonctionnalités réseau.
Dans Kubernetes, les Services regroupent logiquement les pods pour permettre :
- un accès direct via une adresse IP ou un nom DNS, et un port spécifique ;
- de répartir le trafic à l’aide d’un équilibreur de charge entre plusieurs pods hébergeant le même service ou la même application.
La plateforme locale Azure permet également de simplifier la mise en réseau virtuelle pour AKS sur les clusters locaux Azure en fournissant le réseau « sous-couche » de manière hautement disponible.
Lorsque vous créez un cluster AKS, nous créons et configurons également une ressource d’équilibreur de charge HAProxy sous-jacente. Lorsque vous déployez des applications dans un cluster Kubernetes, les adresses IP sont configurées pour vos pods et services Kubernetes en tant que points de terminaison dans cet équilibreur de charge.
Ressources d’adresse IP
Pour simplifier la configuration réseau des charges de travail d’application, AKS Arc affecte des adresses IP aux objets suivants dans un déploiement :
- Serveur d’API de cluster Kubernetes : le serveur d’API est un composant du plan de contrôle Kubernetes qui expose l’API Kubernetes. Le serveur d’API est le front-end du plan de contrôle Kubernetes. Des adresses IP statiques sont toujours allouées aux serveurs d’API, quel que soit le modèle de mise en réseau sous-jacent.
- Nœuds Kubernetes (machines virtuelles) : un cluster Kubernetes se compose d’un ensemble de machines worker, appelées nœuds et nœuds hébergeant des applications conteneurisées. En plus des nœuds de plan de contrôle, chaque cluster a au moins un nœud Worker. Pour un cluster AKS, les nœuds Kubernetes sont configurés en tant que machines virtuelles. Ces machines virtuelles sont créées en tant que machines virtuelles hautement disponibles dans Azure Local, pour plus d’informations, consultez les concepts de mise en réseau de nœuds.
- Services Kubernetes : dans Kubernetes, les services regroupent logiquement les adresses IP des pods pour autoriser l’accès direct via une seule adresse IP ou un nom DNS sur un port spécifique. Vous pouvez également distribuer le trafic à l’aide d’un équilibreur de charge. Des adresses IP statiques sont toujours allouées aux services Kubernetes, quel que soit le modèle de mise en réseau sous-jacent.
- Équilibreurs de charge HAProxy : HAProxy est un équilibreur de charge TCP/HTTP et un serveur proxy qui répartit les requêtes entrantes sur plusieurs points de terminaison. Chaque cluster de charge de travail d’un déploiement AKS sur Azure Local a un équilibreur de charge HAProxy déployé et configuré en tant que machine virtuelle spécialisée.
- Service cloud local Microsoft : il s’agit du fournisseur de cloud local Azure qui permet la création et la gestion de l’environnement virtualisé hébergeant Kubernetes sur un cluster local Azure local ou un cluster Windows Server. Le modèle de mise en réseau suivi de votre cluster Azure Local ou Windows Server détermine la méthode d’allocation d’adresses IP utilisée par le service cloud local Microsoft. Pour en savoir plus sur les concepts de mise en réseau qu’implémente le service cloud local Microsoft, consultez Concepts de mise en réseau de nœuds.
Réseaux Kubernetes
Dans AKS sur Azure Local, vous pouvez déployer un cluster qui utilise l’un des modèles réseau suivants :
- Mise en réseau par superposition Flannel : les ressources réseau sont généralement créées et configurées en même temps que le cluster.
- Mise en réseau Project Calico : ce modèle offre des fonctionnalités de mise en réseau supplémentaires, telles que des stratégies réseau et un contrôle de flux.
Les deux implémentations de mise en réseau utilisent un modèle de configuration réseau par superposition, qui effectue une attribution d’adresses IP déconnectée du reste de la mise en réseau du centre de données.
Pour en savoir plus sur la mise en réseau par superposition, consultez la présentation de la mise en réseau par superposition Kubernetes pour Windows.
Pour plus d’informations sur le plug-in et les stratégies réseau Calico, consultez la prise en main de la stratégie de réseau Calico.
Comparaison des modèles de mise en réseau
Flannel
Remarque
Flannel CNI a été retiré en décembre 2023.
Flannel est une superposition de mise en réseau virtuel conçue spécifiquement pour les conteneurs. Flannel crée un réseau plat qui se superpose au réseau hôte. Une seule adresse IP est affectée à tous les conteneurs/pods dans ce réseau par superposition. Ils communiquent en se connectant directement à l’adresse IP de l’autre.
Calico
Calico est une solution de mise réseau open source et de sécurité réseau pour conteneurs, machines virtuelles et charges de travail basées sur un hôte natif. Calico prend en charge plusieurs plans de données, à savoir : un plan de données eBPF Linux, un plan de données de mise en réseau Linux et un plan de données HNS Windows.
Fonctions
| Fonctionnalité | Flannel | Calico |
|---|---|---|
| Stratégies de réseau | Non | Oui |
| IPv6 | Non | Oui |
| Couches utilisées | L2 (VxLAN) | L2 (VxLAN) |
| Déployer un cluster dans un réseau virtuel nouveau ou existant | Oui | Oui |
| Prise en charge de Windows | Oui | Oui |
| Connectivité pod-à-pod | Oui | Oui |
| Connexion pod-à-machine virtuelle, avec machine virtuelle dans le même réseau | Non | Oui |
| Connexion pod-à-machine virtuelle, avec machine virtuelle dans un réseau différent | Oui | Oui |
| Services Kubernetes | Oui | Oui |
| Exposer via l’équilibreur de charge | Oui | Oui |
| Réseaux | Nombreux réseaux sur le même cluster avec plusieurs démons | Nombreux réseaux sur le même cluster |
| Déploiement | Linux : DaemonSet | Linux : DaemonSet |
| Windows : Service | Windows : Service | |
| Ligne de commande | Aucune | calicoctl |
Important
Actuellement, la sélection par défaut consiste à utiliser Calico en mode mise en réseau par superposition. Pour activer Flannel, utilisez le -primaryNetworkPlugin paramètre de la New-AksHciCluster commande PowerShell et spécifiez flannel comme valeur. Cette valeur ne peut pas être modifiée après le déploiement du cluster, et elle s’applique à la fois aux nœuds de cluster Windows et Linux.
Par exemple :
New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'
Étapes suivantes
Cet article traite des concepts de mise en réseau pour les conteneurs dans les nœuds AKS sur Azure Local. Pour plus d’informations sur AKS sur les concepts locaux Azure, consultez les articles suivants :