Configurazione di bilanciatori del carico integrati con BGP

Questo documento descrive come configurare e utilizzare i bilanciatori del carico in bundle con Border Gateway Protocol (BGP) per Anthos clusters on bare metal. Questa modalità di bilanciamento del carico supporta la pubblicità di indirizzi IP virtuali (VIP) ServiceType LoadBalancer tramite un protocollo BGP (eBGP) esterno per i tuoi cluster. In questo scenario, la rete del tuo cluster è un sistema autonomo che interconnette con un altro sistema autonomo, una rete esterna, tramite peering.

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

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

  • Utilizza la funzionalità di bilanciamento del carico attiva/attiva N-way, che consente un failover più rapido e un utilizzo più efficiente della larghezza di banda disponibile.
  • Supporta il protocollo Layer 3 che interagisce con gli switch top-of-rack di terze parti (ToR) e con i router compatibili con eBGP.
  • Abilita i data center che eseguono uno stack di rete definito dal software avanzato (SDN) per effettuare il push del confine del livello 3 fino ai cluster.

Come funziona il bilanciamento del carico in bundle con BGP

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

Peering BGP

I bilanciatori del carico in bundle con funzionalità BGP avviano diverse connessioni BGP all'infrastruttura. BGP ha i seguenti requisiti tecnici:

  • Le sessioni di peering sono separate per il VIP del piano di controllo e per i VIP del servizio.
  • Le sessioni di peering del piano di controllo vengono avviate dagli indirizzi IP dei nodi del piano di controllo.
  • Le sessioni di peering di servizio vengono avviate dagli indirizzi IP mobili che specifichi nella risorsa personalizzata AnthosNetworkGateway.
  • Il controller gateway di rete Anthos 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 pubblicizzate con qualsiasi peer dovrebbero essere ridistribuite in tutta la rete e raggiungibili da qualsiasi altra parte del cluster.
  • L'utilizzo della funzionalità BGP ADD-PATH in modalità di ricezione è vivamente consigliato per le sessioni di peering.
  • Promuovere più percorsi da ciascun peer risulta in un bilanciamento del carico attivo/attivo.
  • Il routing multipath (ECMP) a parità di costo deve essere abilitato per la tua rete in modo da poter utilizzare più percorsi per distribuire il traffico in un insieme di nodi del bilanciatore del carico.

Bilanciamento del carico del piano di controllo

Ogni nodo del piano di controllo nel cluster stabilisce le sessioni BGP con uno o più peer nell'infrastruttura. Richiediamo che ogni nodo del piano di controllo abbia almeno un peer. Nel file di configurazione del cluster, puoi configurare quali nodi del piano di controllo si connettono a quali peer esterni.

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. In ogni subnet è presente un peer esterno (TOR) e i nodi del piano di controllo di Anthos clusters on bare metal con il relativo TOR.

Bilanciamento del carico di servizio con peering BGP

Bilanciamento del carico di servizio

Oltre alle sessioni di peering avviate da ciascun nodo del piano di controllo per il peering del piano di controllo, vengono avviate sessioni di peering aggiuntive per i servizi LoadBalancer. Queste sessioni di peering non vengono avviate direttamente dagli IP dei nodi del cluster, ma utilizzano IP mobili.

I servizi con un criterio di rete externalTrafficPolicy=Local non sono supportati.

Indirizzi IP mobili

Il bilanciamento del carico del servizio richiede la prenotazione di indirizzi IP mobili nelle subnet dei nodi del cluster da utilizzare per il peering BGP. È richiesto almeno un indirizzo IP mobile per il cluster, ma ti consigliamo di prenotare almeno due indirizzi per garantire l'alta disponibilità per le sessioni BGP. Gli indirizzi IP mobili sono specificati nella risorsa personalizzata (CR) AnthosNetworkGateway, 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 Gateway di rete Anthos si occupa di assegnare AnthosNetworkGateway ai nodi e gestisce anche gli indirizzi IP mobili. Se un nodo smette di funzionare, il controller Anthos Network Gateway riassegna gli indirizzi IP mobili per garantire che i peer esterni abbiano un indirizzo IP deterministico con cui effettuare il peering.

Peer esterni

