Configurazione di bilanciatori del carico integrati con BGP

I bilanciatori del carico integrati con Border Gateway Protocol (BGP) ti consentono di annunciare indirizzi IP virtuali (VIP) per il control plane e per i servizi LoadBalancer ServiceType tramite BGP esterno (eBGP) per i tuoi cluster Google Distributed Cloud. La rete del cluster agisce come un sistema autonomo che esegue il peering con una rete esterna. Quando la tua rete utilizza il routing ECMP (Equal-Cost Multipath) e il BGP ADD-PATH, questa funzionalità fornisce il bilanciamento del carico attivo/attivo N-way per un failover più rapido e un utilizzo più efficiente della larghezza di banda. Funziona con switch e router top-of-rack (ToR) di terze parti che supportano eBGP. I data center che eseguono uno stack di networking software-defined (SDN) possono anche estendere il confine del livello 3 fino ai cluster.

Questa funzionalità si applica a tutti i tipi di cluster, anche se i cluster di amministrazione supportano solo il bilanciamento del carico del control plane. Per configurare questa funzionalità nell'API GKE On-Prem, utilizza BareMetalLoadBalancerConfig per i cluster utente o, nella versione 1.34 e successive, BareMetalAdminLoadBalancerConfig per i cluster di amministrazione.

Come funziona il bilanciamento del carico in bundle con BGP

Le sezioni seguenti forniscono un breve riepilogo del funzionamento dei bilanciatori del carico in bundle con BGP.

Nota: per il bilanciamento del carico integrato con BGP, il gateway di rete per GDC gestisce le funzioni BGP, come l'annuncio di route e le sessioni di peering. Nel bilanciamento del carico integrato con BGP, utilizziamo la funzionalità MetalLB integrata solo per la gestione degli indirizzi IP (IPAM), non per le funzioni BGP. In particolare, in questa soluzione di bilanciamento del carico, MetalLB assegna gli indirizzi VIP ai servizi dall'intervallo di indirizzi IP mobili disponibili.

Peering BGP

La funzionalità dei bilanciatori del carico in bundle 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 control plane e per i VIP dei servizi.
• Le sessioni di peering del control plane vengono avviate dagli indirizzi IP dei nodi del control plane.
• Le sessioni di peering dei servizi vengono avviate da indirizzi IP mobili che specifichi nella risorsa personalizzata NetworkGatewayGroup.
• Il controller Network Gateway for 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 devono essere ridistribuite in tutta la rete e raggiungibili da qualsiasi altro punto del cluster.
• Per le sessioni di peering è consigliato l'utilizzo della funzionalità BGP ADD-PATH in modalità di ricezione.
• L'annuncio di più percorsi da ciascun peer comporta un bilanciamento del carico attivo/attivo.
• Il routing ECMP (Equal-cost multipath) deve essere abilitato per la tua rete in modo che sia possibile utilizzare più percorsi per distribuire il traffico su un insieme di nodi del bilanciatore del carico.
• Configura le sessioni BGP sui peer esterni (ad esempio gli switch Top-of-Rack) in modalità passiva. I nodi del cluster e gli indirizzi IP mobili fungono da peer attivi e avviano le sessioni di peering BGP.

Bilanciamento del carico del control plane

Ogni nodo del control plane 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 quali nodi del control plane si connettono a quali peer esterni.

Il seguente diagramma mostra un esempio di peering del control plane. Il cluster ha due nodi del control plane in una subnet e uno in un'altra. In ogni subnet è presente un peer esterno (TOR) e i nodi del control plane di Google Distributed Cloud eseguono il peering con il proprio TOR.

Nota: il diagramma illustra solo un esempio. Non è necessario che i peer si trovino nella stessa subnet. Attiviamo BGP multi-hop per impostazione predefinita.

Bilanciamento del carico dei servizi

Oltre alle sessioni di peering avviate da ciascun nodo del control plane per il peering del control plane, 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 mobili.

Nota: il bilanciamento del carico dei servizi (o del piano dati) non si applica ai cluster di amministrazione. Se includi informazioni di configurazione della sessione BGP per il piano dati nel tuo cluster di amministrazione, la configurazione viene ignorata.

