Vue d’ensemble de MetalLB pour les clusters Kubernetes

S’applique à : AKS sur Azure Local

Lorsque vous configurez votre cluster AKS Arc, vous devez rendre vos services accessibles en dehors du cluster. Le type LoadBalancer est idéal pour cette accessibilité, mais l’adresse IP externe reste en attente. L’extension pour MetalLB pour Kubernetes avec Azure Arc est un outil qui vous permet de générer des adresses IP externes pour vos applications et services. Les clusters Kubernetes avec Arc peuvent s’intégrer à MetalLB grâce l’extension MetalLB pour Kubernetes avec Azure Arc.

Pour rendre vos services accessibles en dehors du cluster, MetalLB requiert des adresses IP. MetalLB s’occupe de l’attribution et de la libération de ces adresses si nécessaire lorsque vous créez des services. Toutefois, il distribue uniquement les adresses IP qui se trouvent dans ses pools configurés. Lorsque MetalLB affecte une adresse IP externe à un service, il informe le réseau en dehors du cluster que cette adresse IP appartient au cluster. Cette communication s’effectue à l’aide de protocoles réseau standard, comme ARP ou BGP.

• Mode de couche 2 (ARP) : en mode couche 2, un nœud K8s dans le cluster prend possession du service et utilise des protocoles de découverte d’adresses standard (ARP pour IPv4) pour rendre ces adresses IP accessibles sur le réseau local. Du point de vue du réseau local, la machine d’annonce présente simplement plusieurs adresses IP.
• BGP : en mode BGP, toutes les machines du cluster établissent des sessions de peering BGP avec des routeurs proches que vous contrôlez et leur indiquent comment transférer le trafic vers les adresses IP de service. L’utilisation de BGP permet un équilibrage de charge réel sur plusieurs nœuds et un contrôle de trafic affiné en raison des mécanismes de stratégie de BGP.

MetalLB a deux composants :

• Contrôleur : responsable de l’allocation d’adresses IP pour chaque service de type=loadbalancer.
• Intervenant : responsable de la publication de l’adresse IP à l’aide de ARP ou du protocole BGP. Pour répondre aux exigences de haute disponibilité(HA), le déploiement de l’intervenant est un daemonset.

Note

• Les pods d’intervenant utilisent le réseau hôte. C’est-à-dire que leur adresse IP est l’adresse IP du nœud, afin qu’elles puissent envoyer directement des messages de diffusion via l’interface réseau hôte.
• Le pod de contrôleur est un pod normal qui réside dans n’importe quel nœud du cluster.

• En mode ARP, l’un des pods d'intervenant est sélectionné comme principal. Il publie ensuite l’adresse IP à l’aide d’un message de diffusion ARP, en liant l’adresse IP avec l’adresse MAC du nœud dans lequel il réside. Ainsi, tout le trafic atteint d’abord un nœud, puis kube-proxy le répartit uniformément sur tous les pods principaux du service.
• En mode BGP, tous les nœuds de cluster établissent des connexions avec tous les homologues BGP créés dans l’onglet BGP Peers. Souvent,, un homologue BGP est un commutateur TOR. Pour diffuser les informations de routage BGP, les homologues BGP doivent être configurés de manière à reconnaître l’adresse IP et l’ASN des nœuds de cluster. Lorsque vous utilisez BGP avec ECMP (Equal-Cost MultiPath), le trafic est réparti uniformément sur tous les nœuds et obtient donc un véritable équilibrage de charge.

Comparer les modes MetalLB L2 (ARP) et BGP

Le choix entre le mode L2 et BGP avec MetalLB dépend de vos besoins spécifiques, de l’infrastructure réseau et des scénarios de déploiement :

Aspect	MetalLB en mode L2 (ARP)	MetalLB en mode BGP
Vue d’ensemble	En mode couche 2, un nœud K8s est responsable de publier un service sur le réseau local. Du point de vue du réseau, le nœud K8s semble posséder plusieurs adresses IP affectées à son interface réseau.	En mode BGP, chaque nœud K8s de votre cluster établit une session de peering BGP avec vos routeurs réseau et utilise cette session de peering pour publier les adresses IP des services de cluster externe.
Affectation d’adresses IP	Les pools d’adresses IP KeeperLB doivent être dans le même sous-réseau que les nœuds K8s.	Les pools d’adresses IP MetalLB peuvent se trouver dans un réseau différent des nœuds K8s.
Complexité de la configuration	Faible. Étant donné que vous fournissez des adresses IP dans le même réseau que vos nœuds Kubernetes, vous devez uniquement indiquer un CIDR IP ou un pool d'adresses IP lors de la configuration de MetalLB.	Élevée. Configurer BGP nécessite de connaître le protocole BGP et une compréhension de votre infrastructure réseau.
Extensibilité	Limité aux réseaux de couche 2, adaptés aux déploiements K8s de petite à moyenne taille.	Convient aux topologies réseau complexes et aux déploiements K8s à grande échelle.
Compatibilité avec le réseau d’infrastructure	Fonctionne avec tous les réseaux, mais peut provoquer un flooding ARP dans de grands clusters K8s, car une seule adresse IP est utilisée pour tous les services, et la bande passante d’entrée du service est limitée à la bande passante d’un seul nœud.	Requiert la prise en charge du protocole BGP dans l’infrastructure réseau.
Ingénierie du trafic	Contrôle limité du routage du trafic.	Contrôle précis du routage du trafic avec des attributs BGP.
Connectivité externe	Nécessite davantage de configuration pour la connectivité externe.	Se connecte de manière fluide avec des réseaux externes à l’aide du routage BGP.

Questions fréquentes (FAQ)

Est-il possible de réutiliser une instance MetalLB sur des clusters AKS Arc ?

Non, MetalLB ne peut pas être réutilisé sur les clusters AKS Arc. MetalLB existe en tant que pods dans un cluster Kubernetes, tandis que les équilibreurs de charge sont des ressources personnalisées (CR). Vous devez installer l’extension k8s MetalLB Arc avec Azure CLI, les modèles Portail Azure ou Azure Resource Manager, puis créer des équilibreurs de charge pour chaque cluster AKS Arc.

Étapes suivantes

• Déployer MetalLB à l’aide du portail Azure