Devi specificare i peer esterni utilizzati per le sessioni di peering con indirizzi IP mobili nella risorsa personalizzata BGPLoadBalancer, che aggiungi al file di configurazione del cluster. I peer esterni possono essere gli stessi specificati per il peering del piano di controllo nella sezione loadBalancer.controlPlaneBGP del file di configurazione del cluster. In alternativa, puoi specificare peer diversi.

Il controller Gateway di rete Anthos tenta di stabilire due sessioni per ogni peer esterno dal set di indirizzi IP mobili prenotati. Consigliamo di specificare almeno due peer esterni per garantire l'alta disponibilità per le sessioni BGP. Ogni peer esterno designato per il bilanciamento del carico dei servizi deve essere configurato per il peering con ogni indirizzo IP mobile specificato nella risorsa personalizzata AnthosNetworkGateway.

Nodi del bilanciatore del carico

Un sottoinsieme di nodi dal cluster viene utilizzato per il bilanciamento del carico, il che significa che sono i nodi pubblicizzati per essere in grado di accettare il traffico di bilanciamento del carico in entrata. Per impostazione predefinita, questo set di nodi è associato al pool di nodi del piano di controllo, ma puoi specificare un pool di nodi diverso nella sezione loadBalancer del file di configurazione del cluster. Se specifichi un pool di nodi, viene utilizzato per i nodi del bilanciatore del carico, anziché il pool di nodi del piano di controllo.

Gli indirizzi IP mobili, che funzionano come speaker BGP, possono o meno essere eseguiti 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 pubblicizzati tramite BGP sono sempre i nodi del bilanciatore del carico.

Esempio di topologia di peering

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

Bilanciamento del carico di servizio con peering BGP

Configurazione del bilanciatore del carico BGP

Le sezioni seguenti descrivono come configurare i cluster e la rete esterna per l'utilizzo del bilanciatore del carico in bundle con BGP.

Pianifica l'integrazione con infrastrutture esterne

Per utilizzare il bilanciatore del carico in bundle con BGP, devi configurare l'infrastruttura esterna:

  • Per configurare la comunicazione con il piano di controllo, devi configurare l'infrastruttura esterna in modo che esegua il peering con ciascuno dei nodi del piano di controllo nel cluster. Queste sessioni di peering vengono utilizzate per pubblicizzare i VIP del piano di controllo Kubernetes.

  • L'infrastruttura esterna deve essere configurata per il peering con un insieme di indirizzi IP mobili con prenotazione per la comunicazione sul piano dati. Gli indirizzi IP mobili vengono utilizzati per il peering BGP per i VIP del servizio. Consigliamo di utilizzare due indirizzi IP mobili e due peer per garantire l'alta disponibilità per le sessioni BGP. Il processo di prenotazione di IP mobile è descritto come parte della configurazione del cluster per il bilanciamento del carico in bundle con il 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 in bundle con BGP

Puoi abilitare e configurare il bilanciamento del carico in bundle con BGP nel file di configurazione del cluster quando crei un cluster.

  1. Aggiungi l'annotazione baremetal.cluster.gke.io/enable-anthos-network-gateway al file di configurazione del cluster e impostala su true.

    Questa annotazione consente il controller Gateway di rete Anthos.

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
  # This annotation is required for BGP load balancer
  annotations:
    baremetal.cluster.gke.io/enable-anthos-network-gateway: "true"
spec:
...

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

    Questi valori di campo consentono il bilanciamento del carico in bundle basato su BGP.

    ...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp
    ...

  3. Per specificare le informazioni sul peering BGP per il piano di controllo, aggiungi i seguenti campi alla sezione loadBalancer:

        ...
    # AS number for the cluster
    localASN: CLUSTER_ASN

    # List of BGP peers used for the control plane peering sessions.
    bgpPeers:
    - ip: PEER_IP
      asn: PEER_ASN
      # optional; if not specified, all CP nodes connect to all peers.
      controlPlaneNodes:   # optional
      - CP_NODE_IP