I servizi con una policy di rete externalTrafficPolicy=Local sono supportati. Tuttavia, l'impostazione externalTrafficPolicy=Local dipende dal workload e fa sì che le route vengano aggiornate ogni volta che un pod che supporta il servizio viene aggiunto o rimosso completamente da un nodo. Questo comportamento di aggiornamento delle route potrebbe causare la modifica dei flussi di traffico da parte del routing ECMP (Equal Cost Multi-Path), con conseguenti cali del traffico.

Indirizzi IP mobili

Il bilanciamento del carico dei servizi richiede la prenotazione di indirizzi IP mobili nelle subnet dei nodi del cluster da utilizzare per il peering BGP. Per il cluster è richiesto almeno un indirizzo IP mobile, ma ti consigliamo di prenotare almeno due indirizzi per garantire l'alta affidabilità delle sessioni BGP. Gli indirizzi IP mobili sono specificati nella risorsa personalizzata (CR) NetworkGatewayGroup, che può essere inclusa nel file di configurazione del cluster.

Gli indirizzi IP mobili eliminano la preoccupazione di mappare gli indirizzi IP degli speaker BGP ai nodi. Il controller Network Gateway for GDC si occupa dell'assegnazione di NetworkGatewayGroup ai nodi e gestisce anche gli indirizzi IP mobili. Se un nodo non è disponibile, il controller del gateway di rete per GDC riassegna gli indirizzi IP mobili per garantire che i peer esterni abbiano un indirizzo IP deterministico con cui eseguire il peering.

Peer esterni

Per il bilanciamento del carico del piano dati, puoi utilizzare gli stessi peer esterni specificati per il peering del control plane nella sezione loadBalancer.controlPlaneBGP del file di configurazione del cluster. In alternativa, puoi specificare peer BGP diversi.

Se vuoi specificare peer BGP diversi per il peering del piano dati, aggiungi le specifiche delle risorse BGPLoadBalancer e BGPPeer al file di configurazione del cluster. Se non specifichi queste risorse personalizzate, i peer del control plane vengono utilizzati automaticamente per il data plane.

Specifica i peer esterni utilizzati per le sessioni di peering con gli indirizzi IP mobili nella risorsa personalizzata BGPPeer, che aggiungi al file di configurazione del cluster. La risorsa BGPPeer include un'etichetta per l'identificazione da parte della risorsa personalizzata BGPLoadBalancer corrispondente. Specifica l'etichetta corrispondente nel campo peerSelector della risorsa personalizzata BGPLoadBalancer per selezionare BGPPeer da utilizzare.

Il controller del gateway di rete per GDC tenta di stabilire sessioni (il numero di sessioni è configurabile) con ogni peer esterno dall'insieme di indirizzi IP mobili riservati. Ti consigliamo di specificare almeno due peer esterni per garantire l'alta affidabilità delle sessioni BGP. Ogni peer esterno designato per il bilanciamento del carico dei servizi deve essere configurato per il peering con ogni indirizzo IP mobile specificato nella risorsa personalizzata NetworkGatewayGroup.

Nodi del bilanciatore del carico

Un sottoinsieme di nodi del cluster viene utilizzato per il bilanciamento del carico, il che significa che sono i nodi pubblicizzati per poter accettare il traffico di bilanciamento del carico in entrata. Questo insieme di nodi corrisponde per impostazione predefinita al pool di nodi del control plane, ma puoi specificare un pool di nodi diverso nella sezione loadBalancer del file di configurazione del cluster. Se specifichi un pool di nodi, questo viene utilizzato per i nodi del bilanciatore del carico, anziché per il pool di nodi del control plane.

Gli indirizzi IP mobili, che funzionano come speaker BGP, possono essere eseguiti o meno sui nodi del bilanciatore del carico. Gli indirizzi IP mobili vengono assegnati a un nodo nella stessa subnet e il peering viene avviato da lì, indipendentemente dal fatto che si tratti di un nodo del bilanciatore del carico. Tuttavia, gli hop successivi annunciati tramite BGP sono sempre i nodi del bilanciatore del carico.

Esempio di topologia di peering

Il seguente diagramma mostra un esempio di bilanciamento del carico dei servizi con peering BGP. Ai nodi nelle rispettive subnet sono assegnati due indirizzi IP mobili. Sono definiti due peer esterni. Ogni IP mobile esegue il peering con entrambi i peer esterni.

Configura il bilanciatore del carico BGP

Le sezioni seguenti 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 integrato con BGP, devi configurare l'infrastruttura esterna:

