Configurazione di bilanciatori del carico integrati con BGP

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. In questo scenario, la rete del cluster è un sistema autonomo, che si interconnetta con un altro sistema autonomo, una rete esterna, tramite il peering.

I bilanciatori del carico in bundle con funzionalità BGP si applicano a tutti i tipi di cluster, ma i cluster amministrativi supportano solo la parte di bilanciamento del carico del piano di controllo di questa funzionalità.

L'utilizzo della funzionalità dei bilanciatori del carico integrati con BGP offre i seguenti vantaggi:

  • Utilizza la funzionalità di bilanciamento del carico attivo/attivo N-way, che offre un failover più rapido e un utilizzo 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 networking (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 integrati con BGP avvia diverse connessioni BGP alla 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 dei nodi del piano di controllo.
  • Le sessioni di peering di servizi vengono avviate da indirizzi IP mobili specificare nella risorsa personalizzata NetworkGatewayGroup.
  • Network Gateway per il controller GDC gestisce gli indirizzi IP flottanti.
  • Il bilanciamento del carico basato su BGP in bundle supporta solo il peering eBGP.
  • Il peering multihop è supportato per impostazione predefinita.
  • Le password MD5 nelle sessioni BGP non sono supportate.
  • Le sessioni di peering basate su IPv6 non sono supportate.
  • I percorsi pubblicizzati a qualsiasi peer dovrebbero essere ridistribuiti in tutta la rete e essere raggiungibili da qualsiasi altro punto del cluster.
  • Per le sessioni di peering, è consigliabile utilizzare la funzionalità BGP ADD-PATH in modalità di ricezione.
  • 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 control plane

Ogni nodo del piano di controllo nel cluster stabilisce sessioni BGP con uno o più peer nella tua infrastruttura. È necessario che ogni nodo del control plane abbia 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 con il peering BGP

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 direttamente dagli indirizzi IP dei nodi del cluster, ma utilizzano indirizzi IP fluttuanti.

Sono supportati i servizi con un criterio di rete externalTrafficPolicy=Local. Tuttavia, l'impostazione externalTrafficPolicy=Local dipende dal carico di lavoro e provoca l'aggiornamento dei percorsi ogni volta che un pod di supporto del servizio viene aggiunto o rimosso completamente da un nodo. Questo comportamento di aggiornamento dei percorsi potrebbe causare la modifica dei flussi di traffico da parte del routing ECMP (Equal-cost multipath), con conseguente calo 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. Per il cluster è necessario almeno un indirizzo IP dinamico, ma ti consigliamo di prenotare almeno due indirizzi per garantire un'alta disponibilità per le sessioni BGP. Gli indirizzi IP flottanti sono specificati nella risorsa personalizzata NetworkGatewayGroup, che può essere inclusa nel file di configurazione del cluster.

Gli indirizzi IP mobili rimuovono la preoccupazione di mappare gli indirizzi IP degli speaker BGP a nodi. Il controller Network Gateway per GDC si occupa di assegnare il NetworkGatewayGroup ai nodi e gestisce anche gli indirizzi IP flottanti. Se un nodo si arresta in modo anomalo, il controller Network Gateway per GDC riassegna gli indirizzi IP fluttuanti per garantire che i peer esterni abbiano un indirizzo IP deterministico con cui eseguire 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 gli indirizzi IP dinamici 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. Specifica l'etichetta corrispondente nel campo peerSelector della risorsa personalizzata BGPLoadBalancer per selezionare BGPPeer da utilizzare.

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 un'alta disponibilità per le sessioni BGP. Ogni peer esterno designato per il bilanciamento del carico dei servizi deve essere configurato per il peer con ogni indirizzo IP dinamico 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. Per impostazione predefinita, questo insieme di nodi corrisponde al pool di nodi del piano di controllo, ma puoi specificare un altro pool di nodi 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 flottanti, che fungono da speaker BGP, possono essere o meno in esecuzione sui 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 IP dinamico è in peering con entrambi i peer esterni.

Bilanciamento del carico del servizio con il peering BGP

Configura il bilanciatore del carico BGP

Le seguenti sezioni descrivono come configurare i cluster e la rete esterna per utilizzare il bilanciatore del carico integrato con BGP.

Pianifica l'integrazione con l'infrastruttura esterna

Per utilizzare il bilanciatore del carico in bundle con BGP, devi configurare il bilanciatore infrastructure:

  • 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. Queste sessioni di peering vengono utilizzate per pubblicizzare i VIP del control plane di Kubernetes.

  • L'infrastruttura esterna deve essere configurata per il peering con un insieme di indirizzi IP dinamici riservati per la comunicazione del piano dati. Gli indirizzi IP dinamici vengono utilizzati per il peering BGP per i VIP di 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 sessioni di peering con l'infrastruttura esterna.

Configura il cluster per il bilanciamento del carico in bundle con BGP

Attiva e configura il bilanciamento del carico integrato con BGP nel file di configurazione del cluster quando crei un cluster. Nel file di configurazione del cluster, attiva il networking avanzato e aggiorna la sezione loadBalancer. Inoltre, devi aggiungere le specifiche 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 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 le tre risorse personalizzate per configurare il bilanciamento del carico in bundle con BGP.

  1. Aggiungi il campo advancedNetworking al file di configurazione del cluster nella sezione clusterNetwork e impostalo su true.

    Questo campo attiva la funzionalità di networking avanzato, in particolare la risorsa Gruppo di gateway di 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 del cluster Google Distributed Cloud è il nome del cluster preceduto da cluster-. Ad esempio, se il nome del cluster è test, lo spazio dei nomi è cluster-test.

  2. Nella sezione loadBalancer del file di configurazione del cluster, imposta mode su bundled e aggiungi un campo type con un valore bgp.

    Questi valori di campo 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
    ...

  3. Per specificare le informazioni sul peering BGP per il control plane, 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 del sistema autonomo per del 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 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 i node specificati partecipano alle sessioni di peering.

    Puoi specificare più peer esterni, bgpPeers accetta un elenco di mappature. Ti consigliamo di specificare almeno due peer esterni per un'alta la disponibilità per le sessioni BGP. Per un esempio con più peer, consulta Configurazioni di esempio.

  4. Imposta i campi loadBalancer.ports, loadBalancer.vips e loadBalancer.addressPools (sono mostrati i valori predefiniti).

    ...
  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
...

  5. 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>
...

  6. Prenota gli indirizzi IP mobili configurando la risorsa personalizzata NetworkGatewayGroup:

    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 per il cluster. Per impostazione predefinita, gli spazi dei nomi del cluster per Google Distributed Cloud sono il nome del cluster preceduto da cluster-. Ad esempio, se assegni al cluster il nome test, 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 ti consigliamo di specificarne almeno due.
    • 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 campo.

    Assicurati che la risorsa personalizzata NetworkGatewayGroup sia denominata default e utilizzi lo spazio dei nomi del cluster. Per un esempio di come potrebbe essere la specifica della risorsa personalizzata NetworkGatewayGroup, consulta Configurazioni di esempio.

  7. (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: lo spazio dei nomi del cluster. Per impostazione predefinita, gli spazi dei nomi del cluster per Google Distributed Cloud sono il nome del cluster preceduto da cluster-. Ad esempio, se assegni al cluster il nome test, lo spazio dei nomi è cluster-test.
    • PEER_LABEL: l'etichetta utilizzata per identificare per il bilanciamento del carico. Qualsiasi risorsa personalizzata BGPPeer con un L'etichetta corrispondente specifica i dettagli di ogni peer.

    Assicurati che la risorsa personalizzata BGPLoadBalancer sia denominata default e utilizzi la classe nello spazio dei nomi del cluster. Se non specifichi una risorsa personalizzata BGPLoadBalancer, i peer del piano di controllo vengono utilizzati automaticamente per il bilanciamento del carico del piano di dati. Per esempi completi, consulta Configurazioni di esempio.

  8. (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 per il cluster. Per impostazione predefinita, gli spazi dei nomi del cluster per Google Distributed Cloud sono il nome del cluster preceduto da cluster-. Ad esempio, se assegni al cluster il nome test, 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 alla l'etichetta specificata nella risorsa personalizzata BGPLoadBalancer.
    • CLUSTER_ASN: il numero di sistema autonomo per il 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 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 stabilire almeno due sessioni per assicurarti di mantenere una connessione con il peer nel caso in cui uno dei tuoi nodi non sia disponibile.
    • 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 campo nodeSelector nella risorsa NetworkGatewayGroups per selezionare quali nodi utilizzare per il peering con un peer esterno specifico, come Interruttore ToR. Questa operazione può richiedere più voci per selezionare NetworkGatewayGroups nel formato di un gateway per riga.

    Puoi specificare più peer esterni creando risorse personalizzate BGPPeer aggiuntive. Ti consigliamo di specificare almeno due peer esterni (due risorse personalizzate) per l'alta disponibilità per le sessioni BGP. In caso contrario specifica una risorsa personalizzata BGPPeer, vengono utilizzati i peer del piano di controllo automaticamente per il bilanciamento del carico del piano dati.

  9. Quando esegui bmctl cluster create per creare il cluster, vengono eseguiti i controlli preflight. 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 che il cluster possa essere creato.

    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 apporti aggiornamenti successivi a queste risorse. Il cluster di amministrazione riconcilia quindi le modifiche apportate al cluster utente. Se modifichi queste risorse direttamente nel cluster utente, il cluster di amministrazione sovrascrive le modifiche nelle riconciliazioni successive.

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 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 frontend (hop successivi) per un servizio di bilanciatore del carico (prefisso). Attiva ECMP nella rete in modo che il traffico possa essere distribuito su più percorsi. La possibilità di suddividere il traffico annunziando più nodi del cluster come hop successivi, consente di migliorare la scalabilità della capacità 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 flottanti a qualsiasi nodo nella stessa subnet dell'indirizzo IP flottante. Le sessioni BGP vengono avviate da questi indirizzi IP anche se non arrivano ai 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.

Configurare il bilanciamento del carico BGP con la rete dual-stack

A partire dalla release 1.14.0 di Google Distributed Cloud, il bilanciatore del carico incluso basato su BGP 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 bilanciamento del carico in bundle dual-stack 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 dual-stack, consulta Networking dual-stack IPv4/IPv6.

  • Specifica un pool di indirizzi IPv6 nel file di configurazione del cluster in spec.loadBalancer.addressPools. Affinché MetalLB possa allocare indirizzi IP a un servizio a doppio stack, deve essere presente almeno un pool di indirizzi con indirizzi in formato IPv4 e IPv6.

La seguente configurazione di esempio evidenzia le modifiche necessarie per il bilanciamento del carico integrato con BGP in dual stack:

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 control plane 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 raggiungibili da entrambi gli indirizzi IP dinamici (10.0.1.100 o 10.0.2.100) riservati al peering dei servizi loadBalancer. Gli indirizzi IP flottanti possono essere assegnati ai nodi che si trovano nella stessa subnet.

Bilanciamento del carico BGP in cui tutti i nodi utilizzano gli stessi peer

Come mostrato nel seguente esempio di configurazione del cluster, configuri i 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 tutti i peer.

Nella risorsa personalizzata NetworkGatewayGroup specifichi gli indirizzi IP flottanti da utilizzare per le sessioni di peering per il bilanciamento del carico dei servizi. In questo esempio, poiché non è specificato alcun valore per 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 control plane specifici 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 flottanti possono essere assegnati ai nodi che si trovano nella stessa subnet.

Bilanciamento del carico BGP con mappatura esplicita dei nodi del piano di controllo ai peer

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

Configurare il piano di controllo e il piano dati separatamente

Come mostrato nel seguente diagramma, questa configurazione genera due nodi del piano di controllo (10.0.1.10 e 10.0.1.11) in peering con un peer esterno (10.0.1.254) e il terzo nodo del piano di controllo (10.0.2.11) in peering con un altro peer esterno (10.0.2.254).

Un terzo peer esterno (10.0.3.254) è raggiungibile da 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 flottanti possono essere assegnati ai nodi che si trovano nella stessa subnet.

Bilanciamento del carico BGP con configurazione separata per piano di controllo e piano dati

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.

Nella risorsa personalizzata NetworkGatewayGroup specifichi gli indirizzi IP flottanti da utilizzare per le sessioni di peering per il bilanciamento del carico dei servizi.

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 peer, ad esempio cluster.baremetal.gke.io/default-peer: "true".

  • Specifica l'etichetta corrispondente per il campo peerSelector nella risorsa BGPLoadBalancer.

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

Modificare 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). Il cluster amministrativo riconcilia quindi le modifiche con il 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 nella sezione sul bilanciamento del carico del piano di controllo.

Le sezioni seguenti descrivono le best practice per aggiornare le informazioni sul peering BGP del piano di controllo.

Controllare lo stato del peer prima dell'aggiornamento

Per ridurre al minimo il rischio di configurare erroneamente i peer, controlla 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 bgp-advertiser pod registrano ready, indicando che le sessioni sono attive. Se lo stato corrente non corrisponde a quello previsto, risolvi il problema prima di aggiornare la configurazione di un 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:

  1. Aggiungi o aggiorna un singolo peer.
  2. Attendi la riconciliazione della configurazione.
  3. Verifica che il cluster sia in grado di connettersi al peer nuovo o aggiornato.
  4. 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 aver creato il cluster, modifica le risorse personalizzate NetworkGatewayGroup e BGPLoadBalancer. Eventuali modifiche alle informazioni sul peering in queste risorse personalizzate vengono applicate alla configurazione della soluzione di bilanciamento del carico nel cluster di destinazione.

Apporta aggiornamenti alle risorse di origine nello spazio dei nomi del cluster solo nel cluster di amministrazione. 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 viene convalidata con i 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 esecuzione, gli speaker BGP del control plane vengono eseguiti come pod statici su ciascun nodo del control plane e scrivono le 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 sarà simile alla 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 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 correnti. 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 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

Utilizza kubectl describe per visualizzare i dettagli sugli hop successivi di ogni route.

Recupero dell'accesso al VIP del piano di controllo per i cluster autogestiti

Per ottenere nuovamente l'accesso al VIP del control plane in un cluster di amministrazione, 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 cluster. Dopo aver salvato il nuovo della configurazione del cluster, monitora l'integrità dei pod bgpadvertiser. Se la configurazione funziona, i pod si riavviano e diventano integri una volta collegati ai peer.

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.
  • Annuncia 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, non creano connessioni di lunga durata, pertanto il debug di un errore è difficile.

Le sezioni seguenti forniscono istruzioni per configurare una connessione BGP e annunci di una route da una singola macchina del 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, quindi assicurati di testare questa procedura da uno dei nodi del piano di controllo pianificati.

Ottenere il file binario del programma di test BGP

Esegui i passaggi descritti in questa sezione sulla workstation di amministrazione. Questi passaggi recuperano il programma bgpadvertiser utilizzato per testare le connessioni BGP e lo copiano nei nodi del piano di controllo in cui vuoi eseguire il test.

  1. Estrai l'immagine Docker ansible-runner.

    Senza mirror del registry

    Se non utilizzi un mirror del registry, esegui i seguenti comandi per recuperare l'immagine Docker 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 registry, esegui i seguenti comandi 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.

  2. 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 mirror del registry

    Per estrarre il file binario bgpadvertiser, esegui il seguente comando:

    docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

  3. 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 che utilizzi per accedere al nodo del piano di controllo.

    • CP_NODE_IP: l'indirizzo IP del nodo del control plane.

Configura una connessione BGP

Esegui i passaggi descritti in questa sezione su un nodo del piano di controllo.

  1. Crea un file di configurazione sul nodo in /tmp/bgpadvertiser.conf simile al seguente:

    localIP: NODE_IP
localASN: CLUSTER_ASN
peers:
- peerIP: PEER_IP
  peerASN: PEER_ASN

    Sostituisci quanto segue:

    • NODE_IP: indirizzo IP del nodo del control plane su cui ti trovi.
    • CLUSTER_ASN: il numero di sistema autonomo utilizzato dal cluster.
    • PEER_IP: l'indirizzo IP di uno dei peer esterni che vuoi testare.
    • PEER_ASN: il numero del sistema autonomo per rete che contiene il dispositivo peer esterno.

  2. 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 in modo che l'inserzionista BGP pubblicizzi questo indirizzo al peer.

  3. 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 includono BGP_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 hai configurato una connessione BGP. Puoi verificare con l'amministratore di rete che la connessione sia stata stabilita e che veda il percorso pubblicizzato.

Test del traffico

Per verificare che la rete possa inoltrare il traffico al VIP, devi aggiungere il VIP al nodo del piano di controllo su cui è in esecuzione bgpadvertiser. Esegui questo comando in un terminale diverso, quindi puoi lasciare in esecuzione bgpadvertiser:

  1. 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 Argomento VIP --advertise-ip di bgpadvertiser.
    • INTF_NAME: il cluster Kubernetes a riga di comando sul nodo. ovvero l'interfaccia con l'indirizzo IP inserito nella configurazione di Google Distributed Cloud per loadBalancer.bgpPeers.controlPlaneNodes.

  2. 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 verificato manualmente che BGP funzioni. Se non reimposti correttamente il nodo, la configurazione manuale potrebbe interferire con il controllo preliminare o la successiva creazione del cluster.

  1. 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

  2. Sul nodo del piano di controllo, premi Ctrl+C nel terminale bgpadvertiser per interrompere bgpAdvertiser.

  3. Verifica che non siano in esecuzione processi bgpadvertiser:

    ps -ef | grep bgpadvertiser

  4. Se sono presenti processi in esecuzione, interrompili utilizzando il comando kill.