...

    Sostituisci quanto segue:

    • CLUSTER_ASN: il numero di sistema autonomo per il cluster che viene creato.
    • PEER_IP: l'indirizzo IP del dispositivo peer esterno.
    • PEER_ASN: il numero di sistema autonomo della rete che contiene il dispositivo peer esterno.
    • (Facoltativo) CP_NODE_IP: l'indirizzo IP del nodo del piano di controllo che si connette al peer esterno. Se non specifichi alcun nodo del piano di controllo, tutti i nodi del piano di controllo possono connettersi al peer esterno. Se specifichi uno o più indirizzi IP, solo i nodi specificati partecipano alle sessioni di peering.

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

    Questa configurazione di peering BGP per il piano di controllo non può essere aggiornata dopo la creazione del cluster.

  4. Imposta i campi loadBalancer.ports, loadBalancer.vips e loadBalancer.addressPools (vengono visualizzati 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 annulli il commento della 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 indirizzi IP mobili configurando la risorsa personalizzata AnthosNetworkGateway:

    Gli indirizzi IP mobili vengono utilizzati nelle sessioni di peering per il bilanciamento del carico del piano dati.

    ...
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
...

    Sostituisci quanto segue:

    • CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi dei cluster per Anthos clusters on bare metal sono i nomi dei cluster preceduti da cluster-. Ad esempio, se il nome del cluster è test, lo spazio dei nomi sarà cluster-test.
    • FLOATING_IP: un indirizzo IP da una delle subnet del cluster. Devi specificare almeno un indirizzo IP, ma ti consigliamo di specificarne almeno due.

    Per un esempio dell'aspetto della specifica personalizzata delle risorse AnthosNetworkGateway, consulta la sezione Configurazioni di esempio.

  7. Specifica le informazioni di peering BGP per il piano dati configurando la risorsa personalizzata BGPLoadBalancer:

    ...
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: CLUSTER_NAMESPACE
spec:
  localASN: CLUSTER_ASN
  peers:
  - peerIP: PEER_IP
    peerASN: PEER_ASN
    ...

    Sostituisci quanto segue:

    • CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi dei cluster per Anthos clusters on bare metal sono i nomi dei cluster preceduti da cluster-. Ad esempio, se il nome del cluster è test, lo spazio dei nomi sarà cluster-test.
    • CLUSTER_ASN: il numero di sistema autonomo per il cluster che viene creato.
    • PEER_IP: l'indirizzo IP del dispositivo peer esterno. Devi specificare almeno un peer esterno, ma consigliamo di specificarne almeno due. Puoi utilizzare gli stessi peer specificati nel piano di controllo.
    • PEER_ASN: il numero di sistema autonomo della rete che contiene il dispositivo peer esterno.

    Puoi specificare più peer esterni, peers prende un elenco di coppie di mappatura. Ti consigliamo di specificare almeno due peer esterni per garantire l'alta disponibilità per le sessioni BGP. Per un esempio con più peer, consulta Configurazioni di esempio.

  8. Quando esegui bmctl cluster create, per creare il tuo cluster, vengono eseguiti i controlli preflight. Tra gli altri controlli, i controlli preflight convalidano la configurazione di peering BGP per il piano di controllo e segnalano eventuali problemi direttamente alla workstation di amministrazione prima della creazione del cluster.

Promuovere più hop successivi per sessione con ADD-PATH di BGP

Consigliamo vivamente di utilizzare la funzionalità BGP ADD-PATH per le sessioni di peering come specificato in RFC 7911. Per impostazione predefinita, il protocollo BGP consente di pubblicizzare un solo hop successivo ai peer per un singolo prefisso. BGP ADD-PATH consente di pubblicizzare più hop successivi per lo stesso prefisso. Quando ADD-PATH viene utilizzato con il bilanciamento del carico in bundle basato su BGP, il cluster può pubblicizzare più nodi cluster come nodi frontend (hop successivi) per un servizio bilanciatore del carico (prefisso). Abilita ECMP nella rete in modo che il traffico possa essere distribuito su più percorsi. La capacità di ventilare il traffico pubblicizzando più nodi cluster come hop successivi, fornisce una migliore scalabilità della capacità del piano dati per il bilanciamento del carico.

Se il tuo dispositivo peer esterno, ad esempio uno switch top-of-rack (ToR) o un router, 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 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, Anthos clusters on bare metal sceglie i nodi da pubblicizzare dal pool di nodi del bilanciatore del carico e tenta di distribuire gli hop successivi per diversi VIP tra nodi diversi.

Limita il peering BGP ai nodi del bilanciatore del carico

Nella versione di anteprima di questa funzionalità, Anthos clusters on bare metal assegna automaticamente indirizzi IP mobili su qualsiasi nodo nella stessa subnet dell'indirizzo IP mobile. Le sessioni BGP vengono avviate da questi indirizzi IP anche se non arrivano sui nodi del bilanciatore del carico. Questo comportamento è in base alla progettazione, perché abbiamo disaccoppiato il piano di controllo (BGP) dal piano dati (pool di nodi LB).

Se vuoi limitare l'insieme di nodi utilizzabili per il peering BGP, puoi designare una subnet da utilizzare solo per i nodi del bilanciatore del carico. In altre parole, puoi configurare che tutti i nodi della subnet siano nel pool di nodi del bilanciatore del carico. Quando configuri gli indirizzi IP mobili che vengono utilizzati per il peering BGP, assicurati che provengano dalla stessa subnet. Anthos clusters on bare metal assicurano che le assegnazioni degli indirizzi IP mobili e il peering BGP avvengano solo dai nodi del bilanciatore del carico.

Esempi di configurazioni

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

Configura tutti i nodi che utilizzano gli stessi peer

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

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

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

Come mostrato nell'esempio di configurazione del cluster seguente, configuri i peer per i nodi del piano di controllo, bgpPeers, senza specificare controlPlaneNodes. Se non sono specificati nodi per i peer, tutti i nodi del piano di controllo si connettono a tutti i peer.

Specifica gli indirizzi IP mobili da utilizzare per le sessioni di peering di bilanciamento del carico dei servizi nella risorsa personalizzata AnthosNetworkGateway. Devi specificare i peer esterni corrispondenti 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.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: cluster-bm
spec:
  localASN: 65001
  peers:
  - peerIP: 10.8.0.10
    peerASN: 65002
  - peerIP: 10.8.0.11
    peerASN: 65002

Configura nodi di piano di controllo specifici per il peering con peer esterni specifici

Come mostrato nel diagramma seguente, questa configurazione si traduce in 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). Il terzo nodo del piano di controllo (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 piano di controllo solo con gli switch ToR (top-of-rack) corrispondenti.

Gli stessi peer esterni sono raggiungibili tramite uno degli indirizzi IP mobili (10.0.1.100 o 10.0.2.100) prenotati per le sessioni di peering di bilanciamento del carico dei servizi. Gli indirizzi IP mobili possono essere assegnati a nodi che si trovano nella stessa subnet.

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

Come mostrato nel seguente esempio di configurazione del cluster, limiti i nodi del piano di controllo 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 AnthosNetworkGateway. Devi specificare i peer esterni corrispondenti 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.10

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: cluster-bm
spec:
  localASN: 65001
  peers:
  - peerIP: 10.0.1.254
    peerASN: 65002
  - peerIP: 10.0.2.254
    peerASN: 65002

Configura separatamente il piano di controllo e il piano dati

Come mostrato nel diagramma seguente, questa configurazione genera due peering 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.10) 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) prenotati per le sessioni di peering di bilanciamento del carico dei servizi. Gli indirizzi IP mobili possono essere assegnati a nodi che si trovano nella stessa subnet.

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