• L'infrastruttura esterna deve essere configurata per il peering con ciascuno dei nodi del control plane nel cluster per configurare la comunicazione del control plane. Queste sessioni di peering vengono utilizzate per annunciare i VIP del control plane Kubernetes.

• L'infrastruttura esterna deve essere configurata per il peering con un insieme di indirizzi IP mobili riservati per la comunicazione del piano dati. Gli indirizzi IP mobili vengono utilizzati per il peering BGP per i VIP del servizio. Ti consigliamo di utilizzare due indirizzi IP mobili e due peer per garantire l'alta affidabilità delle sessioni BGP. La procedura di prenotazione dell'IP mobile è descritta nella sezione relativa alla configurazione del cluster per il bilanciamento del carico integrato con BGP.

Dopo aver configurato l'infrastruttura, aggiungi le informazioni sul peering BGP al 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 integrato con BGP

Puoi attivare e configurare 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, aggiungi 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 quali peer vengono utilizzati per il bilanciamento del carico BGP.

• BGPPeer: specifica i singoli peer, inclusa un'etichetta per la selezione, per le sessioni di peering BGP.

Le seguenti istruzioni descrivono come configurare il cluster e le tre risorse personalizzate per configurare il bilanciamento del carico in bundle con BGP.

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 Network Gateway Group.

   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 del cluster. Per impostazione predefinita, gli spazi dei nomi del cluster per Google Distributed Cloud corrispondono al nome del cluster preceduto da cluster-. Ad esempio, se assegni al cluster il nome 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 dei campi attivano 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 di 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 di sistema autonomo per il cluster in fase di creazione.
   • PEER_IP: l'indirizzo IP del dispositivo peer esterno.
   • PEER_ASN: il numero di sistema autonomo della rete che contiene il dispositivo peer esterno.
   • CP_NODE_IP: (facoltativo) l'indirizzo IP del nodo del control plane che si connette al peer esterno. Se non specifichi alcun nodo del control plane, tutti i nodi del control plane possono connettersi al peer esterno. Se specifichi uno o più indirizzi IP, solo i nodi specificati partecipano alle sessioni di peering.

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

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

   Nota: quando utilizzi il bilanciamento del carico integrato basato su BGP (mode: bundled e type: bgp), i VIP specificati non devono provenire dalla stessa subnet di uno dei nodi del cluster.

   ...
     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 control plane vengono utilizzati per il bilanciamento del carico del data plane.

   ...
     # 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 bilanciamento del carico del piano dati.

   ...
   ---
   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 namespace del cluster. Per impostazione predefinita, gli spazi dei nomi del cluster per Google Distributed Cloud corrispondono al 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 di una delle subnet del cluster. Devi specificare almeno un indirizzo IP, ma ti consigliamo di specificarne almeno due.
   • NODE_SELECTOR: (facoltativo) un selettore di etichette per identificare i nodi per la creazione di istanze di 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 apparire 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 configurando la risorsa personalizzata BGPLoadBalancer:

   ...
   ---
   apiVersion: networking.gke.io/v1
   kind: BGPLoadBalancer
   metadata:
     name: default
     namespace: CLUSTER_NAMESPACE
   spec:
     peerSelector:
       PEER_LABEL: "true"
   ...
   

   Sostituisci quanto segue:

   • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster. Per impostazione predefinita, gli spazi dei nomi del cluster per Google Distributed Cloud corrispondono al 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. Qualsiasi risorsa personalizzata BGPPeer con un'etichetta corrispondente specifica i dettagli di ogni peer.

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

