Questo documento descrive come configurare e utilizzare i bilanciatori del carico in bundle con Border
Gateway Protocol (BGP) per Cluster Anthos on bare metal. Questa modalità di bilanciamento del carico supporta la pubblicità di ServiceType
LoadBalancer
indirizzi IP virtuali (VIP) tramite protocollo Border Gateway Protocol (eBGP) esterno per i cluster. In questo scenario, la rete del cluster è un sistema autonomo, che si interconnette con un altro sistema autonomo, una rete esterna, tramite peering.
I bilanciatori del carico in bundle con funzionalità BGP si applicano a tutti i tipi di cluster, ma i cluster di amministrazione supportano solo la parte del bilanciamento del carico del piano di controllo.
L'utilizzo dei bilanciatori del carico in bundle con la funzionalità BGP offre i seguenti vantaggi:
- Utilizza la capacità di bilanciamento del carico attiva/attiva N/way, che consente di eseguire il failover più rapidamente e di utilizzare in modo più efficiente la larghezza di banda disponibile.
- Supporta il protocollo Layer 3 che funziona con interruttori top-of-rack (ToR) di terze parti e router compatibili con eBGP.
- Consente i data center che eseguono uno stack di rete software-defined (SDN) avanzato di eseguire il push dei confini di livello 3 nei cluster.
Come funziona il bilanciamento del carico in bundle con BGP
Le seguenti sezioni forniscono un breve riepilogo del funzionamento dei bilanciatori del carico in bundle con BGP.
Peering BGP
Il bilanciatore del carico in bundle con funzionalità BGP avvia diverse connessioni BGP all'infrastruttura. BGP ha i seguenti requisiti tecnici:
- Le sessioni di peering sono separate per il VIP del piano di controllo e per i VIP del servizio.
- Le sessioni di peering del piano di controllo vengono avviate dagli indirizzi IP dei nodi del piano di controllo.
- Le sessioni di peering di servizio vengono avviate dagli indirizzi IP mobili che hai specificato nella risorsa personalizzata
NetworkGatewayGroup
. - Il controller Anthos Network Gateway gestisce gli indirizzi IP mobili.
- Il bilanciamento del carico basato su BGP in bundle supporta solo il peering eBGP.
- Il peering multi-hop è supportato per impostazione predefinita.
- Le password MD5 nelle sessioni BGP non sono supportate.
- Le sessioni di peering basate su IPv6 non sono supportate.
- Le route annunciate a qualsiasi peer devono essere ridistribuite in tutta la rete e raggiungibili da qualsiasi altro punto del cluster.
- Per le sessioni in peering è consigliato l'utilizzo della funzionalità BGP
ADD-PATH
in modalità di ricezione. - La promozione di più percorsi di ogni peer comporta il bilanciamento del carico attivo/attivo.
- Il routing ECMP (Equal-cost multipath) deve essere abilitato per la tua rete, in modo da poter utilizzare più percorsi per distribuire il traffico in un insieme di nodi del bilanciatore del carico.
Bilanciamento del carico del piano di controllo
Ogni nodo del piano di controllo nel tuo cluster stabilisce le sessioni BGP con uno o più peer nella tua infrastruttura. È necessario che ogni nodo del piano di controllo abbia almeno un peer. Nel file di configurazione del cluster, puoi configurare quali nodi del piano di controllo si connettono a quali peer esterni.
Lo schema seguente mostra un esempio di peering del piano di controllo. Il cluster ha due nodi del piano di controllo in una subnet e uno in un'altra. In ogni subnet e in Cluster Anthos del piano di controllo Bare Metal è presente un peer esterno (TOR) con il TOR.
Bilanciamento del carico del servizio
Oltre alle sessioni di peering avviate da ciascun nodo del piano di controllo per il peering del piano di controllo, vengono avviate sessioni di peering aggiuntive per i Servizi LoadBalancer
. Queste sessioni di peering non vengono avviate direttamente dagli IP dei nodi del cluster, ma utilizzano IP mobili.
I servizi con un criterio di rete externalTrafficPolicy=Local
non sono supportati.
Indirizzi IP mobili
Il bilanciamento del carico del servizio richiede la prenotazione di indirizzi IP mobili nelle subnet dei nodi del cluster da utilizzare per il peering BGP. Per il cluster è richiesto almeno un indirizzo IP mobile, ma consigliamo di prenotare almeno due indirizzi per garantire l'alta disponibilità per le sessioni BGP. Gli indirizzi IP mobili sono specificati nella risorsa personalizzata (CR) NetworkGatewayGroup
, che può essere inclusa nel file di configurazione del cluster.
Gli indirizzi IP mobili eliminano la preoccupazione di mappare gli indirizzi IP degli speaker BGP ai nodi. Il controller Anthos Network Gateway si occupa dell'assegnazione di NetworkGatewayGroup
ai nodi e gestisce anche gli indirizzi IP mobili. Se un nodo non funziona, il controller Anthos Network Gateway riassegna
gli indirizzi IP mobili per garantire che i peer esterni abbiano un indirizzo
deterministico con cui eseguire il peering.
peer esterni
Per il bilanciamento del carico del piano dati, puoi utilizzare gli stessi peer esterni specificati per il peering del piano di controllo nella sezione loadBalancer.controlPlaneBGP
del file di configurazione del cluster. In alternativa, puoi specificare diversi peer BGP.
Se vuoi specificare peer BGP diversi per il peering del piano dati, aggiungi le specifiche delle risorse BGPLoadBalancer
e BGPPeer
al file di configurazione del cluster. Se non specifichi queste risorse personalizzate, i peer del piano di controllo vengono utilizzati automaticamente per il piano dati.
Specifica i peer esterni utilizzati per le sessioni di peering con gli indirizzi IP mobili nella risorsa personalizzata BGPPeer
, che aggiungi al file di configurazione del cluster. La risorsa BGPPeer
include un'etichetta per l'identificazione da parte della risorsa personalizzata BGPLoadBalancer
corrispondente. Devi specificare l'etichetta corrispondente nel campo peerSelector
nella risorsa personalizzata BGPLoadBalancer
per selezionare l'elemento BGPPeer
da utilizzare.
Il controller Gateway di rete Anthos tenta di stabilire le sessioni (il numero di sessioni è configurabile) a ogni peer esterno dal set di indirizzi IP mobili prenotati. Ti consigliamo di specificare almeno due peer esterni per garantire l'alta disponibilità per le sessioni BGP. Ogni peer esterno designato per il bilanciamento del carico dei servizi deve essere configurato per il peering con ogni indirizzo IP mobile specificato nella risorsa personalizzata NetworkGatewayGroup
.
Nodi bilanciatore del carico
Per il bilanciamento del carico viene utilizzato un sottoinsieme di nodi del cluster, ovvero i nodi pubblicizzati per poter accettare il traffico di bilanciamento del carico in entrata.
Per impostazione predefinita, questo insieme di nodi corrisponde al pool di nodi del piano di controllo, ma puoi specificare un pool di nodi diverso nella sezione loadBalancer
del file di configurazione del cluster. Se specifichi un pool di nodi, questo viene utilizzato per i nodi del bilanciatore del carico, anziché per il pool di nodi del piano di controllo.
Gli indirizzi IP mobili, che funzionano come altoparlanti BGP, possono o meno essere eseguiti sui nodi del bilanciatore del carico. Gli indirizzi IP mobili vengono assegnati a un nodo nella stessa subnet, da cui viene avviato il peering, indipendentemente dal fatto che si tratti di un nodo del bilanciatore del carico. Tuttavia, gli hop successivi pubblicizzati tramite BGP sono sempre i nodi del bilanciatore del carico.
Esempio di topologia di peering
Il seguente diagramma mostra un esempio di bilanciamento del carico del servizio con peering BGP. Ci sono due indirizzi IP mobili assegnati ai nodi nelle rispettive subnet. Sono definiti due peer esterni. Ogni peer IP mobile è dotato di peer esterni.
Configura il bilanciatore del carico BGP
Le seguenti sezioni descrivono come configurare i cluster e la rete esterna per l'utilizzo del bilanciatore del carico in bundle con BGP.
Pianifica l'integrazione con un'infrastruttura esterna
Per utilizzare il bilanciatore del carico in bundle con BGP, devi configurare l'infrastruttura esterna:
Per configurare la comunicazione del piano di controllo, è necessario configurare l'infrastruttura esterna in modo che esegua il peering con ciascuno dei nodi del piano di controllo nel cluster. Queste sessioni di peering vengono utilizzate per pubblicizzare i VIP del piano di controllo Kubernetes.
L'infrastruttura esterna deve essere configurata per il peering con un insieme di indirizzi IP mobili prenotati per la comunicazione del piano dati. Gli indirizzi IP mobili vengono utilizzati per il peering BGP per i VIP del servizio. Ti consigliamo di utilizzare due indirizzi IP mobili e due peer per garantire l'alta disponibilità per le sessioni BGP. Il processo di prenotazione dell'IP mobile è descritto come parte della configurazione del cluster per il bilanciamento del carico in bundle con BGP.
Dopo aver configurato l'infrastruttura, aggiungi le informazioni sul peering BGP al file di configurazione del cluster. Il cluster creato può avviare sessioni di peering con l'infrastruttura esterna.
Configura il cluster per il bilanciamento del carico in bundle con BGP
Abilita e configura il bilanciamento del carico in bundle con BGP nel file di configurazione del cluster quando crei un cluster. Nel file di configurazione del cluster, abiliti il networking avanzato e aggiorna la sezione loadBalancer
. Aggiungi le specifiche anche per le seguenti tre risorse personalizzate:
NetworkGatewayGroup
: specifica gli indirizzi IP mobili utilizzati per le sessioni di peering BGP dei servizi.BGPLoadBalancer
: specifica con i selettori di etichette quali peer vengono utilizzati per il bilanciamento del carico BGP.BGPPeer
: specifica singoli peer, inclusa un'etichetta per scopi di selezione, per le sessioni di peering BGP.
Le seguenti istruzioni descrivono come configurare il cluster e le tre risorse personalizzate per configurare il bilanciamento del carico in bundle con BGP.
Aggiungi il campo
advancedNetworking
al file di configurazione del cluster nella sezioneclusterNetwork
e impostalo sutrue
.Questo campo consente funzionalità di networking avanzate, in particolare la risorsa Gruppo di gateway rete.
apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: bm namespace: CLUSTER_NAMESPACE spec: ... clusterNetwork: advancedNetworking: true
Sostituisci
CLUSTER_NAMESPACE
con lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi dei cluster Anthos sono su Bare Metal come nome del cluster preceduto dacluster-
. Ad esempio, se assegni al tuo cluster il nometest
, lo spazio dei nomi ècluster-test
.Nella sezione
loadBalancer
del file di configurazione del cluster, impostamode
subundled
e aggiungi un campotype
con un valorebgp
.Questi valori dei campi consentono il bilanciamento del carico in bundle basato su BGP.
... loadBalancer: mode: bundled # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2. type: bgp ...
Per specificare le informazioni sul peering BGP per il piano di controllo, aggiungi i seguenti campi alla sezione
loadBalancer
:... # AS number for the cluster localASN: CLUSTER_ASN # List of BGP peers used for the control plane peering sessions. bgpPeers: - ip: PEER_IP asn: PEER_ASN # optional; if not specified, all CP nodes connect to all peers. controlPlaneNodes: # optional - CP_NODE_IP ...
Sostituisci quanto segue:
CLUSTER_ASN
: il numero di sistema autonomo per il cluster in fase di creazione.PEER_IP
: l'indirizzo IP del dispositivo peer esterno.PEER_ASN
: il numero di sistema autonomo per la rete che contiene il dispositivo peer esterno.CP_NODE_IP
: (facoltativo) l'indirizzo IP del nodo del piano di controllo che si connette al peer esterno. Se non specifichi alcun nodo del piano di controllo, tutti i nodi del piano di controllo possono connettersi al peer esterno. Se specifichi uno o più indirizzi IP, solo i nodi specificati partecipano alle sessioni di peering.
Puoi specificare più peer esterni,
bgpPeers
prende un elenco di mappature. Ti consigliamo di specificare almeno due peer esterni per l'alta disponibilità per le sessioni BGP. Per un esempio con più peer, consulta Configurazioni di esempio.Imposta i campi
loadBalancer.ports
,loadBalancer.vips
eloadBalancer.addressPools
(i valori predefiniti sono mostrati).... loadBalancer: ... # Other existing load balancer options remain the same ports: controlPlaneLBPort: 443 # When type=bgp, the VIPs are advertised over BGP vips: controlPlaneVIP: 10.0.0.8 ingressVIP: 10.0.0.1 addressPools: - name: pool1 addresses: - 10.0.0.1-10.0.0.4 ...
Specifica il nodo del cluster da utilizzare per il bilanciamento del carico del piano dati.
Questo passaggio è facoltativo. Se non rimuovi il commento dalla sezione
nodePoolSpec
, i nodi del piano di controllo vengono utilizzati per il bilanciamento del carico del piano dati.... # Node pool used for load balancing data plane (nodes where incoming traffic # arrives. If not specified, this defaults to the control plane node pool. # nodePoolSpec: # nodes: # - address: <Machine 1 IP> ...
Prenota indirizzi IP mobili configurando la risorsa personalizzata
NetworkGatewayGroup
:Gli indirizzi IP mobili vengono utilizzati nelle sessioni di peering per il bilanciamento del carico del piano dati.
... --- apiVersion: networking.gke.io/v1 kind: NetworkGatewayGroup metadata: name: default namespace: CLUSTER_NAMESPACE spec: floatingIPs: - FLOATING_IP ...
Sostituisci quanto segue:
CLUSTER_NAMESPACE
: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi dei cluster Anthos su Bare Metal sono il nome del cluster preceduto dacluster-
. Ad esempio, se assegni al cluster il nometest
, lo spazio dei nomi ècluster-test
.FLOATING_IP
: un indirizzo IP di una delle subnet del cluster. Devi specificare almeno un indirizzo IP, ma ti consigliamo di specificarne almeno due.
Assicurati che la risorsa personalizzata
NetworkGatewayGroup
sia denominatadefault
e utilizzi lo spazio dei nomi del cluster. Per un esempio dell'aspetto della specifica di risorsa personalizzataNetworkGatewayGroup
, consulta la sezione Configurazioni di esempio.(Facoltativo) Specifica i peer da utilizzare per il bilanciamento del carico del piano dati configurando la risorsa personalizzata
BGPLoadBalancer
:... --- apiVersion: networking.gke.io/v1 kind: BGPLoadBalancer metadata: name: default namespace: CLUSTER_NAMESPACE spec: peerSelector: PEER_LABEL: "true" ...
Sostituisci quanto segue:
CLUSTER_NAMESPACE
: lo spazio dei nomi del cluster. Per impostazione predefinita, gli spazi dei nomi dei cluster Anthos sono su Bare Metal come nome del cluster preceduto dacluster-
. Ad esempio, se assegni al tuo cluster il nometest
, lo spazio dei nomi ècluster-test
.PEER_LABEL
: l'etichetta utilizzata per identificare i peer da utilizzare per il bilanciamento del carico. Qualsiasi risorsa personalizzataBGPPeer
con un'etichetta corrispondente specifica i dettagli di ogni peer.
Assicurati che la risorsa personalizzata
BGPLoadBalancer
sia denominatadefault
e utilizzi lo spazio dei nomi del cluster. Se non specifichi una risorsa personalizzataBGPLoadBalancer
, i peer del piano di controllo vengono utilizzati automaticamente per il bilanciamento del carico del piano dati. Per esempi completi, consulta la pagina Configurazioni di esempio.(Facoltativo) Specifica i peer esterni per il piano dati configurando una o più risorse personalizzate
BGPPeer
:... --- apiVersion: networking.gke.io/v1 kind: BGPPeer metadata: name: BGP_PEER_NAME namespace: CLUSTER_NAMESPACE labels: PEER_LABEL: "true" spec: localASN: CLUSTER_ASN peerASN: PEER_ASN peerIP: PEER_IP sessions: SESSION_QTY ...
Sostituisci quanto segue:
BGP_PEER_NAME
: il nome del peer.CLUSTER_NAMESPACE
: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi dei cluster Anthos su Bare Metal sono il nome del cluster preceduto dacluster-
. Ad esempio, se assegni al cluster il nometest
, lo spazio dei nomi ècluster-test
.PEER_LABEL
: l'etichetta utilizzata per identificare i peer da utilizzare per il bilanciamento del carico. Questa etichetta deve corrispondere a quella specificata nella risorsa personalizzataBGPLoadBalancer
.CLUSTER_ASN
: il numero di sistema autonomo per il cluster in fase di creazione.PEER_IP
: l'indirizzo IP del dispositivo peer esterno. Consigliamo di specificare almeno due peer esterni, ma devi specificarne almeno uno.PEER_ASN
: il numero di sistema autonomo per la rete che contiene il dispositivo peer esterno.SESSION_QTY
: il numero di sessioni da stabilire per questo peer. Ti consigliamo di avviare almeno due sessioni per assicurarti di mantenere una connessione al peer nel caso in cui uno dei tuoi nodi non funzioni.
Puoi specificare più peer esterni creando altre risorse personalizzate
BGPPeer
. Ti consigliamo di specificare almeno due peer esterni (due risorse personalizzate) per l'alta disponibilità per le sessioni BGP. Se non specifichi una risorsa personalizzataBGPPeer
, i peer del piano di controllo vengono utilizzati automaticamente per il bilanciamento del carico del piano dati.Quando esegui
bmctl cluster create
per creare il cluster, i controlli preflight vengono eseguiti. Tra gli altri controlli, i controlli preflight convalidano la configurazione del peering BGP per il piano di controllo e segnalano eventuali problemi direttamente alla workstation di amministrazione prima della creazione del cluster.
Pubblicizza più hop successivi per sessione con BGP ADD-PATH
Consigliamo di utilizzare la funzionalità BGP ADD-PATH
per le sessioni di peering come specificato in RFC 7911.
Per impostazione predefinita, il protocollo BGP consente di pubblicizzare un solo hop successivo ai peer per un singolo prefisso. BGP ADD-PATH
consente di pubblicizzare più hop successivi per lo stesso prefisso. Quando ADD-PATH
viene utilizzato con il bilanciamento del carico in bundle basato su BGP, il cluster può pubblicizzare più nodi del cluster come nodi di frontend (hop successivi) per un servizio bilanciatore del carico (prefisso). Abilita ECMP nella rete in modo che il traffico possa essere distribuito su più percorsi. La capacità di estendere il traffico pubblicizzando più nodi del cluster come hop successivi, consente una migliore scalabilità della capacità del piano dati per il bilanciamento del carico.
Se il tuo dispositivo peer esterno, come uno switch o un router top-of-rack (ToR),
supporta ADD-PATH
di BGP, è sufficiente attivare solo l'estensione di ricezione.
Il bilanciamento del carico in bundle con BGP funziona senza la funzionalità ADD-PATH
, ma la limitazione alla pubblicità di un singolo nodo di bilanciamento del carico per sessione di peering limita la capacità del piano dati del bilanciatore del carico. Senza ADD-PATH
, Cluster Anthos on bare metal sceglie i nodi da pubblicizzare dal pool di nodi del bilanciatore del carico e tenta di distribuire gli hop successivi per diversi VIP su nodi diversi.
Limita il peering BGP ai nodi del bilanciatore del carico
Cluster Anthos on bare metal assegna automaticamente gli indirizzi IP mobili su qualsiasi nodo nella stessa subnet dell'indirizzo IP mobile. Le sessioni BGP vengono avviate da questi indirizzi IP anche se non vengono indirizzati sui nodi del bilanciatore del carico. Questo comportamento è basato sulla progettazione, perché abbiamo disaccoppiato il piano di controllo (BGP) dal piano dati (pool di nodi LB).
Se vuoi limitare il set di nodi utilizzabili per il peering BGP, puoi designare una subnet da utilizzare solo per i nodi del bilanciatore del carico. In altre parole, puoi configurare che tutti i nodi in quella subnet si trovino nel pool di nodi del bilanciatore del carico. Quindi, quando configuri gli indirizzi IP mobili utilizzati per il peering BGP, assicurati che provengano dalla stessa subnet. I cluster Anthos su Bare Metal assicurano che le assegnazioni di indirizzi IP mobili e il peering BGP abbiano luogo solo dai nodi del bilanciatore del carico.
Esempi di configurazioni
Le seguenti sezioni mostrano come configurare il bilanciamento del carico basato su BGP per diverse opzioni o comportamenti.
Configura tutti i nodi utilizzando gli stessi peer
Come mostrato nel diagramma seguente, questa configurazione genera un insieme di peer esterni (10.8.0.10
e 10.8.0.11
) raggiungibili da tutti i nodi.
I nodi del piano di controllo (10.0.1.10
, 10.0.1.11
e 10.0.2.10
) e gli indirizzi IP mobili (10.0.1.100
e 10.0.2.100
) assegnati ai nodi del piano dati raggiungono tutti i peer.
Gli stessi peer esterni sono entrambi raggiungibili da uno degli indirizzi IP mobili (10.0.1.100
o 10.0.2.100
) riservati al peering di servizi loadBalancer
. Gli indirizzi IP mobili possono essere assegnati ai nodi che si trovano nella stessa subnet.
Come mostrato nel seguente esempio di configurazione del cluster, devi configurare i peer per i nodi del piano di controllo, bgpPeers
, senza specificare controlPlaneNodes
.
Se non viene specificato alcun nodo per i peer, tutti i nodi del piano di controllo si connettono a tutti i peer.
Specifica gli indirizzi IP mobili da utilizzare per le sessioni di peering di bilanciamento del carico dei servizi nella risorsa personalizzata NetworkGatewayGroup
. In questo esempio, poiché non è specificato alcun valore BGPLoadBalancer
, i peer del piano di controllo vengono utilizzati automaticamente per le sessioni BGP del piano dati.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: bm
namespace: cluster-bm
spec:
...
loadBalancer:
mode: bundled
# type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
type: bgp
# AS number for the cluster
localASN: 65001
bgpPeers:
- ip: 10.8.0.10
asn: 65002
- ip: 10.8.0.11
asn: 65002
... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.1.100
- 10.0.2.100
Configura nodi del piano di controllo specifici per il peering con peer esterni specifici
Come mostrato nel diagramma seguente, questa configurazione comporta il peering di due nodi del piano di controllo (10.0.1.10
e 10.0.1.11
) con un peer esterno (10.0.1.254
). Il terzo nodo del piano di controllo (10.0.2.10
) utilizza il peering con un altro peer esterno (10.0.2.254
). Questa configurazione è utile quando non vuoi che tutti i nodi si connettano a tutti i peer. Ad esempio, potresti voler fare in modo che i nodi del piano di controllo eseguano il peering solo con i corrispondenti sensori top-of-rack (ToR).
Gli stessi peer esterni sono entrambi raggiungibili tramite uno degli indirizzi IP mobili (10.0.1.100
o 10.0.2.100
) riservati alle sessioni di peering di bilanciamento del carico dei servizi. Gli indirizzi IP mobili possono essere assegnati a nodi che si trovano nella stessa subnet.
Come mostrato nell'esempio di configurazione del cluster seguente, limiti i nodi del piano di controllo che possono connettersi a un peer specifico specificando i suoi indirizzi IP nel campo controlPlaneNodes
per il peer nella sezione bgpPeers
.
Specifica gli indirizzi IP mobili da utilizzare per le sessioni di peering di bilanciamento del carico dei servizi nella risorsa personalizzata NetworkGatewayGroup
. In questo esempio, poiché non è specificato alcun valore BGPLoadBalancer
, i peer del piano di controllo vengono utilizzati automaticamente per le sessioni BGP del piano dati.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: bm
namespace: cluster-bm
spec:
...
loadBalancer:
mode: bundled
# type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
type: bgp
# AS number for the cluster
localASN: 65001
peers:
- ip: 10.0.1.254
asn: 65002
controlPlaneNodes:
- 10.0.1.10
- 10.0.1.11
- ip: 10.0.2.254
asn: 65002
controlPlaneNodes:
- 10.0.2.10
... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.1.100
- 10.0.2.100
Configura il piano di controllo e il piano dati separatamente
Come mostrato nel diagramma seguente, questa configurazione determina il peering di due nodi del piano di controllo (10.0.1.10
e 10.0.1.11
) con un peer esterno (10.0.1.254
) e di un terzo nodo del piano di controllo (10.0.2.10
) con un altro peer esterno (10.0.2.254
).
Un terzo peer esterno (10.0.3.254
) è raggiungibile da uno degli indirizzi IP mobili (10.0.3.100
o 10.0.3.101
) riservati alle sessioni di peering di bilanciamento del carico dei servizi. Gli indirizzi IP mobili possono essere assegnati a nodi che si trovano nella stessa subnet.
Come mostrato nell'esempio di configurazione del cluster seguente, limiti i nodi del piano di controllo che possono connettersi a un peer specifico specificando i suoi indirizzi IP nel campo controlPlaneNodes
per il peer nella sezione bgpPeers
.
Specifica gli indirizzi IP mobili da utilizzare per le sessioni di peering di bilanciamento del carico dei servizi nella risorsa personalizzata NetworkGatewayGroup
.
Per configurare il bilanciamento del carico del piano dati:
Specifica il peer esterno per il piano dati nella risorsa
BGPPeer
e aggiungi un'etichetta da utilizzare per la selezione peer, ad esempiocluster.baremetal.gke.io/default-peer: "true"
.Specifica l'etichetta corrispondente per il campo
peerSelector
nella risorsaBGPLoadBalancer
.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: bm
namespace: cluster-bm
spec:
...
loadBalancer:
mode: bundled
# type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
type: bgp
# AS number for the cluster
localASN: 65001
peers:
- ip: 10.0.1.254
asn: 65002
controlPlaneNodes:
- 10.0.1.10
- 10.0.1.11
- ip: 10.0.2.254
asn: 65002
controlPlaneNodes:
- 10.0.2.11
... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.3.100
- 10.0.3.101
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
name: default
namespace: cluster-bm
spec:
peerSelector:
cluster.baremetal.gke.io/default-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
name: bgppeer1
namespace: cluster-bm
labels:
cluster.baremetal.gke.io/default-peer: "true"
spec:
localASN: 65001
peerASN: 65002
peerIP: 10.0.3.254
sessions: 2
Modifica la configurazione del bilanciamento del carico basato su BGP
Dopo aver creato il cluster configurato per l'utilizzo del bilanciamento del carico in bundle con BGP, puoi aggiornare alcune impostazioni di configurazione, mentre altre non possono essere aggiornate dopo la creazione del cluster.
Piano di controllo
Le informazioni sul peering BGP del piano di controllo possono essere aggiornate nella risorsa Cluster
.
Puoi aggiungere o rimuovere i peer specificati nella sezione Bilanciamento del carico del piano di controllo.
Le seguenti sezioni descrivono le best practice per l'aggiornamento delle informazioni sul peering BGP del piano di controllo.
Controlla lo stato di app peer prima di aggiornare
Per ridurre al minimo il rischio di configurazione errata dei peer, verifica che le sessioni di peering BGP del piano di controllo siano nello stato previsto prima di apportare modifiche. Ad esempio, se prevedi che tutte le sessioni di peering BGP sono attualmente attive, verifica che tutti i pod bgp-advertiser
segnalino ready
, a indicare che le sessioni sono aumentate.
Se lo stato attuale non corrisponde a quanto previsto, risolvi il problema prima di aggiornare una configurazione peer.
Per informazioni sul recupero dei dettagli della sessione BGP del piano di controllo, consulta Sessioni BGP del piano di controllo.
Aggiorna le app peer in modo controllato
Aggiorna il peer alla volta, se possibile, per isolare i possibili problemi:
- Aggiungi o aggiorna un singolo peer.
- Attendi che la configurazione venga riconciliata.
- Verifica che il cluster sia in grado di connettersi al peer nuovo o aggiornato.
- Rimuovi i colleghi vecchi o non necessari.
Servizi
Per aggiornare i pool di indirizzi e le impostazioni dei nodi del bilanciatore del carico, modifica nodePoolSpec
nella risorsa Cluster
.
Per modificare la configurazione del peering BGP dopo aver creato il cluster, modifica le risorse personalizzate NetworkGatewayGroup
e BGPLoadBalancer
. Eventuali modifiche alle informazioni di peering in queste risorse personalizzate si riflettono nella configurazione della soluzione di bilanciamento del carico nel cluster di destinazione.
Aggiorna solo le risorse di origine nello spazio dei nomi del cluster nel cluster di amministrazione. Eventuali modifiche apportate alle risorse nel cluster di destinazione (utente) vengono sovrascritte.
Risolvere i problemi
Le seguenti sezioni descrivono come accedere alle informazioni per la risoluzione dei problemi per il bilanciamento del carico in bundle con BGP.
Sessioni BGP del piano di controllo
La configurazione del peering BGP del piano di controllo viene convalidata con i controlli preflight durante la creazione del cluster. I controlli preflight cercano di:
- Stabilisci una connessione BGP con ogni peer.
- Pubblicizza il VIP del piano di controllo.
- Verifica che il nodo del piano di controllo possa essere raggiunto utilizzando il VIP.
Se la creazione del cluster non supera i controlli preflight, esamina i log di controllo preflight per individuare eventuali errori. I file dei log di controllo preflight con data e ora si trovano nella
directory baremetal/bmctl-workspace/CLUSTER_NAME/log
.
In fase di esecuzione, gli altoparlanti BGP del piano di controllo vengono eseguiti come pod statici su ciascun nodo del piano di controllo e scrivono informazioni sugli eventi nei log. Questi pod statici includono "bgpinserzionista" nel nome, quindi usa il seguente comando kubectl get pods
per visualizzare lo stato dei pod degli altoparlanti BGP:
kubectl -n kube-system get pods | grep bgpadvertiser
Se i pod funzionano correttamente, la risposta ha un aspetto simile al seguente:
bgpadvertiser-node-01 1/1 Running 1 167m
bgpadvertiser-node-02 1/1 Running 1 165m
bgpadvertiser-node-03 1/1 Running 1 163m
Utilizza il comando seguente per visualizzare i log per il pod bgpadvertiser-node-01
:
kubectl -n kube-system logs bgpadvertiser-node-01
Sessioni BGP dei servizi
La risorsa BGPSession
fornisce informazioni sulle sessioni BGP attuali. Per ottenere informazioni sulla sessione, recupera prima le sessioni attuali, poi recupera la risorsa BGPSession
per una delle sessioni.
Utilizza il seguente comando kubectl get
per elencare le sessioni correnti:
kubectl -n kube-system get bgpsessions
Il comando restituisce un elenco di sessioni come nell'esempio seguente:
NAME LOCAL ASN PEER ASN LOCAL IP PEER IP STATE LAST REPORT
bgppeer1-node-03 65500 65000 10.0.1.178 10.0.1.254 Established 2s
bgppeer1-node-05 65500 65000 10.0.3.212 10.0.1.254 Established 2s
bgppeer2-node-03 65500 65000 10.0.1.178 10.0.3.254 Established 2s
bgppeer2-node-05 65500 65000 10.0.3.212 10.0.3.254 Established 2s
Utilizza il seguente comando kubectl describe
per ottenere la risorsa BGPSession
per la sessione BGP 10.0.1.254-node-01
:
kubectl -n kube-system describe bgpsession 10.0.1.254-node-01
La risorsa BGPSession
restituita dovrebbe essere simile all'esempio seguente:
Name: 10.0.1.254-node-01
Namespace: kube-system
Labels: <none>
Annotations: <none>
API Version: networking.gke.io/v1
Kind: BGPSession
Metadata:
(omitted)
Spec:
Floating IP: 10.0.1.178
Local ASN: 65500
Local IP: 10.0.1.178
Node Name: node-01
Peer ASN: 65000
Peer IP: 10.0.1.254
Status:
Advertised Routes:
10.0.4.1/32
Last Report Time: 2021-06-14T22:09:36Z
State: Established
Utilizza il comando kubectl get
per ottenere le risorse BGPAdvertisedRoute
:
kubectl -n kube-system get bgpadvertisedroutes
La risposta, che dovrebbe essere simile all'esempio seguente, mostra i percorsi attualmente pubblicizzati:
NAME PREFIX METRIC
default-default-load-balancer-example 10.1.1.34/32
default-gke-system-istio-ingress 10.1.1.107/32
Usa kubectl describe
per visualizzare i dettagli sugli hop successivi che ogni route pubblicizza.
Recupero dell'accesso al VIP del piano di controllo per i cluster autogestiti
Per riottenere l'accesso al VIP del piano di controllo su un cluster di amministrazione, ibrido o autonomo, devi aggiornare la configurazione BGP sul cluster. Come mostrato nell'esempio di comando seguente, utilizza SSH per connetterti al nodo, quindi utilizza kubectl
per aprire la risorsa del cluster per la modifica.
ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP
kubectl --kubeconfig /etc/kubernetes/admin.conf edit -n CLUSTER_NAMESPACE cluster CLUSTER_NAME
Sostituisci quanto segue:
IDENTITY_FILE
: nome del file di identità SSH che contiene la chiave di identità per l'autenticazione della chiave pubblica.CLUSTER_NODE_IP
: l'indirizzo IP del nodo del cluster.CLUSTER_NAMESPACE
: lo spazio dei nomi del cluster.CLUSTER_NAME
: il nome del cluster.
Modifica la configurazione del peering BGP nell'oggetto del cluster. Dopo aver salvato la nuova configurazione del cluster, monitora l'integrità dei pod bgpadvertiser
. Se la configurazione funziona, i pod si riavviano e diventano integri quando si connettono ai loro peer.
Verifica BGP manuale
Questa sezione contiene istruzioni per la verifica manuale della configurazione BGP. La procedura imposta una connessione BGP a lunga esecuzione in modo da poter eseguire ulteriormente il debug della configurazione BGP con il tuo team di rete. Utilizza questa procedura per verificare la configurazione prima di creare un cluster o utilizzarlo se i controlli preflight relativi a BGP non vanno a buon fine.
I controlli preflight automatizzano le seguenti attività di verifica BGP:
- Configura una connessione BGP a un peer.
- Pubblicizza il VIP del piano di controllo.
- Verifica che il traffico inviato da tutti gli altri nodi del cluster al VIP raggiunga il nodo del bilanciatore del carico corrente.
Queste attività vengono eseguite per ogni peer BGP su ogni nodo del piano di controllo. Superare questi controlli è fondamentale durante la creazione di un cluster. I controlli preflight, tuttavia, non creano connessioni di lunga durata, quindi il debug di un errore è difficile.
Le sezioni seguenti forniscono istruzioni per configurare una connessione BGP e pubblicizzare una route da una singola macchina cluster a un peer. Per testare più macchine e più peer, ripeti le istruzioni utilizzando una combinazione di macchine e peer diversa.
Ricorda che le connessioni BGP vengono stabilite dai nodi del piano di controllo, quindi assicurati di testare questa procedura da uno dei nodi del piano di controllo pianificati.
Ottieni il programma binario del programma di test di BGP
Esegui i passaggi in questa sezione sulla workstation di amministrazione. Questi passaggi consentono di ottenere il programma bgpadvertiser
, utilizzato per testare le connessioni BGP e copiarlo per controllare i nodi del piano su cui vuoi eseguire il test.
Esegui il pull dell'immagine docker ansible-runner.
Senza Mirroring registro
Se non utilizzi un mirroring del Registro di sistema, esegui i comandi seguenti per eseguire il pull dell'immagine dockersans-runner:
gcloud auth login gcloud auth configure-docker docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13
Con specchio del Registro di sistema
Se utilizzi un mirroring del Registro di sistema, esegui i comandi seguenti per eseguire il pull dell'immagine docker ansible-runner:
docker login REGISTRY_HOST docker pull REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13
Sostituisci REGISTRY_HOST con il nome del server mirror del registry.
Per estrarre il programma binario di
bgpadvertiser
.Senza Mirroring registro
Per estrarre il programma binario di
bgpadvertiser
, esegui il comando seguente:docker cp $(docker create gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .
Con specchio del Registro di sistema
Per estrarre il programma binario di
bgpadvertiser
, esegui il comando seguente:docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .
Per copiare il programma binario di
bgpadvertiser
nel nodo del piano di controllo su cui vuoi eseguire il test, esegui il comando seguente:scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/
Sostituisci quanto segue:
USERNAME
: il nome utente che utilizzi per accedere al nodo del piano di controllo.CP_NODE_IP
: l'indirizzo IP del nodo del piano di controllo.
Configura una connessione BGP
Esegui i passaggi di questa sezione su un nodo del piano di controllo.
Crea un file di configurazione sul nodo
/tmp/bgpadvertiser.conf
che abbia il seguente aspetto:localIP: NODE_IP localASN: CLUSTER_ASN peers: - peerIP: PEER_IP peerASN: PEER_ASN
Sostituisci quanto segue:
NODE_IP
: indirizzo IP del nodo del piano di controllo che stai utilizzando.CLUSTER_ASN
: il numero di sistema autonomo utilizzato dal cluster.PEER_IP
: l'indirizzo IP di uno dei peer esterni da testare.PEER_ASN
: il numero di sistema autonomo per la rete che contiene il dispositivo peer esterno.
Esegui il daemon
bgpadvertiser
, sostituendo il VIP del piano di controllo nel comando seguente:/tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIP
Sostituisci
CONTROL_PLANE_VIP
con l'indirizzo IP che utilizzerai per il VIP del piano di controllo. Questo comando fa sì che l'inserzionista BGP pubblicizzi questo indirizzo al peer.Visualizza l'output del programma.
A questo punto, il daemon
bgpadvertiser
si avvia, tenta di connettersi al peer e pubblicizza il VIP. Il programma stampa periodicamente i messaggi (vedi l'output di esempio seguente) che includonoBGP_FSM_ESTABLISHED
quando viene stabilita la connessione BGP.{"level":"info","ts":1646788815.5588224,"logger":"BGPSpeaker","msg":"GoBGP gRPC debug endpoint disabled","localIP":"21.0.101.64"} {"level":"info","ts":1646788815.5596201,"logger":"BGPSpeaker","msg":"Started.","localIP":"21.0.101.64"} I0309 01:20:15.559667 1320826 main.go:154] BGP advertiser started. I0309 01:20:15.561434 1320826 main.go:170] Health status HTTP server started at "127.0.0.1:8080". INFO[0000] Add a peer configuration for:21.0.101.80 Topic=Peer {"level":"info","ts":1646788815.5623345,"logger":"BGPSpeaker","msg":"Peer added.","localIP":"21.0.101.64","peer":"21.0.101.80/4273481989"} DEBU[0000] IdleHoldTimer expired Duration=0 Key=21.0.101.80 Topic=Peer I0309 01:20:15.563503 1320826 main.go:187] Peer applied: {4273481989 21.0.101.80} DEBU[0000] state changed Key=21.0.101.80 Topic=Peer new=BGP_FSM_ACTIVE old=BGP_FSM_IDLE reason=idle-hold-timer-expired DEBU[0000] create Destination Nlri=10.0.0.1/32 Topic=Table {"level":"info","ts":1646788815.5670514,"logger":"BGPSpeaker","msg":"Route added.","localIP":"21.0.101.64","route":{"ID":0,"Metric":0,"NextHop":"21.0.101.64","Prefix":"10.0.0.1/32","VRF":""}} I0309 01:20:15.568029 1320826 main.go:199] Route added: {0 0 21.0.101.64 10.0.0.1/32 } I0309 01:20:15.568073 1320826 main.go:201] BGP advertiser serving... DEBU[0005] try to connect Key=21.0.101.80 Topic=Peer DEBU[0005] state changed Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENSENT old=BGP_FSM_ACTIVE reason=new-connection DEBU[0005] state changed Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENCONFIRM old=BGP_FSM_OPENSENT reason=open-msg-received INFO[0005] Peer Up Key=21.0.101.80 State=BGP_FSM_OPENCONFIRM Topic=Peer DEBU[0005] state changed Key=21.0.101.80 Topic=Peer new=BGP_FSM_ESTABLISHED old=BGP_FSM_OPENCONFIRM reason=open-msg-negotiated DEBU[0005] sent update Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer attributes="[{Origin: i} 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]" DEBU[0006] received update Key=21.0.101.80 Topic=Peer attributes="[{Origin: i} 4273481989 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]" DEBU[0006] create Destination Nlri=10.0.0.1/32 Topic=Table DEBU[0035] sent Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}" DEBU[0065] sent Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"
Se non vedi questi messaggi, ricontrolla i parametri di configurazione BGP nel file di configurazione e verifica con l'amministratore di rete. Ora hai configurato una connessione BGP. Puoi verificare con l'amministratore di rete che la connessione sia stata stabilita dalla sua parte e che venga visualizzata la route pubblicizzata.
Test del traffico
Per verificare che la rete possa inoltrare il traffico al VIP, devi aggiungerlo al nodo del piano di controllo che esegue bgpadvertiser
. Esegui questo comando in un terminale diverso per lasciare in esecuzione bgpadvertiser
:
Aggiungi il VIP al nodo del piano di controllo:
ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME
Sostituisci quanto segue:
CONTROL_PLANE_VIP
: l'argomento VIP--advertise-ip
dibgpadvertiser
.INTF_NAME
: l'interfaccia di Kubernetes sul nodo. In altre parole, l'interfaccia ha l'indirizzo IP che hai inserito nella configurazione di Cluster Anthos on bare metal perloadBalancer.bgpPeers.controlPlaneNodes
.
Invia un ping al VIP da un nodo diverso:
ping CONTROL_PLANE_VIP
Se il ping non va a buon fine, potrebbe esserci un problema di configurazione di BGP sul dispositivo di rete. Collabora con l'amministratore di rete per verificare la configurazione e risolvere il problema.
Esegui la pulizia
Assicurati di seguire questi passaggi per reimpostare il nodo dopo aver verificato manualmente che BGP funziona. Se non reimposti il nodo correttamente, la configurazione manuale potrebbe interferire con il controllo preflight o la creazione successiva del cluster.
Rimuovi il VIP dal nodo del piano di controllo se l'hai aggiunto per il test del traffico:
ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME
Sul nodo del piano di controllo, premi
Ctrl
+C
nel terminalebgpadvertiser
per arrestare l'inserzionista bgp.Verifica che non ci siano processi
bgpadvertiser
in esecuzione:ps -ef | grep bgpadvertiser
Se noti processi in esecuzione, interrompili con il comando
kill
.