Concepts de mise en réseau de conteneurs

Article
04/19/2024

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.

Les applications plus complexes peuvent nécessiter la configuration du trafic d’entrée pour l’arrêt ou le routage SSL/TLS de plusieurs composants. Pour des raisons de sécurité, vous pouvez également être amené à limiter le flux du trafic réseau vers ou entre les nœuds et les pods.

Cet article présente les concepts de base qui fournissent la 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 routages du trafic entrant, vous pouvez utiliser un contrôleur d’entrée.

Notes

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’adresses IP d’é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 qui fait que chaque charge de travail reçoit une adresse IP de service distincte, ou vous pouvez redéployer vos charges de travail sur des clusters cibles qui utilisent des objets différents AksHciClusterNetwork .

ExternalName : crée une entrée DNS spécifique pour faciliter l’accès à l’application. 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.

Concepts de base de la mise en réseau Kubernetes sur Azure Stack Edge HCI

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 Azure Stack HCI permet également de simplifier la mise en réseau virtuelle pour les clusters AKS sur Azure Stack HCI en fournissant le réseau « underlay » de façon 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 les nœuds hébergent 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 Stack HCI. Pour plus d’informations, consultez Concepts de mise en réseau de nœuds.
Services Kubernetes : dans Kubernetes, les services regroupent logiquement les adresses IP des pods pour permettre un accès direct via une adresse IP unique 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 dans un déploiement AKS sur Azure Stack HCI 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 Azure Stack HCI qui permet la création et la gestion de l’environnement virtualisé hébergeant Kubernetes sur un cluster Azure Stack HCI local ou un cluster Windows Server. Le modèle réseau suivi de votre cluster Azure Stack HCI 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 Stack HCI, vous pouvez déployer un cluster utilisant l’un des modèles de 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

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	aucun	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 avoir déployé le cluster, et elle s’applique aux nœuds de cluster Windows et Linux.

Voici un exemple :

New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'

Étapes suivantes

Cet article traite des concepts de mise en réseau pour les conteneurs dans des nœuds AKS sur Azure Stack HCI. Pour plus d’informations sur les concepts d’AKS sur Azure Stack HCI, consultez les articles suivants :