8. (Facoltativo) Specifica i peer esterni per il piano dati configurando una o più risorse personalizzate BGPPeer:

   ...
   ---
   apiVersion: networking.gke.io/v1
   kind: BGPPeer
   metadata:
     name: BGP_PEER_NAME
     namespace: CLUSTER_NAMESPACE
     labels:
       PEER_LABEL: "true"
   spec:
     localASN: CLUSTER_ASN
     peerASN: PEER_ASN
     peerIP: PEER_IP
     sessions: SESSION_QTY
     selectors:   # Optional
       gatewayRefs:
       - GATEWAY_REF
     ...
   

   Sostituisci quanto segue:

   • BGP_PEER_NAME: il nome del peer.
   • CLUSTER_NAMESPACE: il namespace del cluster. Per impostazione predefinita, gli spazi dei nomi del cluster per Google Distributed Cloud corrispondono al 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 a quella 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 dispositivo peer esterno. Ti consigliamo di specificare almeno due peer esterni, ma devi specificarne almeno uno.
   • PEER_ASN: il numero di sistema autonomo della 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 al peer nel caso in cui uno dei tuoi nodi non sia disponibile.
   • GATEWAY_REF: (facoltativo) il nome di una risorsa NetworkGatewayGroup da utilizzare per il peering. Se non viene impostato, è possibile utilizzare una o tutte le risorse gateway. Utilizza questa impostazione insieme al campo nodeSelector nella risorsa NetworkGatewayGroups per selezionare i nodi da utilizzare per il peering con un peer esterno specifico, ad esempio uno switch ToR. Con un gateway per riga, possono essere necessarie più voci per selezionare più NetworkGatewayGroup.

   Puoi specificare più peer esterni creando risorse personalizzate BGPPeer aggiuntive. Ti consigliamo di specificare almeno due peer esterni (due risorse personalizzate) per l'alta affidabilità delle sessioni BGP. Se non specifichi una risorsa personalizzata BGPPeer, i peer del control plane vengono utilizzati automaticamente per il bilanciamento del carico del data plane.

   Avviso: il campo selectors (incluso gatewayRefs) in BGPPeer non è supportato quando utilizzi l'API GKE On-Prem per configurare i cluster. Se il tuo cluster utilizza più risorse NetworkGatewayGroup (ad esempio con NAT in uscita), questa limitazione può interrompere il routing esterno. Per ulteriori informazioni e una soluzione alternativa, consulta Limitazione del selettore BGP con l'API Cloud/Terraform.

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 control plane e segnalano eventuali problemi direttamente alla workstation di amministrazione prima che sia possibile creare il cluster.

   In caso di esito positivo, le risorse di bilanciamento del carico BGP aggiunte (NetworkGatewayGroup, BGPLoadBalancer e BGPPeer) vengono inserite nel cluster di amministrazione nello spazio dei nomi del cluster utente. Utilizza il file kubeconfig del cluster di amministrazione quando apporti aggiornamenti successivi a queste risorse. Il cluster di amministrazione riconcilia quindi le modifiche al cluster utente. Se modifichi queste risorse direttamente nel cluster utente, il cluster di amministrazione sovrascrive le modifiche nelle riconciliazioni successive.

Annuncia 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 annunciare ai peer un solo hop successivo per un singolo prefisso. BGP ADD-PATH consente di annunciare 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ò annunciare più nodi del cluster come nodi frontend (hop successivi) per un servizio di bilanciatore del carico (prefisso). Attiva l'ECMP nella rete in modo che il traffico possa essere distribuito su più percorsi. La possibilità di distribuire il traffico annunciando più nodi del cluster come hop successivi consente di scalare meglio la capacità del piano dati per il bilanciamento del carico.

Se il tuo 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 la limitazione dell'annuncio 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 annunciare dal pool di nodi del bilanciatore del carico e tenta di distribuire gli hop successivi per VIP diversi su nodi diversi.

Limita il peering BGP ai nodi del bilanciatore del carico

Google Distributed Cloud assegna automaticamente gli indirizzi IP mobili a qualsiasi nodo nella stessa subnet dell'indirizzo IP mobile. Le sessioni BGP vengono avviate da questi indirizzi IP anche se non arrivano ai nodi del bilanciatore del carico. Questo comportamento è intenzionale, perché abbiamo disaccoppiato il control plane (BGP) dal piano dati (node pool LB).

Se vuoi limitare l'insieme di nodi che possono essere utilizzati per il peering BGP, puoi designare una subnet da utilizzare solo per i nodi del bilanciatore del carico. In altre parole, puoi configurare tutti i nodi della subnet in modo che si trovino nel pool di nodi del bilanciatore del carico. Poi, quando configuri gli indirizzi IP mobili utilizzati per il peering BGP, assicurati che appartengano alla stessa subnet. Google Distributed Cloud garantisce che le assegnazioni degli indirizzi IP mobili e il peering BGP vengano eseguiti solo dai nodi del bilanciatore del carico.

Configura il bilanciamento del carico BGP con il networking dual-stack

A partire dalla versione 1.14.0 di Google Distributed Cloud, il bilanciatore del carico integrato basato su BGP supporta IPv6. Con l'introduzione del supporto di IPv6, puoi configurare servizi LoadBalancer IPv6 e a doppio stack su un cluster configurato per il networking a doppio stack. Questa sezione descrive le modifiche necessarie per configurare il bilanciamento del carico dual-stack in bundle con BGP.

