Questo documento descrive come configurare e utilizzare bilanciatori del carico in bundle con Border
Gateway Protocol (BGP) per Google Distributed Cloud. Questa modalità di bilanciamento del carico
supporta la pubblicità di ServiceType
indirizzi IP virtuali LoadBalancer
(VIP) tramite eBGP (Border Gateway Protocol) esterno per i tuoi cluster. Nel
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 di questa funzionalità.
L'uso dei bilanciatori del carico in bundle con BGP fornisce quanto segue vantaggi:
- Utilizza la funzionalità di bilanciamento del carico attivo/attivo N-way, fornendo più rapidamente un failover e un uso più efficiente della larghezza di banda disponibile.
- Supporta il protocollo di livello 3 che opera con top-of-rack (ToR) di terze parti e router compatibili con eBGP.
- Abilita i data center che eseguono un'avanzata soluzione software-defined lo stack di rete (SDN) per spingere il confine di livello 3 fino alla cluster.
Come funziona il bilanciamento del carico in bundle con BGP
Le sezioni seguenti forniscono un breve riepilogo di come i bilanciatori del carico in bundle con il lavoro BGP.
Peering BGP
La funzionalità dei bilanciatori del carico in bundle con BGP avvia diverse connessioni BGP della tua infrastruttura. BGP ha i seguenti requisiti tecnici:
- Le sessioni di peering sono separate per il VIP del piano di controllo e per i VIP di servizio.
- Le sessioni di peering del piano di controllo vengono avviate dagli indirizzi IP del dai nodi del piano di controllo.
- Le sessioni di peering di servizi vengono avviate da indirizzi IP mobili
specificare nella risorsa personalizzata
NetworkGatewayGroup
. - Il gateway di rete per il controller GDC 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 dovrebbero essere ridistribuite sulla rete e raggiungibile da qualsiasi altro punto del cluster.
- Per il peering si consiglia l'uso della funzionalità
ADD-PATH
BGP in modalità di ricezione sessioni. - La pubblicità di più percorsi per ogni app peer genera un carico attivo/attivo e del bilanciamento del carico.
- Il routing ECMP (Equal-cost multipath) deve essere abilitato per la tua rete, è possibile usare più percorsi per distribuire il traffico in un insieme di carichi nodi dei bilanciatori del carico.
Bilanciamento del carico del piano di controllo
Ogni nodo del piano di controllo nel cluster stabilisce sessioni BGP con uno o più peer nella tua infrastruttura. Ogni nodo del piano di controllo deve almeno un peer. Nel file di configurazione del cluster puoi configurare quale i nodi del piano di controllo si connettono ai peer esterni.
Il seguente diagramma 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. C'è un'istanza il peer (TOR) in ogni subnet e i nodi del piano di controllo Google Distributed Cloud con il relativo TOR.
Bilanciamento del carico del servizio
Oltre alle sessioni di peering avviate da ciascun piano di controllo
nodo per il peering del piano di controllo, vengono avviate sessioni di peering aggiuntive
per i Servizi LoadBalancer
. Queste sessioni di peering non vengono avviate da
direttamente gli indirizzi IP dei nodi cluster, ma usano indirizzi IP mobili.
Sono supportati i servizi con un criterio di rete externalTrafficPolicy=Local
.
Tuttavia, l'impostazione externalTrafficPolicy=Local
dipende dal carico di lavoro e
causa l'aggiornamento delle route ogni volta che viene aggiunto o rimosso un pod che supporta il servizio
completamente da un nodo. Il comportamento di aggiornamento di questa route può causare costi uguali
Routing Multi-Path (ECMP) per modificare i flussi di traffico, il che può comportare cali delle
per via del traffico.
Indirizzi IP mobili
Il bilanciamento del carico del servizio richiede la prenotazione di indirizzi IP mobili in
dei nodi cluster da usare per il peering BGP. Almeno un indirizzo IP mobile è
per il cluster, ma consigliamo di prenotare almeno due indirizzi
per garantire l'alta disponibilità per le sessioni BGP. Gli indirizzi IP mobili vengono
specificato nella risorsa (RP) personalizzata NetworkGatewayGroup
, che può essere
incluso nel file di configurazione del cluster.
Gli indirizzi IP mobili rimuovono la preoccupazione di mappare gli indirizzi IP degli speaker BGP a
nodi. Il gateway di rete per il controller GDC si occupa di assegnare
NetworkGatewayGroup
ai nodi e gestisce anche gli indirizzi IP mobili.
Se un nodo smette di funzionare, il gateway di rete per il controller GDC la riassegna
indirizzi IP mobili per garantire che i peer esterni abbiano un IP deterministico
l'indirizzo IP con cui stabilire il peering.
App peer esterne
Per il bilanciamento del carico del piano dati, puoi utilizzare gli stessi peer esterni che erano
specificato per il peering del piano di controllo in 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
Specifiche delle risorse BGPLoadBalancer
e BGPPeer
per il cluster
di configurazione del deployment. Se non specifichi queste risorse personalizzate, il controllo
I peer del piano vengono usati automaticamente per il piano dati.
Specifica i peer esterni utilizzati per le sessioni di peering con l'IP mobile
indirizzi nella risorsa personalizzata BGPPeer
, che aggiungi al cluster
di configurazione del deployment. La risorsa BGPPeer
include un'etichetta per l'identificazione
dalla risorsa personalizzata BGPLoadBalancer
corrispondente. Tu specifichi la corrispondenza
un'etichetta nel campo peerSelector
nella risorsa personalizzata BGPLoadBalancer
per
seleziona BGPPeer
per l'utilizzo.
Il gateway di rete per il controller GDC tenta di stabilire sessioni
(il numero di sessioni è configurabile) per ciascun peer esterno dall'insieme
indirizzi IP mobili prenotati. Ti consigliamo di specificare almeno due
peer esterni per garantire l'alta disponibilità per le sessioni BGP. Ogni peer esterno
designati per il bilanciamento del carico dei servizi devono essere configurati per il peering con ogni
Indirizzo IP mobile specificato nella risorsa personalizzata NetworkGatewayGroup
.
Nodi del bilanciatore del carico
Un sottoinsieme di nodi del cluster viene utilizzato per il bilanciamento del carico, il che significa che
i nodi pubblicizzati per essere in grado di accettare il traffico di bilanciamento del carico in entrata.
Questo insieme di nodi è impostato sul pool di nodi del piano di controllo per impostazione predefinita, ma puoi specificare
un pool di nodi diverso nella sezione loadBalancer
della configurazione del cluster
. Se specifichi un pool di nodi, questo viene utilizzato per i nodi del bilanciatore del carico,
anziché il pool di nodi del piano di controllo.
Gli indirizzi IP mobili, che funzionano come altoparlanti BGP, possono essere eseguiti o meno dai nodi del bilanciatore del carico. Gli indirizzi IP mobili sono assegnati a un nodo nella la stessa subnet e il peering vengono avviati da lì, a prescindere dal fatto che del bilanciatore del carico. Tuttavia, gli hop successivi pubblicizzati su BGP sono sempre il carico nodi dei bilanciatori del carico.
Esempio di topologia di peering
Il seguente diagramma mostra un esempio di bilanciamento del carico del servizio con BGP e il peering. Esistono due indirizzi IP mobili assegnati ai nodi nel loro le rispettive subnet. Sono stati definiti due peer esterni. Ogni peer IP mobile con entrambi i colleghi esterni.
Configura il bilanciatore del carico BGP
Le sezioni seguenti descrivono come configurare i cluster e l'infrastruttura per utilizzare il 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 il bilanciatore dell'infrastruttura:
L'infrastruttura esterna deve essere configurata per il peering con ciascuno dei controlli nodi del piano nel cluster per configurare la comunicazione con il piano di controllo. Questi Le 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 riservati indirizzi IP mobili per le comunicazioni del piano dati. L'IP mobile vengono utilizzati per il peering BGP per i VIP del servizio. Ti consigliamo utilizza due indirizzi IP mobili e due peer per garantire l'alta disponibilità BGP. Il processo di prenotazione dell'IP mobile è descritto come parte di configurare il cluster per il bilanciamento del carico in bundle BGP.
Dopo aver configurato l'infrastruttura, aggiungi le informazioni sul peering BGP il file di configurazione del cluster. Il cluster che crei può avviare il peering sessioni con l'infrastruttura esterna.
Configura il cluster per il bilanciamento del carico in bundle con BGP
Puoi abilitare e configurare il bilanciamento del carico in bundle con BGP nel cluster
di configurazione quando crei un cluster. Nel file di configurazione del cluster,
attivi il networking avanzato e aggiorni la sezione loadBalancer
. Inoltre
aggiungi le specifiche per le seguenti tre risorse personalizzate:
NetworkGatewayGroup
: specifica gli indirizzi IP mobili utilizzati per Sessioni di peering BGP dei servizi.BGPLoadBalancer
: specifica con i selettori di etichette per quali peer vengono utilizzati i peer Bilanciamento del carico BGP.BGPPeer
: specifica le singole app peer, inclusa un'etichetta per la selezione per le sessioni di peering BGP.
Le istruzioni riportate di seguito descrivono come configurare il cluster e i tre risorse personalizzate per configurare il bilanciamento del carico in bundle con BGP.
Aggiungi il campo
advancedNetworking
al file di configurazione del cluster nellaclusterNetwork
e l'hai impostata sutrue
.Questo campo attiva funzionalità di networking avanzate, in particolare la rete Risorsa gruppo di gateway.
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 del cluster Google Distributed Cloud è il nome del cluster preceduto dacluster-
. Ad esempio, se assegni al cluster il nometest
, lo spazio dei nomi ècluster-test
.Nella sezione
loadBalancer
del file di configurazione del cluster, impostamode
abundled
e aggiungi un campotype
con il valorebgp
.Questi valori dei campi abilitano 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 di peering BGP per il piano di controllo, aggiungi 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 del sistema autonomo per del cluster in fase di creazione.PEER_IP
: l'indirizzo IP del peer esterno dispositivo.PEER_ASN
: il numero del sistema autonomo per rete che contiene il dispositivo peer esterno.CP_NODE_IP
: (facoltativo) l'indirizzo IP del del piano di controllo che si connette al peer esterno. In caso contrario specificare qualsiasi nodo del piano di controllo, tutti i nodi possono connettersi il peer esterno. Se specifichi uno o più indirizzi IP, solo il valore i nodi specificati partecipano alle sessioni di peering.
Puoi specificare più peer esterni,
bgpPeers
richiede un elenco di mapping. Ti consigliamo di specificare almeno due peer esterni per un'alta la disponibilità per le sessioni BGP. Per un esempio con più app peer, consulta Configurazioni di esempio.Imposta
loadBalancer.ports
,loadBalancer.vips
eloadBalancer.addressPools
campi (valori predefiniti 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
NetworkGatewayGroup
risorsa personalizzata:Gli indirizzi IP mobili vengono utilizzati nelle sessioni di peering per il carico del piano dati e del bilanciamento del carico.
... --- apiVersion: networking.gke.io/v1 kind: NetworkGatewayGroup metadata: name: default namespace: CLUSTER_NAMESPACE spec: floatingIPs: - FLOATING_IP nodeSelector: # optional - NODE_SELECTOR ...
Sostituisci quanto segue:
CLUSTER_NAMESPACE
: il valore per il cluster. Per impostazione predefinita, gli spazi dei nomi del cluster Google Distributed Cloud è 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 da uno dei alle subnet del cluster. Devi specificare almeno un indirizzo IP, ma consigliamo di specificare almeno due indirizzi IP.NODE_SELECTOR
: (facoltativo) un selettore di etichetta per identificare i nodi per creare un'istanza delle sessioni di peering con peer esterni, come gli switch top-of-rack (ToR). Se non è necessario, rimuovi questo .
Assicurati che la risorsa personalizzata
NetworkGatewayGroup
sia denominatadefault
e utilizzi lo spazio dei nomi del cluster. Per un esempio di comeNetworkGatewayGroup
personalizzata delle risorse, vedi Configurazioni di esempio.(Facoltativo) Specifica i peer da utilizzare per il bilanciamento del carico del piano dati tramite configurazione della 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
: il valore del cluster. Per impostazione predefinita, gli spazi dei nomi del cluster Google Distributed Cloud è 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 per il bilanciamento del carico. Qualsiasi risorsa personalizzataBGPPeer
con un L'etichetta corrispondente specifica i dettagli di ogni peer.
Assicurati che la risorsa personalizzata
BGPLoadBalancer
sia denominatadefault
e utilizzi la classe nello spazio dei nomi del cluster. Se non specifichi una risorsa personalizzataBGPLoadBalancer
, I peer del piano di controllo vengono utilizzati automaticamente per il carico del piano dati e del bilanciamento del carico. Per esempi completi, consulta: Configurazioni di esempio.(Facoltativo) Specifica i peer esterni per il piano dati configurandone uno o più
BGPPeer
risorse personalizzate:... --- 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 selectors: # Optional gatewayRefs: - GATEWAY_REF ...
Sostituisci quanto segue:
BGP_PEER_NAME
: il nome del peer.CLUSTER_NAMESPACE
: il valore per il cluster. Per impostazione predefinita, gli spazi dei nomi del cluster Google Distributed Cloud è 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 per il bilanciamento del carico. Questa etichetta deve corrispondere alla l'etichetta specificata nella risorsa personalizzataBGPLoadBalancer
.CLUSTER_ASN
: il numero del sistema autonomo per del cluster in fase di creazione.PEER_IP
: l'indirizzo IP del peer esterno dispositivo. Ti consigliamo di specificare almeno due peer esterni, ma devi specificarne almeno uno.PEER_ASN
: il numero del sistema autonomo per rete che contiene il dispositivo peer esterno.SESSION_QTY
: il numero di sessioni per stabilisci per questo peer. Ti consigliamo di definire almeno due per assicurarti di mantenere una connessione con il peer nel caso uno dei nodi non funziona.GATEWAY_REF
: (facoltativo) il nome di un Risorsa NetworkGatewayGroup da utilizzare per il peering. Se non viene configurato, qualsiasi valore o possono essere utilizzate tutte le risorse del gateway. Utilizza questa impostazione insieme a il camponodeSelector
nella risorsa NetworkGatewayGroups per selezionare quali nodi utilizzare per il peering con un peer esterno specifico, come un Interruttore ToR. Questa operazione può richiedere più voci per selezionare NetworkGatewayGroups nel formato di un gateway per riga.
Puoi specificare più peer esterni creando altri
BGPPeer
risorse personalizzate. Ti consigliamo di specificare almeno due peer esterni (due risorse personalizzate) per garantire l'alta disponibilità per le sessioni BGP. In caso contrario specifica una risorsa personalizzataBGPPeer
, vengono utilizzati i peer del piano di controllo automaticamente per il bilanciamento del carico del piano dati.Quando esegui
bmctl cluster create
per creare il tuo cluster, vengono eseguiti controlli preflight vengono eseguiti tutti i test delle unità. Tra gli altri controlli, i controlli preflight convalidano il peering BGP configurazione per il piano di controllo e segnala eventuali problemi direttamente al alla workstation di amministrazione Google prima di poter creare il cluster.Se l'operazione riesce, le risorse di bilanciamento del carico BGP aggiunte (NetworkGatewayGroup, BGPLoadBalancer e BGPPeer) entrano nel cluster di amministrazione nel cluster utente nello spazio dei nomi. Utilizza il file kubeconfig del cluster di amministrazione quando effettui aggiornamenti a queste risorse. Il cluster di amministrazione esegue quindi la riconciliazione delle modifiche nel cluster utente. Se modifichi queste risorse direttamente nel cluster utente, il cluster di amministrazione sovrascrive le modifiche nelle riconciliazioni successive.
Pubblicizza più hop successivi per sessione con BGP ADD-PATH
Ti 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
per un singolo prefisso. BGP ADD-PATH
abilita la pubblicità di più hop successivi
per lo stesso prefisso. Quando ADD-PATH
viene utilizzato con il carico in bundle basato su BGP
di bilanciamento, il cluster può pubblicizzare più nodi cluster come nodi frontend
(hop successivi) per un servizio di bilanciamento del carico (prefisso). Abilita ECMP nella rete in modo che
che il traffico può essere distribuito su più percorsi. La possibilità di distribuire il traffico in fan-out
pubblicizzando più nodi del cluster come hop successivi, offre una migliore scalabilità
del piano dati per il bilanciamento del carico.
Se il dispositivo peer esterno, ad esempio uno switch o un router top-of-rack (ToR),
supporta BGP ADD-PATH
, è sufficiente attivare solo l'estensione di ricezione.
Il bilanciamento del carico in bundle con BGP funziona senza la funzionalità ADD-PATH
, ma
limitazione della 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
,
Google Distributed Cloud sceglie i nodi da pubblicizzare dal pool di nodi del bilanciatore del carico
e tenta di distribuire hop successivi per diversi VIP su nodi diversi.
Limita il peering BGP ai nodi del bilanciatore del carico
Google Distributed Cloud assegna automaticamente indirizzi IP mobili su qualsiasi nodo nella stessa subnet dell'indirizzo IP mobile. Le sessioni BGP vengono avviate da anche se non arrivano sui nodi del bilanciatore del carico. Questo il comportamento è dovuto alla progettazione, poiché il piano di controllo (BGP) è disaccoppiato dal piano dati (pool di nodi LB).
Se vuoi limitare l'insieme di nodi che possono essere utilizzati per il peering BGP, può designare una subnet da utilizzare solo per i nodi del bilanciatore del carico. Vale a dire che può configurare tutti i nodi in quella subnet in modo che rientrino nel pool di nodi del bilanciatore del carico. Poi, quando configuri gli indirizzi IP mobili utilizzati per il peering BGP, assicurati che provengano dalla stessa subnet. Google Distributed Cloud garantisce che Le assegnazioni di indirizzi IP mobili e il peering BGP vengono eseguiti dal bilanciatore del carico solo nodi.
Configura il bilanciamento del carico BGP con networking a doppio stack
A partire dalla release 1.14.0 di Google Distributed Cloud, il carico in bundle basato su BGP che supporta IPv6. Con l'introduzione del supporto IPv6, puoi configurare Servizi LoadBalancer IPv6 e a doppio stack su un cluster configurato per il doppio stack networking. Questa sezione descrive le modifiche necessarie per configurare il Dual stack, il bilanciamento del carico in bundle con BGP.
Per abilitare i servizi LoadBalancer a doppio stack, modifiche alla configurazione seguenti sono obbligatori:
Il cluster sottostante deve essere configurato per il networking a doppio stack:
Specifica i CIDR del servizio IPv4 e IPv6 nel file di configurazione del cluster sotto
spec.clusterNetwork.services.cidrBlocks
.Definire le risorse ClusterCIDRConfig appropriate per specificare IPv4 e IPv6 Intervalli CIDR per i pod.
Per ulteriori informazioni sulla configurazione di un cluster per il networking a doppio stack, consulta Networking a doppio stack IPv4/IPv6
Specifica un pool di indirizzi IPv6 nel file di configurazione del cluster in
spec.loadBalancer.addressPools
. Per MetalLB per allocare indirizzi IP a un servizio Dual Stack, deve essere presente almeno un pool di indirizzi in formato IPv4 e IPv6 indirizzi IP esterni.
La seguente configurazione di esempio evidenzia le modifiche necessarie per il modello a doppio stack bilanciamento del carico in bundle con BGP:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: bm
namespace: cluster-bm
spec:
...
clusterNetwork:
services:
cidrBlocks:
# Dual-stack Service IP addresses must be provided
- 10.96.0.0/16
- fd00::/112
...
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
addressPools:
- name: pool1
addresses:
# Each address must be either in the CIDR form (1.2.3.0/24)
# or range form (1.2.3.1-1.2.3.5).
- "203.0.113.1-203.0.113.20"
- "2001:db8::1-2001:db8::20" # Note the additional IPv6 range
... # Other cluster config info omitted
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.1.100
- 10.0.2.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
name: cluster-wide-1
namespace: cluster-bm
spec:
ipv4:
cidr: "192.168.0.0/16"
perNodeMaskSize: 24
ipv6:
cidr: "2001:db8:1::/112"
perNodeMaskSize: 120
Limitazioni per il bilanciamento del carico a doppio stack e in bundle con BGP
Quando configuri il cluster per l'utilizzo del bilanciamento del carico a doppio stack e in bundle con BGP, tieni presente le seguenti limitazioni:
Il bilanciamento del carico del piano di controllo IPv6 non è supportato.
Le sessioni BGP IPv6 non sono supportate, ma le route IPv6 possono essere annunciate su Sessioni IPv4 con BGP multiprotocollo.
Configurazioni di esempio
Le sezioni seguenti mostrano come configurare il bilanciamento del carico basato su BGP 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.
Nodi del piano di controllo (10.0.1.10
, 10.0.1.11
e 10.0.2.10
) e IP mobile
gli indirizzi (10.0.1.100
e 10.0.2.100
) assegnati ai nodi del piano dati raggiungono tutti
con i colleghi.
Gli stessi peer esterni sono entrambi raggiungibili tramite l'IP mobile
indirizzi (10.0.1.100
o 10.0.2.100
) riservati a loadBalancer
Peering di servizi. Gli indirizzi IP mobili possono essere assegnati ai nodi che si trovano in
la stessa subnet.
Come mostrato nell'esempio di configurazione del cluster riportato di seguito, configuri le app peer
per i nodi del piano di controllo, bgpPeers
, senza specificare controlPlaneNodes
.
Se non vengono specificati nodi per i peer, tutti i nodi del piano di controllo si connettono a
tutte le app peer.
Specifica gli indirizzi IP mobili da utilizzare per il peering con bilanciamento del carico dei servizi
sessioni nella risorsa personalizzata NetworkGatewayGroup
. In questo esempio, poiché nessuna
BGPLoadBalancer
è specificato, 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 specifici del piano di controllo per eseguire il peering con peer esterni specifici
Come mostrato nel diagramma seguente, questa configurazione genera
peering di nodi del piano (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
) è 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 volere
nodi del piano in peering solo con i commutatori top-of-rack (ToR) corrispondenti.
Gli stessi peer esterni sono entrambi raggiungibili tramite l'IP mobile
(10.0.1.100
o 10.0.2.100
) riservati ai servizi
e sessioni di peering con bilanciamento del carico. Gli indirizzi IP mobili possono essere assegnati
di nodi nella stessa subnet.
Come mostrato nell'esempio di configurazione del cluster riportato di seguito, limiti i tipi
i nodi del piano di controllo possono connettersi a un determinato peer specificando i relativi indirizzi IP
nel campo controlPlaneNodes
per il peer nella sezione bgpPeers
.
Specifica gli indirizzi IP mobili da utilizzare per il peering con bilanciamento del carico dei servizi
sessioni nella risorsa personalizzata NetworkGatewayGroup
. In questo esempio, poiché nessuna
BGPLoadBalancer
è specificato, 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.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 genera
peering di nodi del piano (10.0.1.10
e 10.0.1.11
) con un peer esterno
(10.0.1.254
) e il peering del terzo nodo del piano di controllo (10.0.2.11
) con
un altro peer esterno (10.0.2.254
).
Un terzo peer esterno (10.0.3.254
) è raggiungibile tramite uno degli IP mobili
(10.0.3.100
o 10.0.3.101
) riservati ai servizi
e sessioni di peering con bilanciamento del carico. Gli indirizzi IP mobili possono essere assegnati
di nodi nella stessa subnet.
Come mostrato nell'esempio di configurazione del cluster riportato di seguito, limiti i tipi
i nodi del piano di controllo possono connettersi a un determinato peer specificando i relativi indirizzi IP
nel campo controlPlaneNodes
per il peer nella sezione bgpPeers
.
Specifica gli indirizzi IP mobili da utilizzare per il peering con bilanciamento del carico dei servizi
sessioni 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 dei compagni, comecluster.baremetal.gke.io/default-peer: "true"
.Specifica l'etichetta corrispondente per il campo
peerSelector
nell'elementoBGPLoadBalancer
risorsa.
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.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 utilizzare il bilanciamento del carico in bundle con BGP, alcune impostazioni di configurazione possono essere aggiornate, ma altre non possono essere aggiornate dopo la creazione del cluster.
Utilizza il file kubeconfig del cluster di amministrazione quando apporti aggiornamenti successivi alla Risorse correlate a BGP (NetworkGatewayGroup, BGPLoadBalancer e BGPPeer). La quindi riconcilia le modifiche al cluster utente. Se modifichi questi direttamente sul cluster utente, il cluster di amministrazione sovrascrive le modifiche nelle riconciliazioni successive.
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 nel bilanciamento del carico del piano di controllo
.
Le seguenti sezioni descrivono le best practice per l'aggiornamento del controllo per pianificare le informazioni sul peering BGP.
Controlla lo stato delle app peer prima di eseguire l'aggiornamento
Per ridurre al minimo il rischio di configurazione errata dei peer, controlla il BGP del piano di controllo
Le sessioni di peering sono 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 bgp-advertiser
pod registrano ready
, indicando che le sessioni sono attive.
Se lo stato attuale non corrisponde a quello previsto, risolvi il problema prima
aggiornare una configurazione peer.
Per informazioni sul recupero dei dettagli della sessione BGP del piano di controllo, consulta Controllo sessioni BGP del piano.
Aggiorna i peer in modo controllato
Se possibile, aggiorna un peer alla volta per isolare i possibili problemi:
- Aggiungi o aggiorna un singolo peer.
- Attendi la riconciliazione della configurazione.
- Verifica che il cluster sia in grado di connettersi al peer nuovo o aggiornato.
- Rimuovi i colleghi vecchi o non necessari.
Servizi
Per aggiornare le impostazioni dei nodi del bilanciatore del carico e dei pool di indirizzi, modifica nodePoolSpec
in
la risorsa Cluster
.
Per modificare la configurazione del peering BGP dopo la creazione del cluster,
modifica le risorse personalizzate NetworkGatewayGroup
e BGPLoadBalancer
. Qualsiasi
le modifiche alle informazioni di peering
in queste risorse personalizzate
nella configurazione della soluzione di bilanciamento del carico nel cluster di destinazione.
Apporta aggiornamenti nelle risorse di origine nello spazio dei nomi del cluster nella sezione Amministratore solo nel cluster. Qualsiasi modifica apportata alle risorse nel target (utente) vengono sovrascritti.
Risoluzione dei problemi
Le seguenti sezioni descrivono come accedere alle informazioni di 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 è convalidata mediante controlli preflight durante la creazione del cluster. I controlli preflight tentano 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, rivedi il controllo preflight
i log per gli errori. I file di log dei controlli preflight con data si trovano in
Directory baremetal/bmctl-workspace/CLUSTER_NAME/log
.
In fase di runtime, gli speaker BGP del piano di controllo vengono eseguiti come pod statici su ciascun controllo
del piano di controllo e scrivere informazioni sugli eventi nei log. Questi pod statici includono
"inserzionista bgp" nel nome, quindi usa questo comando kubectl get pods
per visualizzare lo stato dei pod degli speaker BGP:
kubectl -n kube-system get pods | grep bgpadvertiser
Quando i pod funzionano correttamente, la risposta ha un aspetto simile a seguenti:
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 seguente comando 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. A
ottenere informazioni sulla sessione, visualizzare prima le sessioni correnti, quindi recuperare
BGPSession
risorsa 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
10.0.1.254-node-01 65500 65000 10.0.1.178 10.0.1.254 Established 2s
10.0.1.254-node-02 65500 65000 10.0.3.212 10.0.1.254 Established 2s
10.0.3.254-node-01 65500 65000 10.0.1.178 10.0.3.254 Established 2s
10.0.3.254-node-02 65500 65000 10.0.3.212 10.0.3.254 Established 2s
Usa questo comando kubectl describe
per recuperare 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 avere un aspetto simile al seguente
esempio:
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
Usa il comando kubectl get
per recuperare le risorse BGPAdvertisedRoute
:
kubectl -n kube-system get bgpadvertisedroutes
La risposta, che dovrebbe avere un aspetto simile all'esempio seguente, mostra route attualmente pubblicizzate:
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 di ogni route
per la pubblicità online.
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 account amministratore, ibrido o autonomo
devi aggiornare la configurazione BGP sul cluster. Come mostrato in
nell'esempio di comando riportato di seguito, usa SSH per connetterti al nodo, quindi usa kubectl
aprire la risorsa del cluster per modificarla.
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
: il nome del file di identità SSH che contiene la chiave di identità per l'autenticazione con 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 il nuovo
della configurazione del cluster, monitora l'integrità dei pod bgpadvertiser
. Se
funziona, i pod si riavviano e diventano integri una volta connessi
con i colleghi.
Verifica BGP manuale
Questa sezione contiene istruzioni per la verifica manuale del BGP configurazione. La procedura configura una connessione BGP a lunga esecuzione un ulteriore debug della configurazione BGP con il tuo team di rete. Usa questa 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 la attuale nodo del bilanciatore del carico.
Queste attività vengono eseguite per ciascun peer BGP su ciascun nodo del piano di controllo. Superato è fondamentale durante la creazione di un cluster. I controlli preflight, tuttavia, creare connessioni a lunga esecuzione, pertanto è difficile eseguire il debug di un errore.
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ù volte più macchine virtuali e più peer, ripeti le istruzioni utilizzando un combinazione di macchina e app peer.
Ricorda che le connessioni BGP vengono stabilite dai nodi del piano di controllo, assicurati di testare questa procedura da uno dei nodi del piano di controllo pianificato.
Ottenere il file binario del programma di test BGP
Esegui i passaggi descritti in questa sezione sulla workstation di amministrazione. Questi passaggi consentono di
bgpadvertiser
programma utilizzato per testare le connessioni BGP e copiarlo in
dei nodi del piano di controllo su cui vuoi eseguire il test.
Estrai l'immagine Docker ansible-runner.
Senza Mirror del registro
Se non utilizzi un mirror del registro, esegui questi comandi per eseguire il pull l'immagine Docker di ansible-runner:
gcloud auth login gcloud auth configure-docker docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13
Con mirroring del registro
Se utilizzi un mirror del registro, esegui questi comandi per eseguire il pull 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 di mirroring del registry.
Per estrarre il programma binario
bgpadvertiser
.Senza Mirror del registro
Per estrarre il programma binario
bgpadvertiser
, esegui questo comando:docker cp $(docker create gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .
Con mirroring del registro
Per estrarre il programma binario
bgpadvertiser
, esegui questo comando:docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .
Per copiare il programma binario
bgpadvertiser
sul nodo del piano di controllo che vuoi su cui eseguire il test, esegui questo comando:scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/
Sostituisci quanto segue:
USERNAME
: il nome utente per accedere al nodo del piano di controllo.CP_NODE_IP
: l'indirizzo IP di dal nodo del piano di controllo.
Configura una connessione BGP
Esegui i passaggi descritti in questa sezione su un nodo del piano di controllo.
Crea un file di configurazione sul nodo in
/tmp/bgpadvertiser.conf
che ha 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 in cui ti trovi.CLUSTER_ASN
: numero del sistema autonomo utilizzato dal cluster.PEER_IP
: l'indirizzo IP di uno dei server peer che vuoi testare.PEER_ASN
: il numero del sistema autonomo per rete che contiene il dispositivo peer esterno.
Esegui il daemon
bgpadvertiser
, sostituendo il VIP del piano di controllo nel seguente comando:/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 peer.Visualizza l'output del programma.
A questo punto, il daemon
bgpadvertiser
viene avviato e tenta di connettersi il peer e pubblicizza il VIP. Il programma stampa periodicamente i messaggi (vedi l'output di esempio di seguito) 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, verifica la configurazione di BGP nel file di configurazione e verifica con l'amministratore di rete. Ora è configurata una connessione BGP. Puoi verificare con l'amministratore di rete che vede la connessione instaurata dal loro lato e vede il percorso pubblicizzato.
Test del traffico
Per verificare che la rete possa inoltrare il traffico al VIP, devi aggiungere il VIP a
dal nodo del piano di controllo che esegue bgpadvertiser
. Esegui questo comando
in un terminale diverso, quindi puoi 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
: il valore Argomento VIP--advertise-ip
dibgpadvertiser
.INTF_NAME
: il cluster Kubernetes a riga di comando sul nodo. cioè l'interfaccia con l'indirizzo IP che inserisci nella configurazione di Google Distributed CloudloadBalancer.bgpPeers.controlPlaneNodes
.
Invia un ping al VIP da un nodo diverso:
ping CONTROL_PLANE_VIP
Se il ping non riesce, potrebbe esserci un problema con il BGP configurazione sul dispositivo di rete. Rivolgiti all'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 eseguito la verifica manuale del servizio BGP funziona. Se non reimposti correttamente il nodo, la configurazione manuale potrebbe interferiscono con il controllo preflight o con la successiva creazione del cluster.
Rimuovi il VIP dal nodo del piano di controllo se lo hai aggiunto per il traffico Test:
ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME
Sul nodo del piano di controllo, premi
Ctrl
+C
nel terminalebgpadvertiser
per interrompere bgpAdvertiser.Verifica che nessun processo
bgpadvertiser
sia in esecuzione:ps -ef | grep bgpadvertiser
Se vedi processi in esecuzione, interrompili utilizzando il comando
kill
.