Panoramica di MetalLB per i cluster Kubernetes
Si applica a: Azure Stack HCI, versione 23H2
Quando si configura il cluster Arc del servizio Azure Kubernetes, è necessario un modo per rendere i servizi accessibili all'esterno del cluster. Il LoadBalancer
tipo è ideale per questa accessibilità, ma l'indirizzo IP esterno rimane in sospeso. L'estensione MetalLB Arc è uno strumento che consente di generare indirizzi IP esterni per le applicazioni e i servizi. I cluster Kubernetes abilitati per Arc possono integrarsi con MetalLB usando l'estensione Arc Networking
k8s.
Per rendere i servizi accessibili all'esterno del cluster, MetalLB necessita di indirizzi IP. MetalLB si occupa dell'assegnazione e del rilascio di questi indirizzi in base alle esigenze quando si creano servizi, ma distribuisce solo gli indirizzi IP presenti nei pool configurati. Quando MetalLB assegna un indirizzo IP esterno a un servizio, informa la rete esterna al cluster che questo IP appartiene al cluster. Questa comunicazione viene eseguita usando protocolli di rete standard come ARP o BGP.
- Modalità livello 2 (ARP): nella modalità di livello 2, un nodo K8s nel cluster acquisisce la proprietà del servizio e usa protocolli di individuazione degli indirizzi standard (ARP per IPv4) per rendere raggiungibili tali indirizzi IP nella rete locale. Dal punto di vista della LAN, il computer che annuncia semplicemente ha più indirizzi IP.
- BGP: in modalità BGP, tutti i computer del cluster stabiliscono sessioni di peering BGP con router vicini che si controllano e indicano ai router come inoltrare il traffico agli INDIRIZZI IP del servizio. L'uso di BGP consente il bilanciamento del carico vero tra più nodi e il controllo del traffico con granularità fine a causa dei meccanismi dei criteri BGP.
MetalLB ha due componenti:
- Controller: responsabile dell'allocazione dell'indirizzo IP per ogni servizio di
type=loadbalancer
. - Relatore: responsabile della pubblicità dell'IP tramite
ARP
oBGP
del protocollo. Per soddisfare il requisito di disponibilità elevata, la distribuzione del parlante è un daemonset.
Nota
- I pod voce usano la rete host; Ad esempio, il loro IP è l'IP del nodo, in modo che possano inviare direttamente messaggi trasmessi tramite l'interfaccia di rete host.
- Il pod controller è un pod normale che si trova in qualsiasi nodo del cluster.
- In modalità ARP, uno dei pod altoparlanti viene selezionato come leader. Annuncia quindi l'IP usando un messaggio di trasmissione ARP, associando l'IP con l'indirizzo MAC del nodo in cui risiede. Di conseguenza, tutto il traffico raggiunge prima un nodo e quindi kube-proxy lo distribuisce uniformemente a tutti i pod back-end del servizio.
- In modalità BGP tutti i nodi del cluster stabiliscono connessioni con tutti i peer BGP creati nella
BGP Peers
scheda. In genere un peer BGP è un commutatore TOR. Per trasmettere le informazioni di routing BGP, i peer BGP devono essere configurati in modo che riconoscano l'IP e l'ASN dei nodi del cluster. Quando si usa BGP con ECMP (Equal-Cost MultiPath), il traffico raggiunge in modo uniforme tutti i nodi e quindi ottiene un vero bilanciamento del carico.
Confrontare le modalità ARP (MetalLB L2) e BGP
La scelta tra la modalità L2 e BGP con MetalLB dipende dai requisiti specifici, dall'infrastruttura di rete e dagli scenari di distribuzione:
Aspetto | MetalLB in modalità L2 (ARP) | MetalLB in modalità BGP |
---|---|---|
Panoramica | In modalità livello 2, un nodo K8s assume la responsabilità di pubblicizzare un servizio alla rete locale. Dal punto di vista della rete, sembra che il nodo K8s abbia più indirizzi IP assegnati alla relativa interfaccia di rete. | In modalità BGP ogni nodo K8s del cluster stabilisce una sessione di peering BGP con i router di rete e usa tale sessione di peering per annunciare gli INDIRIZZI IP dei servizi cluster esterni. |
Assegnazione indirizzi IP | I pool di indirizzi IP EseguiLB devono trovarsi nella stessa subnet dei nodi K8s. | I pool di indirizzi IP di Eseguire bilanciamento del carico di rete possono trovarsi in una rete diversa rispetto ai nodi K8s. |
Complessità della configurazione | Basso. Poiché si forniscono indirizzi IP nella stessa rete dei nodi Kubernetes, è sufficiente specificare un CIDR IP o un pool IP durante la configurazione di MetalLB. | Elevato. La configurazione di BGP richiede la conoscenza del protocollo BGP e la comprensione dell'infrastruttura di rete. |
Scalabilità | Limitato alle reti di livello 2, adatte per distribuzioni K8 di piccole e medie dimensioni. | Adatto per topologie di rete complesse e distribuzioni K8s su larga scala. |
Compatibilità con la rete dell'infrastruttura | Funziona con qualsiasi rete, ma può causare inondazioni ARP in cluster K8s di grandi dimensioni, poiché viene usato un singolo IP per tutti i servizi e la larghezza di banda in ingresso del servizio è limitata alla larghezza di banda di un singolo nodo. | Richiede il supporto BGP nell'infrastruttura di rete. |
Progettazione del traffico | Controllo limitato sul routing del traffico. | Controllo con granularità fine sul routing del traffico tramite attributi BGP. |
Connettività esterna | Richiede più configurazione per la connettività esterna. | Offre connettività senza problemi con reti esterne tramite il routing BGP. |
Domande frequenti
È possibile riutilizzare un'istanza di MetalLB nei cluster Arc del servizio Azure Kubernetes?
No, MetalLB non può essere riutilizzato nei cluster arc del servizio Azure Kubernetes. MetalLB risiede come pod in un cluster Kubernetes e i servizi di bilanciamento del carico sono risorse personalizzate (CR). È necessario installare l'estensione MetalLB Arc k8s usando l'interfaccia della riga di comando di Azure, i modelli di portale di Azure o Azure Resource Manager e creare servizi di bilanciamento del carico per ogni cluster del servizio Azure Kubernetes Arc.