Per abilitare i servizi LoadBalancer a doppio stack, sono necessarie le seguenti modifiche alla configurazione:

• Il cluster sottostante deve essere configurato per il networking a doppio stack:

  • Specifica i CIDR dei servizi IPv4 e IPv6 nel file di configurazione del cluster in spec.clusterNetwork.services.cidrBlocks.

  • Definisci le risorse ClusterCIDRConfig appropriate per specificare gli intervalli CIDR IPv4 e IPv6 per i pod.

  Per saperne di più 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 in bundle a doppio stack 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 in bundle a doppio stack con BGP

Quando configuri il cluster per l'utilizzo del bilanciamento del carico dual stack integrato 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 utilizzando BGP multiprotocollo.

Configurazioni di esempio

Le sezioni seguenti mostrano come configurare il bilanciamento del carico basato su BGP per diverse opzioni o comportamenti.

Configura tutti i nodi in modo che utilizzino gli stessi peer

Come mostrato nel diagramma seguente, questa configurazione genera un insieme di peer esterni (10.8.0.10 e 10.8.0.11) raggiungibili da tutti i nodi. I nodi del control plane (10.0.1.10, 10.0.1.11 e 10.0.2.10) e gli indirizzi IP mobili (10.0.1.100 e 10.0.2.100) assegnati ai nodi del data plane raggiungono tutti i peer.

Gli stessi peer esterni sono raggiungibili da uno degli indirizzi IP mobili (10.0.1.100 o 10.0.2.100) riservati per il peering dei servizi loadBalancer. Gli indirizzi IP mobili possono essere assegnati ai nodi che si trovano nella stessa subnet.

Come mostrato nell'esempio di configurazione del cluster riportato di seguito, configura i peer per i nodi del control plane, bgpPeers, senza specificare controlPlaneNodes. Se non vengono specificati nodi per i peer, tutti i nodi del control plane si connettono a tutti i peer.

Specifica gli indirizzi IP mobili da utilizzare per le sessioni di peering di bilanciamento del carico dei servizi nella risorsa personalizzata NetworkGatewayGroup. In questo esempio, poiché non è specificato BGPLoadBalancer, i peer del control plane vengono utilizzati automaticamente per le sessioni BGP del data plane.

Nota: le sezioni di configurazione del cluster che non si applicano a questa configurazione di bilanciamento del carico basata su BGP in bundle sono state rimosse per semplificare la lettura dell'esempio.

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 il peering con peer esterni specifici

Come mostrato nel diagramma seguente, questa configurazione genera due nodi del control plane (10.0.1.10 e 10.0.1.11) in peering con un peer esterno (10.0.1.254). Il terzo nodo del control plane (10.0.2.10) è in peering con un altro peer esterno (10.0.2.254). Questa configurazione è utile quando non vuoi che tutti i nodi si connettano a tutti i peer. Ad esempio, potresti voler eseguire il peering dei nodi del control plane solo con i corrispondenti switch top-of-rack (ToR).

Gli stessi peer esterni sono raggiungibili da uno degli indirizzi IP mobili (10.0.1.100 o 10.0.2.100) riservati alle sessioni di peering di bilanciamento del carico dei servizi. Gli indirizzi IP mobili possono essere assegnati ai nodi che si trovano nella stessa subnet.

Come mostrato nell'esempio di configurazione del cluster riportato di seguito, puoi limitare i nodi del control plane che 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 le sessioni di peering di bilanciamento del carico dei servizi nella risorsa personalizzata NetworkGatewayGroup. In questo esempio, poiché non è specificato alcun BGPLoadBalancer, i peer del control plane vengono utilizzati automaticamente per le sessioni BGP del data plane.

Nota: le sezioni di configurazione del cluster che non si applicano a questa configurazione di bilanciamento del carico basata su BGP in bundle sono state rimosse per semplificare la lettura dell'esempio.

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 separatamente il control plane e il piano dati