Come mostrato nel seguente esempio di configurazione del cluster, limiti i nodi del piano di controllo 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 AnthosNetworkGateway. Devi specificare i peer esterni corrispondenti 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/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
  name: bgplb
  namespace: cluster-bm
spec:
  bgp:
    localASN: 65001
    peers:
    - peerIP: 10.0.3.254
      peerASN: 65002

Modifica della configurazione di bilanciamento del carico basata su BGP

Dopo aver creato il cluster per l'utilizzo del bilanciamento del carico in bundle con BGP, è possibile aggiornare alcune impostazioni di configurazione, ma non è possibile aggiornarle dopo la creazione del cluster.

Piano di controllo

Le modifiche alla configurazione del bilanciamento del carico del piano di controllo non sono supportate durante l'anteprima.

Servizi

Puoi modificare la configurazione di peering BGP dopo che il cluster è stato creato modificando la RP AnthosNetworkGateway e la RP BGPLoadBalancer. Eventuali modifiche alle informazioni di peering in queste RP si riflettono nella configurazione della soluzione di bilanciamento del carico nel cluster di destinazione.

Aggiorna solo le risorse di origine nello spazio dei nomi del cluster nel cluster di amministrazione. Qualsiasi modifica apportata alle risorse nel cluster di destinazione (utente) viene sovrascritta.

