Vue d’ensemble de MetalLB pour les clusters Kubernetes
S’applique à : Azure Local, version 23H2
Lorsque vous configurez votre cluster AKS Arc, vous avez besoin d’un moyen de rendre vos services accessibles en dehors du cluster. Le LoadBalancer type 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 à l’aide de l’extension MetalLB pour Kubernetes avec Azure Arc.
Pour rendre vos services accessibles en dehors du cluster, MetalLB a besoin d’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, mais 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 a 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 indiquent à ces routeurs 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 publicité de l’adresse IP à l’aide
ARPouBGPau protocole. Pour répondre aux exigences de haute disponibilité(HA), le déploiement de l’orateur est un démon.
Remarque
- Les pods d’orateur 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 du haut-parleur est sélectionné comme leader. 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. En règle générale, un homologue BGP est un commutateur TOR. Pour diffuser les informations de routage BGP, les homologues BGP doivent être configurés afin qu’ils reconnaissent l’adresse IP et l’ASN des nœuds de cluster. Lorsque vous utilisez BGP avec ECMP (Equal-Cost MultiPath), le trafic atteint 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 assume la responsabilité de la publicité d’un service sur le réseau local. Du point de vue du réseau, il semble que le nœud K8s possède 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 se trouver dans le même sous-réseau que les nœuds K8s. | Les pools d’adresses IP Lblb 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 spécifier un CIDR IP ou un pool IP lors de la configuration de MetalLB. | Élevé. La configuration de BGP nécessite une connaissance du protocole BGP et une compréhension de votre infrastructure réseau. |
| Évolutivité | Limité aux réseaux de couche 2, adaptés aux déploiements K8s de petite à moyenne taille. | Adapté aux topologies réseau complexes et aux déploiements K8s à grande échelle. |
| Compatibilité avec le réseau d’infrastructure | Fonctionne avec n’importe quel réseau, mais peut provoquer des inondations 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. | Nécessite 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 à l’aide d’attributs BGP. |
| Connectivité externe | Nécessite davantage de configuration pour la connectivité externe. | Fournit une connectivité transparente avec des réseaux externes à l’aide du routage BGP. |
Questions fréquentes (FAQ)
Une instance MetalLB peut-elle être réutilisée sur des clusters AKS Arc ?
Non, MetalLB ne peut pas être réutilisé sur les clusters AKS Arc. MetalLB vit en tant que pods dans un cluster Kubernetes et les équilibreurs de charge sont des ressources personnalisées (CR). Vous devez installer l’extension k8s MetalLB Arc à l’aide d’Azure CLI, des modèles Portail Azure ou Azure Resource Manager et créer des équilibreurs de charge pour chaque cluster AKS Arc.