Come mostrato nel diagramma seguente, questa configurazione genera due nodi del control plane (10.0.1.10 e 10.0.1.11) in peering con un peer esterno (10.0.1.254) e il terzo nodo del control plane (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 indirizzi IP mobili (10.0.3.100 o 10.0.3.101) riservati alle sessioni di peering di bilanciamento del carico dei servizi. Gli indirizzi IP mobili possono essere assegnati ai nodi che si trovano nella stessa subnet.

Come mostrato nell'esempio di configurazione del cluster riportato di seguito, puoi limitare i nodi del control plane che 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 le sessioni di peering di bilanciamento del carico dei servizi nella risorsa personalizzata NetworkGatewayGroup.

Per configurare il bilanciamento del carico del piano dati:

• Specifica il peer esterno per il piano dati nella risorsa BGPPeer e aggiungi un'etichetta da utilizzare per la selezione del peer, ad esempio cluster.baremetal.gke.io/default-peer: "true".

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

Nota: le sezioni di configurazione del cluster che non si applicano a questa configurazione di bilanciamento del carico basata su BGP in bundle sono state rimosse per semplificare la lettura dell'esempio.

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 l'utilizzo del bilanciamento del carico integrato 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 alle risorse relative a BGP (NetworkGatewayGroup, BGPLoadBalancer e BGPPeer). Il cluster di amministrazione riconcilia quindi le modifiche al cluster utente. Se modifichi queste risorse direttamente nel cluster utente, il cluster di amministrazione sovrascrive le modifiche nelle riconciliazioni successive.

Control plane

Le informazioni sul peering BGP del control plane possono essere aggiornate nella risorsa Cluster. Puoi aggiungere o rimuovere i peer specificati nella sezione del bilanciamento del carico del control plane.

Avviso: fai attenzione quando aggiorni le informazioni di peering BGP del control plane, in particolare per i cluster autogestiti (cluster di tipo admin, ibrido o autonomo). Il VIP del control plane e il control plane Kubernetes diventano inaccessibili dall'esterno del cluster se il cluster non è in grado di annunciare il VIP del control plane a nessuno dei peer. Ad esempio, l'accesso viene perso se la configurazione del peering non fa riferimento a un peer valido o se il cluster non è in grado di connettersi al peer a causa di una configurazione errata o di problemi di rete. Per istruzioni su come recuperare l'accesso, consulta Recupero dell'accesso al VIP del control plane per i cluster autogestiti.

Le sezioni seguenti descrivono le best practice per l'aggiornamento delle informazioni di peering BGP del control plane.

Controlla lo stato del peer prima dell'aggiornamento

Per ridurre al minimo il rischio di configurare in modo errato i peer, verifica che le sessioni di peering BGP del control plane siano nello stato previsto prima di apportare modifiche. Ad esempio, se ti aspetti che tutte le sessioni di peering BGP siano attive, verifica che tutti i pod bgp-advertiser segnalino ready, a indicare che le sessioni sono attive. Se lo stato attuale non corrisponde a quello previsto, risolvi il problema prima di aggiornare una configurazione peer.

Per informazioni sul recupero dei dettagli delle sessioni BGP del control plane, consulta Sessioni BGP del control plane.

Aggiorna i peer in modo controllato

Se possibile, aggiorna un peer alla volta per isolare eventuali 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 peer obsoleti o non necessari.

Servizi

Per aggiornare i pool di indirizzi e le impostazioni dei nodi del bilanciatore del carico, modifica nodePoolSpec nella risorsa Cluster.

Avviso: fai attenzione quando aggiorni le informazioni di peering per i servizi del piano dati. Se le informazioni di peering non sono configurate correttamente e il cluster non può stabilire sessioni BGP con i peer e annunciare i VIP, i client non possono accedere ai servizi tramite i VIP LoadBalancer. Ti consigliamo di aggiornare la configurazione un peer alla volta, come descritto nella sezione precedente, per ridurre al minimo il rischio di errori di configurazione.

Per modificare la configurazione del peering BGP dopo la creazione del cluster, modifica le risorse personalizzate NetworkGatewayGroup e BGPLoadBalancer. Eventuali modifiche alle informazioni di peering in queste risorse personalizzate si riflettono nella configurazione della soluzione di bilanciamento del carico nel cluster di destinazione.

Apporta aggiornamenti alle risorse di origine nello spazio dei nomi del cluster solo nel cluster di amministrazione. Le modifiche apportate alle risorse nel cluster di destinazione (utente) vengono sovrascritte.

Risoluzione dei problemi

Le sezioni seguenti descrivono come accedere alle informazioni per la risoluzione dei problemi relativi al bilanciamento del carico integrato con BGP.

Sessioni BGP del control plane

La configurazione del peering BGP del control plane viene convalidata con controlli preflight durante la creazione del cluster. I controlli preflight tentano di:

• Stabilire una connessione BGP con ogni peer.
• Annuncia il VIP del control plane.
• Verifica che il nodo del control plane sia raggiungibile utilizzando il VIP.

Se la creazione del cluster non supera i controlli preflight, esamina i log dei controlli preflight per individuare eventuali errori. I file di log dei controlli preflight con data e ora si trovano nella directory baremetal/bmctl-workspace/CLUSTER_NAME/log.

In fase di runtime, gli speaker BGP del control plane vengono eseguiti come pod statici su ogni nodo del control plane e scrivono le informazioni sugli eventi nei log. Questi pod statici includono "bgpadvertiser" nel nome, quindi utilizza il seguente comando kubectl get pods per visualizzare lo stato dei pod speaker BGP:

kubectl -n kube-system get pods | grep bgpadvertiser

Nota: la condizione di idoneità dei pod bgpadvertiser del control plane è legata allo stato delle sessioni BGP. Ciò significa che un pod viene dichiarato pronto solo quando tutte le sue sessioni BGP sono attive. Se una delle sessioni BGP del pod non è attiva, la condizione Ready del pod diventa False.

Quando i pod funzionano correttamente, la risposta è 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 del 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. Per ottenere informazioni sulla sessione, recupera prima le sessioni correnti, quindi recupera la risorsa BGPSession per una delle sessioni.

Utilizza il seguente comando kubectl get per elencare le sessioni attuali:

kubectl -n kube-system get bgpsessions

Il comando restituisce un elenco di sessioni simile al seguente esempio:

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

Utilizza il seguente comando kubectl describe per ottenere la risorsa BGPSession per la sessione BGP 10.0.1.254-node-01:

kubectl -n kube-system describe bgpsession 10.0.1.254-node-01

La risorsa BGPSession restituita dovrebbe essere simile 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

Utilizza il comando kubectl get per ottenere le risorse BGPAdvertisedRoute:

kubectl -n kube-system get bgpadvertisedroutes

La risposta, che dovrebbe essere simile al seguente esempio, mostra le route annunciate:

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 annunciati da ogni route.

Recupero dell'accesso al VIP del control plane per i cluster autogestiti

Per riottenere l'accesso al VIP del control plane su un cluster di amministrazione, ibrido o autonomo, devi aggiornare la configurazione BGP sul cluster. Come mostrato nell'esempio di comando riportato di seguito, utilizza SSH per connetterti al nodo, quindi utilizza kubectl per aprire la risorsa del cluster per la modifica.

ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP

kubectl --kubeconfig /etc/kubernetes/admin.conf edit -n CLUSTER_NAMESPACE cluster CLUSTER_NAME

Sostituisci quanto segue:

• IDENTITY_FILE: il nome del file di identità SSH che contiene la chiave di identità per l'autenticazione a 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 la nuova configurazione del cluster, monitora lo stato dei pod bgpadvertiser. Se la configurazione funziona, i pod vengono riavviati e diventano integri una volta connessi ai peer.

Verifica manuale del BGP

Questa sezione contiene le istruzioni per verificare manualmente la configurazione BGP. La procedura configura una connessione BGP di lunga durata in modo da poter eseguire ulteriormente il debug della configurazione BGP con il tuo team di rete. Utilizza questa procedura per verificare la configurazione prima di creare un cluster o 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 control plane.
• Verifica che il traffico inviato da tutti gli altri nodi del cluster al VIP raggiunga il nodo del bilanciatore del carico corrente.

Queste attività vengono eseguite per ogni peer BGP su ogni nodo del control plane. Il superamento di questi controlli è fondamentale durante la creazione di un cluster. Tuttavia, i controlli preflight non creano connessioni a lunga esecuzione, quindi il debug di un errore è difficile.

Le sezioni seguenti forniscono istruzioni per configurare una connessione BGP e annunciare una route da una singola macchina del cluster a un peer. Per testare più macchine e più peer, ripeti le istruzioni utilizzando una combinazione di macchina e peer diversa.

Ricorda che le connessioni BGP vengono stabilite dai nodi del control plane, quindi assicurati di testare questa procedura da uno dei nodi del control plane pianificati.

Ottieni il file binario del programma di test BGP

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

1. Esegui il pull dell'immagine Docker ansible-runner.

   Senza Registry Mirror

   Se non utilizzi un mirror del registry, esegui i seguenti comandi per eseguire il pull dell'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 mirror del registry

   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 file binario bgpadvertiser.

   Senza Registry Mirror

   Per estrarre il file 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 questo comando:

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

3. Per copiare il file binario bgpadvertiser nel nodo del control plane con cui vuoi 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 control plane.

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

Configura una connessione BGP

Esegui i passaggi di questa sezione su un nodo del control plane.

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: l'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 di sistema autonomo della rete che contiene il dispositivo peer esterno.

2. Esegui il daemon bgpadvertiser, sostituendo il VIP del control plane 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 control plane. Questo comando fa sì che l'annunciatore BGP annunci questo indirizzo al peer.

3. Visualizza l'output del programma.

   A questo punto, il daemon bgpadvertiser si avvia, tenta di connettersi al peer e annuncia il VIP. Il programma stampa periodicamente 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, controlla i parametri di configurazione BGP nel file di configurazione e verifica con l'amministratore di rete. Ora hai configurato una connessione BGP. Puoi verificare con l'amministratore di rete che la connessione sia stabilita sul suo lato e che la route sia pubblicizzata.

Test del traffico

Per verificare che la rete possa inoltrare il traffico al VIP, devi aggiungere il VIP al nodo del control plane che esegue bgpadvertiser. Esegui questo comando in un terminale diverso in modo da poter lasciare bgpadvertiser in esecuzione:

1. Aggiungi il VIP al nodo del control plane:

   ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME
   

   Sostituisci quanto segue:

   • CONTROL_PLANE_VIP: l'argomento VIP --advertise-ip di bgpadvertiser.
   • INTF_NAME: l'interfaccia Kubernetes sul nodo. In altre parole, l'interfaccia che ha l'indirizzo IP che hai 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 va a buon fine, potrebbe esserci un problema con la configurazione BGP sul dispositivo di rete. Collabora con l'amministratore di rete per verificare la configurazione e risolvere il problema.

Esegui la pulizia

Assicurati di seguire questi passaggi per reimpostare il nodo dopo aver verificato manualmente che BGP funzioni. Se non reimposti correttamente il nodo, la configurazione manuale potrebbe interferire con il controllo preflight o con la successiva creazione del cluster.

1. Rimuovi il VIP dal nodo del control plane se lo hai aggiunto per il test del traffico:

   ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME
   

2. Sul nodo del control plane, premi Ctrl+C nel terminale bgpadvertiser per arrestare bgpadvertiser.

3. Verifica che non siano in esecuzione processi bgpadvertiser:

   ps -ef | grep bgpadvertiser
   

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

Limitazione del selettore BGP con l'API Cloud/Terraform

Quando gestisci i cluster Google Distributed Cloud utilizzando l'API GKE On-Prem (Terraform, la console Google Cloud o l'interfaccia a riga di comando gcloud), non puoi specificare i selettori BGP nella configurazione del cluster. Se il cluster utilizza il bilanciamento del carico BGP e il NAT in uscita, il peering BGP potrebbe non riuscire.