Risolvere i problemi

Le seguenti sezioni descrivono come accedere alle informazioni per la risoluzione dei problemi per il bilanciamento del carico in bundle con BGP.

Sessioni BGP del piano di controllo

La configurazione del peering BGP del piano di controllo viene convalidata con i controlli preflight in fase di creazione durante la creazione del cluster. I controlli preflight provano a:

  • Stabilisci una connessione BGP con ogni peer.
  • Pubblicizzare il VIP del piano di controllo.
  • Verifica che sia possibile raggiungere il nodo del piano di controllo utilizzando il VIP.

Se la creazione del cluster non supera i controlli preflight, controlla i log di controllo preflight per individuare eventuali errori. I file del log di controllo preliminare di Datestamp si trovano nella directory baremetal/bmctl-workspace/CLUSTER_NAME/log.

In fase di esecuzione, gli altoparlanti BGP del piano di controllo vengono eseguiti come pod statici su ciascun nodo del piano di controllo e scrivono le informazioni degli eventi nei log. Questi pod statici includono "bgpadvertiser" nel proprio nome, quindi utilizza il seguente comando kubectl get pods per visualizzare lo stato dei pod dell'altoparlante BGP:

kubectl -n kube-system  get pods | grep bgpadvertiser

Quando i pod funzionano correttamente, la risposta dovrebbe essere 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 comando seguente per visualizzare i log per il pod bgpadvertiser-node-01:

kubectl -n kube-system  logs bgpadvertiser-node-01

Sessioni BGP dei servizi

La risorsa BGPSession fornisce informazioni sulle sessioni BGP attuali. Per ottenere le informazioni sulle sessioni, recupera prima le sessioni attuali, 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 come nel seguente esempio:

NAME                            AGE
10.0.1.254-node-01              170m
10.0.1.254-node-05              170m
10.0.3.254-node-01              170m
10.0.3.254-node-05              170m

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

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

La risorsa BGPSession restituita dovrebbe essere simile all'esempio seguente:

Name:         10.0.1.254-node-01
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1alpha1
Kind:         BGPSession
Metadata:
 (omitted)
Spec:
  Floating IP:  10.0.1.178
  Local ASN:    65500
  Local IP:     10.0.1.178
  Node Name:    node-01
  Peer ASN:     65000
  Peer IP:      10.0.1.254
Status:
  Advertised Routes:
    10.0.4.1/32
  Last Report Time:  2021-06-14T22:09:36Z
  State:             Established

Utilizza il comando kubectl get per ottenere le risorse BGPAdvertisedRoute:

kubectl -n kube-system get bgpadvertisedroutes

La risposta, che dovrebbe essere simile all'esempio seguente, mostra i percorsi attualmente pubblicizzati:

NAME                                  AGE
bgplb-default-load-balancer-example   5d5h
bgplb-gke-system-istio-ingress        6d

Utilizza kubectl describe per visualizzare i dettagli relativi ai successivi hop successivi della pubblicità.

Verifica manuale del BGP

Questa sezione contiene le istruzioni per verificare manualmente la configurazione BGP. La procedura imposta una connessione BGP a lunga esecuzione in modo da poter eseguire un ulteriore debug della configurazione BGP con il tuo team di rete. Utilizza questa procedura per verificare la configurazione prima di creare un cluster o utilizzala se i controlli preflight relativi a BGP non vanno a buon fine.

I controlli preflight automatizzano le seguenti attività di verifica BGP:

  • Configurare una connessione BGP a un peer.
  • Pubblicizzare il VIP del piano di controllo.
  • Verifica che il traffico inviato da tutti gli altri nodi del cluster al VIP raggiunga il nodo del bilanciatore del carico attuale.

