Questa pagina descrive come configurare il bilanciamento del carico in bundle con MetalLB per Google Distributed Cloud. I bilanciatori del carico MetalLB vengono eseguiti su un pool dedicato nodi worker o sugli stessi nodi del piano di controllo.
Consulta la Panoramica dei bilanciatori del carico per esempi di topologie di bilanciamento del carico disponibili in Google Distributed Cloud.
Requisiti
- Tutti i nodi del bilanciatore del carico devono trovarsi nella stessa subnet di livello 2.
- Tutti i VIP devono trovarsi nella subnet dei nodi del bilanciatore del carico ed essere instradabili attraverso il gateway della subnet.
- Il gateway della subnet del bilanciatore del carico deve ascoltare messaggi ARP gratuiti e inoltrare i pacchetti ARP ai nodi del bilanciatore del carico.
Campi di configurazione
Modifica la sezione cluster.spec.loadBalancer
del file di configurazione del cluster
per configurare il bilanciamento del carico in bundle. Per informazioni sui cluster
di configurazione ed esempi di configurazioni valide, consulta uno dei
pagine seguenti:
loadBalancer.mode
Questo valore deve essere bundled
per abilitare il bilanciamento del carico in bundle.
loadBalancer.ports.controlPlaneLBPort
Questo valore specifica la porta di destinazione da utilizzare per il traffico inviato al server il piano di controllo Kubernetes (i server API Kubernetes).
loadBalancer.vips.controlPlaneVIP
Questo valore specifica l'indirizzo IP di destinazione da utilizzare per il traffico inviato a
il piano di controllo Kubernetes (i server API Kubernetes). Questo indirizzo IP deve
devono trovarsi nella stessa subnet di livello 2 dei nodi nel cluster. Non elencare
nella sezione address pools
della
.
loadBalancer.vips.ingressVIP
Questo valore specifica l'indirizzo IP da utilizzare per i servizi dietro il carico per il traffico in entrata. Questo campo non è consentito in admin cluster di configurazione dei deployment. Questo indirizzo deve essere indicato nella pool della configurazione.
loadBalancer.addressPools
Questa sezione della configurazione contiene uno o più pool di indirizzi. Ciascuna
il pool di indirizzi specifica un elenco di intervalli di indirizzi IP. Quando crei un
Servizio di tipo LoadBalancer
,
gli indirizzi IP esterni per il servizio vengono scelti da questi intervalli.
I pool di indirizzi sono specificati nel seguente formato:
- name: POOL_NAME
avoidBuggyIPs: BOOLEAN
manualAssign: BOOLEAN
addresses:
- IP_RANGE
- IP_RANGE2
name
: il nome del pool di indirizzi, pool-name, del tuo per scopi organizzativi. Questo campo è immutabile.avoidBuggyIPs
: (facoltativo)true
ofalse
. Setrue
, nel pool ometti gli indirizzi IP che terminano con.0
e.255
. Alcuni cali dell'hardware di rete il traffico verso questi indirizzi speciali. Puoi omettere questo campo, il relativo valore predefinito èfalse
. Questo campo è modificabile.manualAssign
: (facoltativo)true
ofalse
. Setrue
, di indirizzi IP in questo pool non vengono assegnati automaticamente ai servizi Kubernetes. Setrue
, un indirizzo IP in questo pool viene utilizzato solo quando specificato esplicitamente da un servizio. Puoi omettere questo campo, il suo valore predefinito èfalse
. Questo campo è modificabile.addresses
Un elenco di uno o più intervalli di indirizzi IP non sovrapposti. ip-range può essere specificato in notazione CIDR (come198.51.100.0/24
) o la notazione di intervallo (ad es.198.51.100.0-198.51.100.10
, con senza spazi attorno al trattino). Questo campo è immutabile.
Gli intervalli di indirizzi IP nell'elenco addresses
non devono sovrapporsi e devono trovarsi
la stessa subnet dei nodi che eseguono bilanciatori del carico.
loadBalancer.nodePoolSpec
Questa sezione della configurazione specifica un elenco di nodi su cui eseguire il carico bilanciatori del carico. I nodi dei bilanciatori del carico possono eseguire carichi di lavoro regolari per impostazione predefinita; c'è nessuna incompatibilità speciale sui nodi. Anche se i nodi nel pool di nodi del bilanciatore del carico di carichi di lavoro, sono separati dai nodi nei pool di nodi worker. Tu non può includere un determinato nodo cluster in più di un pool di nodi. Nodo sovrapposto Gli indirizzi IP tra i pool di nodi bloccano la creazione del cluster e un altro cluster operazioni.
Se vuoi impedire l'esecuzione dei carichi di lavoro su un nodo nel bilanciatore del carico di pool di nodi, aggiungi la seguente incompatibilità al nodo:
node-role.kubernetes.io/load-balancer:NoSchedule
Google Distributed Cloud aggiunge tolleranze per questa incompatibilità ai pod richiesti per il bilanciamento del carico.
nodePoolSpec:
nodes:
- address: 10.0.0.32
- address: 10.0.0.33
Tutti i nodi nel pool di nodi del bilanciatore del carico devono trovarsi nella stessa subnet di livello 2
i VIP del bilanciatore del carico configurati
loadBalancer.addressPools
del file di configurazione.
Se nodePoolSpec
non è impostato, i bilanciatori del carico in bundle vengono eseguiti sul controllo
nodi del piano. Ti consigliamo di eseguire i bilanciatori del carico su pool di nodi separati se
possibile.
Bilanciamento del carico del piano di controllo
Il bilanciatore del carico del piano di controllo gestisce l'indirizzo IP virtuale del piano di controllo (VIP). Google Distributed Cloud esegue KeepaLive e HAProxy come pod statici Kubernetes nodi del bilanciatore del carico per annunciare il VIP del piano di controllo. KeepaLive utilizza lo standard Virtual Router Redundancy Protocol (VRRP) sui nodi del bilanciatore del carico per la disponibilità del servizio.
Bilanciamento del carico del piano dati
Il bilanciatore del carico del piano dati è per tutti i servizi Kubernetes di tipo
LoadBalancer
Google Distributed Cloud utilizza MetalLB
in esecuzione in modalità di livello 2 per il bilanciamento del carico del piano dati. Bilanciamento del carico del piano dati
può essere configurato solo tramite Google Distributed Cloud, non modificare MetalLB
ConfigMap. Puoi usare tutte le caratteristiche di MetalLB, tra cui
Condivisione degli indirizzi IP tra i servizi.
Per informazioni sulle funzionalità, consulta la documentazione MetalLB.
MetalLB esegue un pod dello speaker su ciascun nodo utilizzando un daemonset, utilizzando elenco membri per garantire l'alta disponibilità. C'è un nodo del bilanciatore del carico dedicato MetalLB per Kubernetes, anziché uno per l'intero cluster. In questo modo il traffico viene distribuiti nei nodi dei bilanciatori del carico se sono presenti più servizi.
I bilanciatori del carico del piano dati possono essere eseguiti sui nodi del piano di controllo o su un sottoinsieme di nodi worker. Raggruppamento dei bilanciatori del carico del piano dati sul aumenta l'utilizzo dei nodi del piano di controllo. Tuttavia, Il raggruppamento dei nodi del piano di controllo aumenta anche il rischio di sovraccaricare piano di controllo e aumenta il profilo di rischio delle informazioni riservate di controllo, come le chiavi SSH.
Conservazione dell'indirizzo IP di origine del client
Il servizio LoadBalancer
creato con il bilanciamento del carico di livello 2 in bundle
usa l'impostazione Cluster
predefinita per il criterio del traffico esterno.
Questa impostazione, spec.externalTrafficPolicy: Cluster
, instrada il traffico esterno a
a livello di cluster, ma oscura anche l'indirizzo IP di origine del client.
Le sezioni seguenti descrivono come configurare il cluster per conservare l'indirizzo IP di origine del client.
Servizi NodePort
Kubernetes esegue Network Address Translation (NAT) di origine per NodePort
Servizi. Per conservare gli indirizzi IP di origine client, imposta
Da service.spec.externalTrafficPolicy
a Local
. Kubernetes non eseguirà l'esecuzione
NAT di più, ma devi assicurarti che siano presenti pod in esecuzione esattamente sul nodo
Indirizzo IP selezionato.
Servizi LoadBalancer
Quando utilizzi externalTrafficPolicy: Local
nei tuoi servizi LoadBalancer
, imposta
i pod dell'applicazione in modo che vengano eseguiti esattamente sui nodi del bilanciatore del carico. Aggiungi il parametro
seguenti nodeSelector
ai pod dell'applicazione per apportare questa modifica:
apiVersion: v1
kind: Pod
...
spec:
nodeSelector:
baremetal.cluster.gke.io/lbnode: "true"
...
In entrata
Se le tue applicazioni sono servizi HTTP, puoi ottenere la visibilità dell'IP del client configurando i componenti in entrata:
Apri il servizio
istio-ingress
per la modifica:kubectl edit service -n gke-system istio-ingress
Aggiungi
externalTrafficPolicy: Local
aspec
, salva ed esci da dell'editor.apiVersion: v1 kind: Service ... spec: ... externalTrafficPolicy: Local
Apri il deployment
istio-ingress
da modificare:kubectl edit deployment -n gke-system istio-ingress
Aggiungi il seguente
nodeSelector
al deployment, salva ed esci da dell'editor.apiVersion: apps/v1 kind: Deployment ... spec: ... template: ... spec: ... nodeSelector: baremetal.cluster.gke.io/lbnode: "true" ...
Ora, tutti i tuoi servizi dietro Ingress vedono un'intestazione X-Forwarded-For
con
come nell'esempio seguente:
X-Forwarded-For: 21.0.104.4