Soluzione alternativa

Per eseguire override manuali, devi impostare la configurazione del bilanciatore del carico su "unmanaged" nel cluster di amministrazione. Questa impostazione impedisce all'API GKE On-Prem di riconciliare automaticamente le modifiche al bilanciatore del carico.

1. Applica l'anti-affinità IP: suddividi il tuo NetworkGatewayGroup BGP in risorse NetworkGatewayGroup separate (una per IP mobile) e utilizza nodeSelector in ogni NetworkGatewayGroup per assegnare l'IP mobile a un nodo fisico specifico. In questo modo, più IP BGP non vengono assegnati allo stesso nodo.
2. Annulla la gestione del bilanciatore del carico: nel cluster di amministrazione, rimuovi l'annotazione baremetal.cluster.gke.io/managed: "true" dalla risorsa BGPLoadBalancer nello spazio dei nomi del cluster utente. In questo modo, i controller GDC non annullano le modifiche manuali.
3. Applica patch alle risorse BGPPeer: applica manualmente patch alle risorse BGPPeer nel cluster di amministrazione per aggiungere il blocco selectors che fa riferimento alle risorse NetworkGatewayGroup e agli IP mobili corretti. Queste modifiche vengono sincronizzate con il cluster utente e stabilizzano le sessioni BGP.