Queste attività vengono eseguite per ciascun peer BGP su ciascun nodo del piano di controllo. Superare questi controlli è fondamentale quando si crea un cluster. I controlli preflight, tuttavia, non creano connessioni a lunga esecuzione, quindi il debug di un errore è difficile.

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

Ricorda che le connessioni BGP vengono stabilite dai nodi del piano di controllo, quindi assicurati di testare questa procedura da uno dei nodi del piano di controllo pianificato.

Ottieni il programma binario del programma di test BGP

Esegui i passaggi in questa sezione sulla workstation di amministrazione. Questi passaggi consentono di ottenere il programma bgpadvertiser, utilizzato per testare le connessioni BGP e copiarlo per controllare i nodi del piano su cui vuoi eseguire il test.

  1. Esegui il pull dell'immagine docker runner ansible.

    Senza mirroring del Registro di sistema

    Se non utilizzi un mirror del Registro di sistema, esegui questi comandi per eseguire il pull dell'immagine docker runner applicabile:

    gcloud auth login
gcloud auth configure-docker
docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Con specchio del Registro di sistema

    Se utilizzi un mirror del Registro di sistema, esegui i comandi seguenti per eseguire il pull dell'immagine docker ansible-runner:

    docker login REGISTRY_HOST
docker pull REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Sostituisci REGISTRY_HOST con il nome del tuo server mirror del registry.

  2. Per estrarre il programma binario di bgpadvertiser.

    Senza mirroring del Registro di sistema

    Per estrarre il programma binario di bgpadvertiser, esegui il comando seguente:

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

    Con specchio del Registro di sistema

    Per estrarre il programma binario di bgpadvertiser, esegui il comando seguente:

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

  3. Per copiare il programma binario di bgpadvertiser nel nodo del piano di controllo con cui vuoi eseguire il test, esegui il comando seguente:

    scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/

    Sostituisci quanto segue:

    • USERNAME: il nome utente che utilizzi per accedere al nodo del piano di controllo.

    • CP_NODE_IP: l'indirizzo IP del nodo del piano di controllo.

Configura una connessione BGP

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

  1. Crea un file di configurazione sul nodo in /tmp/bgpadvertiser.conf che abbia il seguente aspetto:

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

    Sostituisci quanto segue:

    • NODE_IP: indirizzo IP del nodo del piano di controllo in uso.
    • 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 piano di controllo nel comando seguente:

    /tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIP

    Sostituisci CONTROL_PLANE_VIP con l'indirizzo IP che utilizzerai per il VIP del piano di controllo. Questo comando fa sì che l'inserzionista BGP pubblicizzi questo indirizzo nel peer.

  3. Visualizza l'output del programma.

    A questo punto, il daemon bgpadvertiser si avvia, tenta di connettersi al peer e pubblicizza il VIP. Il programma stampa periodicamente i messaggi (vedi l'output di esempio seguente) che 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, ricontrolla i parametri di configurazione BGP nel file di configurazione e verifica con l'amministratore di rete. Ora hai configurato una connessione BGP. Puoi verificare con l'amministratore di rete che vede la connessione stabilita dalla sua parte e che vede 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 che esegue bgpadvertiser. Esegui questo comando in un terminale diverso in modo da poter lasciare il comando bgpadvertiser in esecuzione:

  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: l'argomento VIP --advertise-ip di bgpadvertiser.
    • INTF_NAME: l'interfaccia di Kubernetes nel nodo. Ciò significa che l'interfaccia ha l'indirizzo IP che hai inserito nella configurazione di Anthos clusters on bare metal 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 sia funzionante. Se non reimposti correttamente il nodo, la configurazione manuale potrebbe interferire con il controllo preflight o la creazione successiva del cluster.

  1. Rimuovi il VIP dal nodo del piano di controllo se l'hai aggiunto per il test del traffico:

    ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME

  2. Sul nodo del piano di controllo, premi Ctrl+C nel terminale bgpadvertiser per arrestare l'inserzionista bgp.

  3. Verifica che non siano in esecuzione processi bgpadvertiser:

    ps -ef | grep bgpadvertiser

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