Chapitre 32. Équilibrage de charge avec MetalLB
32.1. A propos de MetalLB et de l'opérateur MetalLB
En tant qu'administrateur de cluster, vous pouvez ajouter l'opérateur MetalLB à votre cluster afin que lorsqu'un service de type LoadBalancer est ajouté au cluster, MetalLB puisse ajouter une adresse IP externe pour le service. L'adresse IP externe est ajoutée au réseau hôte de votre cluster.
32.1.1. Quand utiliser MetalLB
L'utilisation de MetalLB est intéressante lorsque vous disposez d'un cluster bare-metal, ou d'une infrastructure qui ressemble à du bare-metal, et que vous souhaitez un accès tolérant aux pannes à une application par le biais d'une adresse IP externe.
Vous devez configurer votre infrastructure réseau de manière à ce que le trafic réseau pour l'adresse IP externe soit acheminé des clients vers le réseau hôte du cluster.
Après avoir déployé MetalLB avec l'opérateur MetalLB, lorsque vous ajoutez un service de type LoadBalancer, MetalLB fournit un équilibreur de charge natif de la plateforme.
La MetalLB fonctionnant en mode couche 2 prend en charge le basculement en utilisant un mécanisme similaire au basculement IP. Toutefois, au lieu de s'appuyer sur le protocole de redondance des routeurs virtuels (VRRP) et sur keepalived, MetalLB s'appuie sur un protocole basé sur les commérages pour identifier les cas de défaillance des nœuds. Lorsqu'une défaillance est détectée, un autre nœud assume le rôle de nœud leader et un message ARP gratuit est envoyé pour diffuser ce changement.
La MetalLB fonctionnant en mode layer3 ou border gateway protocol (BGP) délègue la détection des défaillances au réseau. Le ou les routeurs BGP avec lesquels les nœuds d'OpenShift Container Platform ont établi une connexion identifieront toute défaillance de nœud et mettront fin aux routes vers ce nœud.
Il est préférable d'utiliser MetalLB plutôt que le basculement IP pour garantir la haute disponibilité des pods et des services.
32.1.2. Ressources personnalisées de l'opérateur MetalLB
L'opérateur MetalLB surveille son propre espace de noms pour les ressources personnalisées suivantes :
MetalLB-
Lorsque vous ajoutez une ressource personnalisée
MetalLBau cluster, l'opérateur MetalLB déploie MetalLB sur le cluster. L'opérateur ne prend en charge qu'une seule instance de la ressource personnalisée. Si l'instance est supprimée, l'opérateur supprime MetalLB du cluster. IPAddressPoolLa MetalLB a besoin d'un ou plusieurs pools d'adresses IP qu'elle peut attribuer à un service lorsque vous ajoutez un service de type
LoadBalancer. UnIPAddressPoolcomprend une liste d'adresses IP. La liste peut être une adresse IP unique définie à l'aide d'une plage, telle que 1.1.1.1-1.1.1.1, une plage spécifiée en notation CIDR, une plage spécifiée en tant qu'adresse de début et de fin séparée par un trait d'union, ou une combinaison des trois. UnIPAddressPoolnécessite un nom. La documentation utilise des noms tels quedoc-example,doc-example-reserved, etdoc-example-ipv6. Une ressourceIPAddressPoolattribue des adresses IP à partir du pool. Les ressources personnaliséesL2AdvertisementetBGPAdvertisementpermettent d'annoncer une IP donnée à partir d'un pool donné.NoteUn seul site
IPAddressPoolpeut être référencé par une annonce L2 et une annonce BGP.BGPPeer- La ressource BGP peer custom identifie le routeur BGP avec lequel MetalLB doit communiquer, le numéro d'AS du routeur, le numéro d'AS de MetalLB et les personnalisations pour l'annonce des routes. MetalLB annonce les routes pour les adresses IP du service load-balancer à un ou plusieurs pairs BGP.
BFDProfile- La ressource personnalisée BFD profile configure Bidirectional Forwarding Detection (BFD) pour un pair BGP. BFD permet de détecter les défaillances de chemin plus rapidement que BGP seul.
L2Advertisement-
La ressource personnalisée L2Advertisement annonce une IP provenant d'un site
IPAddressPoolà l'aide du protocole L2. BGPAdvertisement-
La ressource personnalisée BGPAdvertisement annonce une IP provenant d'un site
IPAddressPoolà l'aide du protocole BGP.
Une fois que vous avez ajouté la ressource personnalisée MetalLB au cluster et que l'opérateur a déployé MetalLB, les composants logiciels controller et speaker MetalLB commencent à fonctionner.
MetalLB valide toutes les ressources personnalisées pertinentes.
32.1.3. Composants du logiciel MetalLB
Lorsque vous installez l'Opérateur MetalLB, le déploiement metallb-operator-controller-manager démarre un pod. Le pod est l'implémentation de l'Opérateur. Le pod surveille les modifications apportées à toutes les ressources pertinentes.
Lorsque l'opérateur démarre une instance de MetalLB, il démarre un déploiement controller et un ensemble de démons speaker.
Vous pouvez configurer les spécifications de déploiement dans la ressource personnalisée MetalLB pour gérer le déploiement et l'exécution des pods controller et speaker dans votre cluster. Pour plus d'informations sur ces spécifications de déploiement, voir la section Additional Resources section.
controllerL'opérateur démarre le déploiement et un pod unique. Lorsque vous ajoutez un service de type
LoadBalancer, Kubernetes utilise le servicecontrollerpour allouer une adresse IP à partir d'un pool d'adresses. En cas de défaillance d'un service, vérifiez que vous avez l'entrée suivante dans vos journaux de podscontroller:Exemple de sortie
"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller
speakerL'opérateur démarre un ensemble de démons pour
speakerpods. Par défaut, un pod est démarré sur chaque nœud de votre cluster. Vous pouvez limiter les pods à des nœuds spécifiques en spécifiant un sélecteur de nœud dans la ressource personnaliséeMetalLBlorsque vous démarrez MetalLB. Sicontrollera alloué l'adresse IP au service et que le service n'est toujours pas disponible, lisez les journaux du podspeaker. Si le podspeakerest indisponible, exécutez la commandeoc describe pod -n.Pour le mode couche 2, après que le site
controllera attribué une adresse IP pour le service, les podsspeakerutilisent un algorithme pour déterminer quel podspeakersur quel nœud annoncera l'adresse IP de l'équilibreur de charge. L'algorithme consiste à hacher le nom du nœud et l'adresse IP de l'équilibreur de charge. Pour plus d'informations, voir "MetalLB and external traffic policy". Le sitespeakerutilise le protocole de résolution d'adresses (ARP) pour annoncer les adresses IPv4 et le protocole de découverte de voisins (NDP) pour annoncer les adresses IPv6.
En mode Border Gateway Protocol (BGP), après que controller a attribué une adresse IP au service, chaque pod speaker annonce l'adresse IP de l'équilibreur de charge à ses pairs BGP. Vous pouvez configurer les nœuds qui démarrent des sessions BGP avec des pairs BGP.
Les demandes concernant l'adresse IP de l'équilibreur de charge sont acheminées vers le nœud dont l'adresse speaker annonce l'adresse IP. Une fois que le nœud a reçu les paquets, le proxy de service les achemine vers un point de terminaison du service. Le point de terminaison peut se trouver sur le même nœud dans le cas optimal ou sur un autre nœud. Le proxy de service choisit un point de terminaison chaque fois qu'une connexion est établie.
32.1.4. MetalLB et politique de trafic externe
En mode couche 2, un nœud de votre cluster reçoit tout le trafic pour l'adresse IP de service. En mode BGP, un routeur du réseau hôte ouvre une connexion à l'un des nœuds de la grappe pour une nouvelle connexion client. La manière dont votre grappe gère le trafic après son entrée dans le nœud est affectée par la stratégie de trafic externe.
clusterIl s'agit de la valeur par défaut de
spec.externalTrafficPolicy.Avec la stratégie de trafic
cluster, une fois que le nœud a reçu le trafic, le proxy de service distribue le trafic à tous les pods de votre service. Cette stratégie assure une distribution uniforme du trafic dans les modules, mais elle masque l'adresse IP du client et l'application de vos modules peut avoir l'impression que le trafic provient du nœud plutôt que du client.localAvec la politique de trafic
local, après que le nœud a reçu le trafic, le proxy de service n'envoie le trafic qu'aux pods du même nœud. Par exemple, si le podspeakersur le nœud A annonce l'IP du service externe, tout le trafic est envoyé au nœud A. Une fois que le trafic entre dans le nœud A, le proxy de service n'envoie le trafic qu'aux modules du service qui se trouvent également sur le nœud A. Les modules du service qui se trouvent sur d'autres nœuds ne reçoivent aucun trafic du nœud A. Les modules du service situés sur d'autres nœuds servent de répliques en cas de basculement.Cette politique n'affecte pas l'adresse IP du client. Les modules d'application peuvent déterminer l'adresse IP du client à partir des connexions entrantes.
Les informations suivantes sont importantes lors de la configuration de la politique de trafic externe en mode BGP.
Bien que MetalLB annonce l'adresse IP de l'équilibreur de charge à partir de tous les nœuds éligibles, le nombre de nœuds équilibrant le service peut être limité par la capacité du routeur à établir des routes ECMP (equal-cost multipath). Si le nombre de nœuds annonçant l'adresse IP est supérieur à la limite du groupe ECMP du routeur, ce dernier utilisera moins de nœuds que ceux qui annoncent l'adresse IP.
Par exemple, si la politique de trafic externe est définie sur local et que le routeur a une limite de groupe ECMP définie sur 16 et que les pods implémentant un service LoadBalancer sont déployés sur 30 nœuds, les pods déployés sur 14 nœuds ne recevront pas de trafic. Dans cette situation, il serait préférable de définir la politique de trafic externe pour le service sur cluster.
32.1.5. Concepts MetalLB pour le mode couche 2
En mode couche 2, le pod speaker d'un nœud annonce l'adresse IP externe d'un service au réseau hôte. Du point de vue du réseau, le nœud semble avoir plusieurs adresses IP attribuées à une interface réseau.
Comme le mode couche 2 repose sur ARP et NDP, le client doit se trouver sur le même sous-réseau que les nœuds annonçant le service pour que la MetalLB fonctionne. En outre, l'adresse IP attribuée au service doit se trouver sur le même sous-réseau que le réseau utilisé par le client pour accéder au service.
Le pod speaker répond aux demandes ARP pour les services IPv4 et aux demandes NDP pour IPv6.
En mode couche 2, tout le trafic pour une adresse IP de service est acheminé via un seul nœud. Une fois le trafic entré dans le nœud, le proxy de service du fournisseur de réseau CNI distribue le trafic à tous les pods du service.
Comme tout le trafic d'un service passe par un seul nœud en mode couche 2, MetalLB n'implémente pas, au sens strict, d'équilibreur de charge pour la couche 2. MetalLB met plutôt en œuvre un mécanisme de basculement pour la couche 2 de sorte que lorsqu'un pod speaker devient indisponible, un pod speaker sur un autre nœud peut annoncer l'adresse IP du service.
Lorsqu'un nœud devient indisponible, le basculement est automatique. Les pods speaker sur les autres nœuds détectent qu'un nœud est indisponible et un nouveau pod speaker et un nouveau nœud prennent possession de l'adresse IP de service du nœud défaillant.
Le graphique précédent illustre les concepts suivants liés à la MetalLB :
-
Une application est disponible par le biais d'un service qui possède une adresse IP de cluster sur le sous-réseau
172.130.0.0/16. Cette adresse IP est accessible depuis l'intérieur du cluster. Le service dispose également d'une adresse IP externe que MetalLB lui a attribuée,192.168.100.200. - Les nœuds 1 et 3 disposent d'un pod pour l'application.
-
Le jeu de démons
speakerexécute un pod sur chaque nœud. L'opérateur MetalLB démarre ces pods. -
Chaque module
speakerest un module en réseau hôte. L'adresse IP du module est identique à l'adresse IP du nœud sur le réseau hôte. -
Le pod
speakersur le nœud 1 utilise ARP pour annoncer l'adresse IP externe du service,192.168.100.200. Le modulespeakerqui annonce l'adresse IP externe doit se trouver sur le même nœud qu'un point de terminaison du service et le point de terminaison doit être dans l'étatReady. Le trafic du client est acheminé vers le réseau hôte et se connecte à l'adresse IP
192.168.100.200. Une fois que le trafic entre dans le nœud, le proxy de service envoie le trafic au module d'application sur le même nœud ou sur un autre nœud, conformément à la stratégie de trafic externe que vous avez définie pour le service.-
Si la stratégie de trafic externe pour le service est définie sur
cluster, le nœud qui annonce l'adresse IP de l'équilibreur de charge192.168.100.200est sélectionné parmi les nœuds où un podspeakerest en cours d'exécution. Seul ce nœud peut recevoir du trafic pour le service. -
Si la politique de trafic externe pour le service est définie sur
local, le nœud qui annonce l'adresse IP de l'équilibreur de charge192.168.100.200est sélectionné parmi les nœuds où un podspeakerest en cours d'exécution et au moins un point d'extrémité du service. Seul ce nœud peut recevoir du trafic pour le service. Dans le graphique précédent, le nœud 1 ou 3 annoncerait192.168.100.200.
-
Si la stratégie de trafic externe pour le service est définie sur
-
Si le nœud 1 devient indisponible, l'adresse IP externe bascule sur un autre nœud. Sur un autre nœud disposant d'une instance du module d'application et du point de terminaison du service, le module
speakercommence à annoncer l'adresse IP externe,192.168.100.200, et le nouveau nœud reçoit le trafic du client. Dans le diagramme, le seul candidat est le nœud 3.
32.1.6. Concepts MetalLB pour le mode BGP
En mode BGP, par défaut, chaque pod speaker annonce l'adresse IP de l'équilibreur de charge pour un service à chaque pair BGP. Il est également possible d'annoncer les IP provenant d'un pool donné à un ensemble spécifique de pairs en ajoutant une liste optionnelle de pairs BGP. Les homologues BGP sont généralement des routeurs de réseau configurés pour utiliser le protocole BGP. Lorsqu'un routeur reçoit du trafic pour l'adresse IP de l'équilibreur de charge, il choisit l'un des nœuds avec un pod speaker qui a annoncé l'adresse IP. Le routeur envoie le trafic à ce nœud. Une fois le trafic entré dans le nœud, le proxy de service pour le plugin de réseau CNI distribue le trafic à tous les pods du service.
Le routeur directement connecté sur le même segment de réseau de couche 2 que les nœuds de cluster peut être configuré en tant qu'homologue BGP. Si le routeur directement connecté n'est pas configuré comme homologue BGP, vous devez configurer votre réseau de manière à ce que les paquets destinés aux adresses IP de l'équilibreur de charge soient acheminés entre les homologues BGP et les nœuds de cluster qui exécutent les pods speaker.
Chaque fois qu'un routeur reçoit un nouveau trafic pour l'adresse IP de l'équilibreur de charge, il crée une nouvelle connexion avec un nœud. Chaque fabricant de routeurs dispose d'un algorithme spécifique pour choisir le nœud avec lequel établir la connexion. Toutefois, les algorithmes sont généralement conçus pour répartir le trafic entre les nœuds disponibles afin d'équilibrer la charge du réseau.
Si un nœud devient indisponible, le routeur établit une nouvelle connexion avec un autre nœud doté d'un pod speaker qui annonce l'adresse IP de l'équilibreur de charge.
Figure 32.1. Schéma topologique de la MetalLB en mode BGP
Le graphique précédent illustre les concepts suivants liés à la MetalLB :
-
Une application est disponible par l'intermédiaire d'un service qui possède une adresse IP IPv4 sur le sous-réseau
172.130.0.0/16. Cette adresse IP est accessible depuis l'intérieur du cluster. Le service dispose également d'une adresse IP externe que MetalLB lui a attribuée,203.0.113.200. - Les nœuds 2 et 3 disposent d'un pod pour l'application.
-
Le jeu de démons
speakerexécute un pod sur chaque nœud. L'opérateur MetalLB démarre ces pods. Vous pouvez configurer MetalLB pour spécifier les nœuds qui exécutent les podsspeaker. -
Chaque module
speakerest un module en réseau hôte. L'adresse IP du module est identique à l'adresse IP du nœud sur le réseau hôte. -
Chaque pod
speakerdémarre une session BGP avec tous les pairs BGP et annonce les adresses IP de l'équilibreur de charge ou les routes agrégées aux pairs BGP. Les modulesspeakerannoncent qu'ils font partie du système autonome 65010. Le diagramme montre un routeur, R1, en tant que pair BGP au sein du même système autonome. Cependant, vous pouvez configurer MetalLB pour démarrer des sessions BGP avec des pairs appartenant à d'autres systèmes autonomes. Tous les nœuds dotés d'un pod
speakerqui annonce l'adresse IP de l'équilibreur de charge peuvent recevoir du trafic pour le service.-
Si la stratégie de trafic externe pour le service est définie sur
cluster, tous les nœuds où un pod de haut-parleur est en cours d'exécution annoncent l'adresse IP de l'équilibreur de charge203.0.113.200et tous les nœuds avec un podspeakerpeuvent recevoir du trafic pour le service. Le préfixe de l'hôte n'est annoncé au routeur pair que si la stratégie de trafic externe est définie sur cluster. -
Si la stratégie de trafic externe pour le service est définie sur
local, tous les nœuds où un podspeakerest en cours d'exécution et où au moins un point d'extrémité du service est en cours d'exécution peuvent annoncer l'adresse IP de l'équilibreur de charge203.0.113.200. Seuls ces nœuds peuvent recevoir du trafic pour le service. Dans le graphique précédent, les nœuds 2 et 3 annonceraient203.0.113.200.
-
Si la stratégie de trafic externe pour le service est définie sur
-
Vous pouvez configurer MetalLB pour contrôler les pods
speakerqui démarrent des sessions BGP avec des pairs BGP spécifiques en spécifiant un sélecteur de nœud lorsque vous ajoutez une ressource personnalisée de pair BGP. - Tous les routeurs, tels que R1, qui sont configurés pour utiliser BGP peuvent être définis comme homologues BGP.
- Le trafic du client est acheminé vers l'un des nœuds du réseau hôte. Une fois que le trafic entre dans le nœud, le proxy de service envoie le trafic au module d'application sur le même nœud ou sur un autre nœud en fonction de la stratégie de trafic externe que vous avez définie pour le service.
- Si un nœud devient indisponible, le routeur détecte la défaillance et établit une nouvelle connexion avec un autre nœud. Vous pouvez configurer MetalLB pour qu'il utilise un profil BFD (Bidirectional Forwarding Detection) pour les pairs BGP. BFD permet une détection plus rapide des défaillances de liaison, de sorte que les routeurs peuvent initier de nouvelles connexions plus tôt que sans BFD.
32.1.7. Limites et restrictions
32.1.7.1. Considérations relatives à l'infrastructure pour MetalLB
MetalLB est principalement utile pour les installations sur site, bare metal, car ces installations n'incluent pas de capacité native de load-balancer. En plus des installations bare metal, les installations d'OpenShift Container Platform sur certaines infrastructures peuvent ne pas inclure une capacité native de load-balancer. Par exemple, les infrastructures suivantes peuvent bénéficier de l'ajout de l'opérateur MetalLB :
- Métal nu
- VMware vSphere
MetalLB Operator et MetalLB sont pris en charge par les fournisseurs de réseaux OpenShift SDN et OVN-Kubernetes.
32.1.7.2. Limites du mode couche 2
32.1.7.2.1. Goulot d'étranglement à nœud unique
MetalLB achemine tout le trafic d'un service via un seul nœud, qui peut devenir un goulot d'étranglement et limiter les performances.
Le mode couche 2 limite la bande passante d'entrée de votre service à la bande passante d'un seul nœud. Il s'agit d'une limitation fondamentale de l'utilisation de l'ARP et du NDP pour diriger le trafic.
32.1.7.2.2. Lenteur du basculement
Le basculement entre les nœuds dépend de la coopération des clients. Lorsqu'un basculement se produit, MetalLB envoie des paquets ARP gratuits pour notifier aux clients que l'adresse MAC associée à l'IP de service a changé.
La plupart des systèmes d'exploitation clients traitent correctement les paquets ARP gratuits et mettent rapidement à jour leurs caches de voisins. Lorsque les clients mettent à jour leurs caches rapidement, le basculement s'effectue en quelques secondes. Les clients basculent généralement vers un nouveau nœud en moins de 10 secondes. Toutefois, certains systèmes d'exploitation clients ne traitent pas du tout les paquets ARP gratuits ou ont des implémentations obsolètes qui retardent la mise à jour du cache.
Les versions récentes des systèmes d'exploitation courants tels que Windows, macOS et Linux implémentent correctement le basculement de couche 2. Il ne faut pas s'attendre à des problèmes de basculement lent, sauf pour les systèmes d'exploitation clients plus anciens et moins courants.
Pour minimiser l'impact d'un basculement planifié sur les clients obsolètes, laissez l'ancien nœud fonctionner pendant quelques minutes après le basculement de la direction. L'ancien nœud peut continuer à transmettre le trafic des clients obsolètes jusqu'à ce que leurs caches soient rafraîchis.
Lors d'un basculement non planifié, les IP de service sont inaccessibles jusqu'à ce que les clients obsolètes rafraîchissent leurs entrées de cache.
32.1.7.3. Limitations du mode BGP
32.1.7.3.1. La défaillance d'un nœud peut interrompre toutes les connexions actives
MetalLB partage une limitation commune à l'équilibrage de charge basé sur BGP. Lorsqu'une session BGP se termine, par exemple en cas de défaillance d'un nœud ou de redémarrage d'un pod speaker, la fin de la session peut entraîner la réinitialisation de toutes les connexions actives. Les utilisateurs finaux peuvent recevoir un message Connection reset by peer.
La conséquence d'une session BGP terminée est spécifique à l'implémentation de chaque fabricant de routeurs. Cependant, vous pouvez prévoir qu'un changement dans le nombre de pods speaker affecte le nombre de sessions BGP et que les connexions actives avec les pairs BGP seront interrompues.
Pour éviter ou réduire la probabilité d'une interruption de service, vous pouvez spécifier un sélecteur de nœud lorsque vous ajoutez un homologue BGP. En limitant le nombre de nœuds qui démarrent des sessions BGP, une défaillance sur un nœud qui n'a pas de session BGP n'a pas d'incidence sur les connexions au service.
32.1.7.3.2. Prise en charge d'un seul ASN et d'un seul ID de routeur uniquement
Lorsque vous ajoutez une ressource personnalisée BGP peer, vous spécifiez le champ spec.myASN pour identifier le numéro de système autonome (ASN) auquel MetalLB appartient. OpenShift Container Platform utilise une implémentation de BGP avec MetalLB qui exige que MetalLB appartienne à un seul ASN. Si vous tentez d'ajouter un pair BGP et que vous spécifiez une valeur différente pour spec.myASN par rapport à une ressource personnalisée de pair BGP existante, vous recevez une erreur.
De même, lorsque vous ajoutez une ressource personnalisée d'homologue BGP, le champ spec.routerID est facultatif. Si vous spécifiez une valeur pour ce champ, vous devez spécifier la même valeur pour toutes les autres ressources personnalisées d'homologue BGP que vous ajoutez.
La limitation à la prise en charge d'un seul ASN et d'un seul ID de routeur est une différence par rapport à la mise en œuvre de MetalLB soutenue par la communauté.
