Gebündelte Load-Balancer mit BGP konfigurieren

In diesem Dokument wird beschrieben, wie Sie gebündelte Load Balancer mit Border Gateway Protocol (BGP) für Google Distributed Cloud einrichten und verwenden. Dieser Load-Balancing-Modus unterstützt das Advertising von virtuellen IP-Adressen (VIPs) vom Typ ServiceType LoadBalancer über das externe Border Gateway Protocol (eBGP) für Ihre Cluster. In diesem Szenario ist Ihr Clusternetzwerk ein autonomes System, das über Peering mit einem anderen autonomen System (einem externen Netzwerk) verbunden ist.

Die gebündelten Load-Balancer mit BGP-Funktion gelten für alle Clustertypen. In Administratorclustern wird jedoch nur das Load-Balancing auf Steuerungsebene als Teil dieser Funktion unterstützt.

Die Verwendung der gebündelten Load-Balancer mit BGP-Funktion bietet folgende Vorteile:

• Verwendet die N-Wege-Aktiv/Aktiv-Load-Balancing-Funktion, um einen schnelleren Failover und eine effizientere Auslastung der verfügbaren Bandbreite zu ermöglichen.
• Unterstützt das Layer-3-Protokoll, das mit ToR-Switches (Top-of-Rack) von Drittanbietern und mit Routern arbeitet, die mit eBGP kompatibel sind.
• Rechenzentren, in denen ein erweiterter SDN-Stack (softwarebasierter Netzwerkstack) ausgeführt wird, können die Layer-3-Grenze bis zu den Clustern ausweiten.

So funktioniert das gebündelte Load-Balancing mit BGP

Die folgenden Abschnitte bieten eine kurze Zusammenfassung darüber, wie gebündelte Load-Balancer mit BGP funktionieren.

BGP-Peering

Die gebündelten Load-Balancer mit BGP-Funktionen starten mehrere BGP-Verbindungen zu Ihrer Infrastruktur. BGP hat die folgenden technischen Anforderungen:

• Peering-Sitzungen sind für die VIP der Steuerungsebene und für Dienst-VIPs getrennt.
• Peering-Sitzungen der Steuerungsebene werden von den IP-Adressen der Knoten auf Steuerungsebene initiiert.
• Dienst-Peering-Sitzungen werden über Floating-IP-Adressen initiiert, die Sie in der benutzerdefinierten NetworkGatewayGroup-Ressource angeben.
• Der Network Gateway for GDC-Controller verwaltet die Floating-IP-Adressen.
• Gebündeltes BGP-basiertes Load-Balancing unterstützt nur eBGP-Peering.
• Multi-Hop-Peering wird standardmäßig unterstützt.
• MD5-Passwörter in BGP-Sitzungen werden nicht unterstützt.
• IPv6-basierte Peering-Sitzungen werden nicht unterstützt.
• Von einem Peer weitergeleitete Routen werden voraussichtlich im gesamten Netzwerk neu verteilt und sind über jede beliebige Stelle im Cluster erreichbar.
• Die Verwendung der BGP-ADD-PATH-Funktion im Empfangsmodus wird für Peering-Sitzungen empfohlen.
• Das Advertising mehrerer Pfade von jedem Peer führt zu Aktiv/Aktiv-Load-Balancing.
• ECMP (Equal-Cost Multipath Routing) sollte für Ihr Netzwerk aktiviert sein, damit mehrere Pfade zum Verteilen des Traffics auf eine Gruppe von Load-Balancer-Knoten verwendet werden können.

Load-Balancing auf Steuerungsebene

Jeder Knoten der Steuerungsebene in Ihrem Cluster richtet BGP-Sitzungen mit einem oder mehreren Peers in Ihrer Infrastruktur ein. Jeder Knoten der Steuerungsebene muss mindestens einen Peer haben. In der Clusterkonfigurationsdatei können Sie konfigurieren, welche Knoten der Steuerungsebene mit welchen externen Peers verbunden sind.

Das folgende Diagramm zeigt ein Beispiel für das Peering der Steuerungsebene. Der Cluster hat zwei Knoten auf Steuerungsebene in einem Subnetz und einen weiteren Knoten in einem anderen Subnetz. In jedem Subnetz gibt es einen externen Peer (TOR) und die Knoten der Google Distributed Cloud-Steuerungsebene werden mit ihrem TOR verbunden.

Dienst-Load-Balancing

Zusätzlich zu den Peering-Sitzungen, die von jedem Knoten der Steuerungsebene für das Peering der Steuerungsebene initiiert werden, werden weitere Peering-Sitzungen für LoadBalancer-Dienste initiiert. Diese Peering-Sitzungen werden nicht direkt von IP-Adressen des Clusterknotens initiiert, sondern verwenden stattdessen Floating-IP-Adressen.

Dienste mit der Netzwerkrichtlinie externalTrafficPolicy=Local werden unterstützt. Die externalTrafficPolicy=Local-Einstellung ist jedoch arbeitslastabhängig und führt dazu, dass Routen aktualisiert werden, wenn ein Pod, der den Dienst unterstützt, einem Knoten hinzugefügt oder vollständig daraus entfernt wird. Dieses Verhalten beim Aktualisieren von Routen kann dazu führen, dass sich die Trafficflüsse durch das ECMP-Routing (Equal Cost Multi-Path) ändern, was zu einem Rückgang des Traffics führen kann.

Floating-IP-Adressen

Für das Dienst-Load-Balancing müssen Sie Floating-IP-Adressen in den Clusterknoten-Subnetzen reservieren, die für das BGP-Peering verwendet werden. Für den Cluster ist mindestens eine Floating-IP-Adresse erforderlich. Wir empfehlen jedoch, mindestens zwei Adressen zu reservieren, um eine hohe Verfügbarkeit für BGP-Sitzungen zu ermöglichen. Die Floating-IP-Adressen werden in der benutzerdefinierten Ressource (Custom Resource, CR) NetworkGatewayGroup angegeben, die in der Clusterkonfigurationsdatei enthalten sein kann.

Bei Floating-IP-Adressen müssen Sie sich keine Gedanken über die Zuordnung von BGP-Speaker-IP-Adressen zu Knoten zu machen. Der Network Gateway for GDC-Controller übernimmt die Zuweisung von NetworkGatewayGroup zu Knoten und verwaltet auch die Floating-IP-Adressen. Wenn ein Knoten ausfällt, weist der Network Gateway for GDC-Controller Floating-IP-Adressen neu zu, damit externe Peers eine deterministische IP-Adresse haben, mit der sie verbunden werden können.

Externe Peers

Beim Load-Balancing auf Datenebene können Sie die gleichen externen Peers verwenden, die für das Peering auf Steuerungsebene im Abschnitt loadBalancer.controlPlaneBGP der Clusterkonfigurationsdatei angegeben wurden. Alternativ können Sie andere BGP-Peers angeben.

Wenn Sie andere BGP-Peers für das Peering auf Datenebene angeben möchten, hängen Sie die Ressourcenspezifikationen BGPLoadBalancer und BGPPeer an die Clusterkonfigurationsdatei an. Wenn Sie diese benutzerdefinierten Ressourcen nicht angeben, werden die Peers der Steuerungsebene automatisch für die Datenebene verwendet.

Die externen Peers, die für Peering-Sitzungen verwendet werden, werden mit den Floating-IP-Adressen in der benutzerdefinierten BGPPeer-Ressource festgelegt. Diese fügen Sie der Clusterkonfigurationsdatei hinzu. Die BGPPeer-Ressource enthält ein Label zur Identifizierung durch die entsprechende benutzerdefinierte BGPLoadBalancer-Ressource. Sie geben das entsprechende Label im Feld peerSelector der benutzerdefinierten BGPLoadBalancer-Ressource an, um BGPPeer zur Verwendung auszuwählen.

Der Network Gateway for GDC-Controller versucht, Sitzungen (die Anzahl der Sitzungen konfigurierbar) für jeden externen Peer aus der Reihe von reservierten Floating-IP-Adressen einzurichten. Wir empfehlen, mindestens zwei externe Peers anzugeben, um eine hohe Verfügbarkeit für BGP-Sitzungen zu ermöglichen. Jeder externe Peer, der für das Load Balancing von Diensten festgelegt wurde, muss so konfiguriert sein, dass er mit jeder in der benutzerdefinierten NetworkGatewayGroup-Ressource angegebenen Floating-IP-Adresse verbunden werden kann.

Load-Balancer-Knoten

Eine Teilmenge von Knoten aus dem Cluster wird für das Load-Balancing verwendet. Dies bedeutet, dass es sich um die beworbenen Knoten handelt, die eingehenden Traffic für das Load-Balancing annehmen können. Diese Gruppe von Knoten verwendet standardmäßig den Knotenpool der Steuerungsebene. Sie können jedoch im Abschnitt loadBalancer der Clusterkonfigurationsdatei einen anderen Knotenpool angeben. Wenn Sie einen Knotenpool angeben, wird er für die Load-Balancer-Knoten anstelle des Knotenpools der Steuerungsebene verwendet.

Die Floating-IP-Adressen, die als BGP-Lautsprecher funktionieren, können auf den Load-Balancer-Knoten ausgeführt werden. Die Floating-IP-Adressen werden einem Knoten im selben Subnetz zugewiesen und das Peering wird von dort aus gestartet, unabhängig davon, ob es sich um einen Load-Balancer-Knoten handelt. Die nächsten Hops, die über BGP beworben werden, sind jedoch immer die Load-Balancer-Knoten.

Beispiel für Peering-Topologie

Das folgende Diagramm zeigt ein Beispiel für ein Dienst-Load-Balancing mit BGP-Peering. Den Knoten in ihren jeweiligen Subnetzen werden zwei Floating-IP-Adressen zugewiesen. Es sind zwei externe Peers definiert. Jeder Floating-IP-Peer verbindet sich mit beiden externen Peers.

BGP-Load-Balancer einrichten

In den folgenden Abschnitten wird beschrieben, wie Sie Ihre Cluster und Ihr externes Netzwerk für die Verwendung des gebündelten Load-Balancers mit BGP konfigurieren.

Integration in externe Infrastruktur planen

Damit Sie den gebündelten Load Balancer mit BGP verwenden können, müssen Sie die externe Infrastruktur einrichten:

• Die externe Infrastruktur muss so konfiguriert sein, dass sie mit jedem Knoten der Steuerungsebene im Cluster verbunden ist, um die Kommunikation mit der Steuerungsebene einzurichten. Diese Peering-Sitzungen werden verwendet, um die VIPs der Kubernetes-Steuerungsebene zu bewerben.

• Die externe Infrastruktur muss für das Peering mit einer Reihe reservierter Floating-IP-Adressen für die Kommunikation auf Datenebene konfiguriert werden. Die Floating-IP-Adressen werden für BGP-Peering für die Dienst-VIPs verwendet. Wir empfehlen die Verwendung von zwei Floating-IP-Adressen und zwei Peers, um eine Hochverfügbarkeit für BGP-Sitzungen zu ermöglichen. Der Vorgang zum Reservieren von Floating-IP-Adressen wird im Rahmen der Konfiguration des Clusters für das gebündelte Load Balancing mit BGP beschrieben.

Wenn Sie die Infrastruktur konfiguriert haben, fügen Sie der Clusterkonfigurationsdatei die BGP-Peering-Informationen hinzu. Der von Ihnen erstellte Cluster kann Peering-Sitzungen mit der externen Infrastruktur initiieren.

Cluster für das gebündelte Load-Balancing mit BGP konfigurieren

Sie aktivieren und konfigurieren das gebündelte Load-Balancing mit BGP in der Clusterkonfigurationsdatei, wenn Sie einen Cluster erstellen. In der Clusterkonfigurationsdatei aktivieren Sie erweiterte Netzwerkfunktionen und aktualisieren den Abschnitt loadBalancer. Außerdem fügen Sie Spezifikationen für die folgenden drei benutzerdefinierten Ressourcen hinzu:

• NetworkGatewayGroup: gibt Floating-IP-Adressen an, die für BGP-Peering-Sitzungen für Dienste verwendet werden.

• BGPLoadBalancer: gibt mit Labelauswahlen an, welche Peers für das BGP-Load Balancing verwendet werden.

• BGPPeer: gibt einzelne Peers, einschließlich eines Labels für Auswahlzwecke, für BGP-Peering-Sitzungen an.

In der folgenden Anleitung wird beschrieben, wie Sie Ihren Cluster und die drei benutzerdefinierten Ressourcen zum Einrichten des gebündelten Load-Balancings mit BGP konfigurieren.

1. Fügen Sie das Feld advancedNetworking der Clusterkonfigurationsdatei im Abschnitt clusterNetwork hinzu und setzen Sie es auf true.

   Dieses Feld aktiviert erweiterte Netzwerkfunktionen, insbesondere die Network Gateway Group-Ressource.

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: bm
     namespace: CLUSTER_NAMESPACE
   spec:
   ...
     clusterNetwork:
       advancedNetworking: true
   

   Ersetzen Sie CLUSTER_NAMESPACE durch den Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für Google Distributed Cloud der Name des Clusters, dem cluster- vorangestellt ist. Wenn Sie Ihren Cluster beispielsweise test nennen, lautet der Namespace cluster-test.

2. Legen Sie mode im Abschnitt loadBalancer der Cluster-Konfigurationsdatei auf bundled fest und fügen Sie das Feld type mit dem Wert bgp hinzu.

   Diese Feldwerte ermöglichen das BGP-basierte gebündelte Load-Balancing.

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

3. Fügen Sie dem Abschnitt loadBalancer die folgenden Felder hinzu, um die BGP-Peering-Informationen für die Steuerungsebene anzugeben:

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

   Ersetzen Sie Folgendes:

   • CLUSTER_ASN: die Nummer des autonomen Systems für den zu erstellenden Cluster.
   • PEER_IP: die IP-Adresse des externen Peer-Geräts.
   • PEER_ASN: die autonome Systemnummer für das Netzwerk, das das externe Peer-Gerät enthält.
   • CP_NODE_IP (optional): die IP-Adresse des Knotens auf der Steuerungsebene, der eine Verbindung zum externen Peer herstellt. Wenn Sie keine Knoten auf Steuerungsebene angeben, können alle Knoten auf Steuerungsebene eine Verbindung zum externen Peer herstellen. Wenn Sie eine oder mehrere IP-Adressen angeben, nehmen nur die angegebenen Knoten an Peering-Sitzungen teil.

   Sie können mehrere externe Peers angeben. bgpPeers verwendet eine Liste von Zuordnungen. Es wird empfohlen, mindestens zwei externe Peers für die Hochverfügbarkeit für BGP-Sitzungen anzugeben. Ein Beispiel mit mehreren Peers finden Sie unter Beispielkonfigurationen.

4. Legen Sie die Felder loadBalancer.ports, loadBalancer.vips und loadBalancer.addressPools fest (Standardwerte werden angezeigt).

   ...
     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. Geben Sie den Clusterknoten an, der für das Load-Balancing der Datenebene verwendet werden soll.

   Dieser Schritt ist optional. Wenn Sie die Kommentarzeichen für den Abschnitt nodePoolSpec entfernen, werden die Knoten der Steuerungsebene für das Load-Balancing der Datenebene verwendet.

   ...
     # 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. Reservieren Sie Floating-IP-Adressen, indem Sie die benutzerdefinierte NetworkGatewayGroup-Ressource konfigurieren:

   Die Floating-IP-Adressen werden in Peering-Sitzungen für das Load-Balancing auf Datenebene verwendet.

   ...
   ---
   apiVersion: networking.gke.io/v1
   kind: NetworkGatewayGroup
   metadata:
     name: default
     namespace: CLUSTER_NAMESPACE
   spec:
     floatingIPs:
     - FLOATING_IP
     nodeSelector:    # optional
     - NODE_SELECTOR
   ...
   

   Ersetzen Sie Folgendes:

   • CLUSTER_NAMESPACE: der Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für Google Distributed Cloud der Name des Clusters, dem cluster- vorangestellt ist. Wenn Sie Ihren Cluster beispielsweise test nennen, lautet der Namespace cluster-test.
   • FLOATING_IP: eine IP-Adresse aus einem der Subnetze des Clusters. Sie müssen mindestens eine IP-Adresse angeben. Wir empfehlen jedoch, mindestens zwei IP-Adressen anzugeben.
   • NODE_SELECTOR: (Optional) Labelauswahl, um Knoten für die Instanziierung von Peering-Sitzungen mit externen Peers zu identifizieren, z. B. ToR-Switches (Top-of-Rack). Entfernen Sie dieses Feld, wenn es nicht benötigt wird.

   Achten Sie darauf, dass die benutzerdefinierte NetworkGatewayGroup-Ressource den Namen default hat und den Cluster-Namespace verwendet. Ein Beispiel dafür, wie die Spezifikation der benutzerdefinierten NetworkGatewayGroup-Ressource aussehen könnte, finden Sie unter Beispielkonfigurationen.

7. (Optional) Geben Sie die Peers an, die für das Load Balancing auf Datenebene verwendet werden sollen. Konfigurieren Sie dazu die benutzerdefinierte BGPLoadBalancer-Ressource:

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

   Ersetzen Sie Folgendes:

   • CLUSTER_NAMESPACE: der Namespace des Clusters. Standardmäßig sind die Cluster-Namespaces für Google Distributed Cloud der Name des Clusters, dem cluster- vorangestellt ist. Wenn Sie Ihren Cluster beispielsweise test nennen, lautet der Namespace cluster-test.
   • PEER_LABEL: das Label, mit dem angegeben wird, welche Peers für das Load-Balancing verwendet werden sollen. Jede benutzerdefinierte BGPPeer-Ressource mit einem entsprechenden Label gibt die Details jedes Peers an.

   Achten Sie darauf, dass die benutzerdefinierte BGPLoadBalancer-Ressource den Namen default hat und den Cluster-Namespace verwendet. Wenn Sie keine benutzerdefinierte BGPLoadBalancer-Ressource angeben, werden die Peers der Steuerungsebene automatisch für das Load-Balancing auf Datenebene verwendet. Umfassende Beispiele finden Sie unter Beispielkonfigurationen.

8. (Optional) Geben Sie die externen Peers für die Datenebene an, indem Sie eine oder mehrere benutzerdefinierte BGPPeer-Ressourcen konfigurieren:

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

   Dabei gilt:

   • BGP_PEER_NAME: der Name des Peers.
   • CLUSTER_NAMESPACE: der Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für Google Distributed Cloud der Name des Clusters, dem cluster- vorangestellt ist. Wenn Sie Ihren Cluster beispielsweise test nennen, lautet der Namespace cluster-test.
   • PEER_LABEL: das Label, mit dem angegeben wird, welche Peers für das Load-Balancing verwendet werden sollen. Dieses Label sollte dem Label entsprechen, das in der benutzerdefinierten BGPLoadBalancer-Ressource angegeben ist.
   • CLUSTER_ASN: die Nummer des autonomen Systems für den zu erstellenden Cluster.
   • PEER_IP: die IP-Adresse des externen Peer-Geräts. Wir empfehlen, mindestens zwei externe Peers anzugeben, aber mindestens einer ist erforderlich.
   • PEER_ASN: die autonome Systemnummer für das Netzwerk, das das externe Peer-Gerät enthält.
   • SESSION_QTY: die Anzahl der Sitzungen, die für diesen Peer eingerichtet werden sollen. Wir empfehlen, mindestens zwei Sitzungen einzurichten, damit Sie eine Verbindung zum Peer aufrechterhalten können, falls einer Ihrer Knoten ausfällt.
   • GATEWAY_REF: (Optional) Der Name einer NetworkGatewayGroup-Ressource, die für das Peering verwendet werden soll. Wenn Sie diese Option nicht festlegen, können alle oder einige Gateway-Ressourcen verwendet werden. Verwenden Sie diese Einstellung in Verbindung mit dem Feld nodeSelector in der Ressource „NetworkGatewayGroups“, um auszuwählen, welche Knoten für das Peering mit einem bestimmten externen Peer verwendet werden sollen, z. B. einem ToR-Switch. Es können mehrere Einträge erforderlich sein, um mehrere NetworkGatewayGroups auszuwählen, wenn gewünscht, im Format „ein Gateway pro Zeile“.

   Sie können mehrere externe Peers angeben, indem Sie zusätzliche benutzerdefinierte BGPPeer-Ressourcen erstellen. Wir empfehlen, mindestens zwei externe Peers (zwei benutzerdefinierte Ressourcen) anzugeben, um Hochverfügbarkeit für BGP-Sitzungen zu ermöglichen. Wenn Sie keine benutzerdefinierte BGPPeer-Ressource angeben, werden die Peers der Steuerungsebene automatisch für das Load-Balancing auf Datenebene verwendet.

9. Wenn Sie bmctl cluster create zum Erstellen des Clusters ausführen, werden Preflight-Prüfungen ausgeführt. Unter anderem prüfen die Preflight-Prüfungen die BGP-Peering-Konfiguration für die Steuerungsebene und melden Probleme direkt an die Administrator-Workstation, bevor der Cluster erstellt werden kann.

   Bei Erfolg werden die hinzugefügten BGP-Load Balancing-Ressourcen (NetworkGatewayGroup, BGPLoadBalancer und BGPPeer) in den Administratorcluster im Nutzercluster-Namespace verschoben. Verwenden Sie die kubeconfig-Datei des Administratorclusters, wenn Sie diese Ressourcen später aktualisieren. Der Administratorcluster gleicht dann die Änderungen mit dem Nutzercluster ab. Wenn Sie diese Ressourcen auf dem Nutzercluster direkt bearbeiten, überschreibt der Administratorcluster Ihre Änderungen bei späteren Abgleichungen.

Mehrere nächste Hops pro Sitzung mit BGP ADD-PATH bewerben

Es wird empfohlen, die BGP-Funktion ADD-PATH für Peering-Sitzungen zu verwenden, wie in RFC 7911 angegeben. Standardmäßig kann das BGP-Protokoll nur einen einzigen nächsten Hop für Peers für ein einzelnes Präfix bewerben. Mit BGP-ADD-PATH können Sie mehrere nächste Hops für dasselbe Präfix bewerben. Wenn ADD-PATH mit BGP-basiertem gebündeltem Load-Balancing verwendet wird, kann der Cluster mehrere Clusterknoten als Frontend-Knoten (nächste Hops) für einen Load-Balancer-Dienst (Präfix) bewerben. Aktivieren Sie ECMP im Netzwerk, damit der Traffic über mehrere Pfade verteilt werden kann. Durch die Möglichkeit, Traffic durch Advertising mehrerer Clusterknoten als nächste Hops aufzufächern, wird die Kapazität der Datenebene für das Load-Balancing verbessert.

Wenn Ihr externes Peer-Gerät, z. B. ein ToR-Switch (Top-of-Rack), oder ein Router BGP ADD-PATH unterstützt, reicht es aus, nur die Empfangserweiterung zu aktivieren. Gebündeltes Load-Balancing mit BGP funktioniert ohne die Funktion ADD-PATH. Die Einschränkung des Advertising eines einzelnen Load-Balancing-Knotens pro Peering-Sitzung begrenzt die Kapazität der Load-Balancer-Datenebene. Ohne ADD-PATH wählt Google Distributed Cloud Knoten aus, um sie aus dem Knotenpool des Load Balancers zu bewerben, und versucht, die nächsten Hops für verschiedene VIPs auf verschiedene Knoten zu verteilen.

BGP-Peering auf Load-Balancer-Knoten beschränken

Google Distributed Cloud weist automatisch Floating-IP-Adressen auf jedem Knoten im selben Subnetz wie die Floating-IP-Adresse zu. BGP-Sitzungen werden von diesen IP-Adressen initiiert, auch wenn sie nicht auf den Load-Balancer-Knoten landen. Dieses Verhalten ist bewusst so konzipiert, da die Steuerungsebene (BGP) von der Datenebene (LB-Knotenpools) entkoppelt wurde.

Wenn Sie die Gruppe von Knoten einschränken möchten, die für BGP-Peering verwendet werden können, können Sie ein Subnetz so festlegen, dass es nur für Load-Balancer-Knoten verwendet werden soll. Das heißt, Sie können alle Knoten in diesem Subnetz so konfigurieren, dass sie sich im Knotenpool des Load-Balancers befinden. Wenn Sie dann Floating-IP-Adressen konfigurieren, die für BGP-Peering verwendet werden, achten Sie darauf, dass sie aus demselben Subnetz stammen. Google Distributed Cloud sorgt dafür, dass die Floating-IP-Adresszuweisungen und das BGP-Peering nur von Load Balancer-Knoten ausgeführt werden.

BGP-Load Balancing mit Dual-Stack-Netzwerk einrichten

Ab Google Distributed Cloud-Release 1.14.0 unterstützt der BGP-basierte gebündelte Load Balancer IPv6. Mit der Einführung der IPv6-Unterstützung können Sie IPv6- und Dual-Stack-LoadBalancer-Dienste in einem Cluster konfigurieren, der für Dual-Stack-Netzwerke konfiguriert ist. In diesem Abschnitt werden die Änderungen beschrieben, die zum Konfigurieren des gebündelten Dual-Stack-Load Balancings mit BGP erforderlich sind.

Um Dual-Stack-LoadBalancer-Dienste zu aktivieren, sind die folgenden Konfigurationsänderungen erforderlich:

• Der zugrunde liegende Cluster muss für Dual-Stack-Netzwerke konfiguriert sein:

  • Geben Sie in der Clusterkonfigurationsdatei unter spec.clusterNetwork.services.cidrBlocks sowohl IPv4- als auch IPv6-Dienst-CIDRs an.

  • Definieren Sie geeignete ClusterCIDRConfig-Ressourcen, um IPv4- und IPv6-CIDR-Bereiche für Pods anzugeben.

  Weitere Informationen zum Konfigurieren eines Clusters für Dual-Stack-Netzwerke finden Sie unter IPv4/IPv6-Dual-Stack-Netzwerke.

• Geben Sie in der Clusterkonfigurationsdatei unter spec.loadBalancer.addressPools einen IPv6-Adresspool an. Damit MetalLB einem Dual-Stack-Dienst IP-Adressen zuweisen kann, muss es mindestens einen Adresspool mit Adressen im IPv4- und IPv6-Format geben.

In der folgenden Beispielkonfiguration sind die Änderungen für das gebündelte Dual-Stack-Load Balancing mit BGP zu sehen:

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

Einschränkungen für Dual-Stack-gebündeltes Load Balancing mit BGP

Beachten Sie bei der Konfiguration Ihres Clusters für das gebündelte Load Balancing mit BGP und Dual-Stack die folgenden Einschränkungen:

• Das Load Balancing der IPv6-Steuerungsebene wird nicht unterstützt.

• IPv6-BGP-Sitzungen werden nicht unterstützt, aber IPv6-Routen können über IPv4-Sitzungen mit Multiprotokoll-BGP beworben werden.

Beispielkonfigurationen

In den folgenden Abschnitten wird gezeigt, wie Sie BGP-basiertes Load-Balancing für verschiedene Optionen oder Verhaltensweisen konfigurieren.

Alle Knoten müssen dieselben Peers verwenden

Wie im folgenden Diagramm dargestellt, führt diese Konfiguration zu einer Gruppe externer Peers (10.8.0.10 und 10.8.0.11), die von allen Knoten erreichbar sind. Die Peers werden von allen Knoten der Steuerungsebene (10.0.1.10, 10.0.1.11 und 10.0.2.10) und Floating-IP-Adressen (10.0.1.100 und 10.0.2.100) erreicht, die Knoten der Datenebene zugewiesen sind.

Dieselben externen Peers sind über eine der Floating-IP-Adressen (10.0.1.100 oder 10.0.2.100) erreichbar, die für das loadBalancer-Dienst-Peering reserviert sind. Die Floating-IP-Adressen können Knoten zugewiesen werden, die sich im selben Subnetz befinden.

Wie im folgenden Beispiel für die Clusterkonfiguration gezeigt, konfigurieren Sie die Peers für die Knoten der Steuerungsebene (bgpPeers), ohne controlPlaneNodes anzugeben. Wenn keine Knoten für Peers angegeben sind, werden alle Knoten der Steuerungsebene mit allen Peers verbunden.

Die Floating-IP-Adressen zur Verwendung für Load-Balancing-Peering-Sitzungen für Dienste legen Sie in der benutzerdefinierten NetworkGatewayGroup-Ressource fest. Da in diesem Beispiel kein BGPLoadBalancer angegeben ist, werden die Peers der Steuerungsebene automatisch für die BGP-Sitzungen der Datenebene verwendet.

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

Bestimmte Knoten der Steuerungsebene für das Peering mit bestimmten externen Peers konfigurieren

Wie im folgenden Diagramm dargestellt, führt diese Konfiguration zu einem Peering mit zwei Knoten der Steuerungsebene (10.0.1.10 und 10.0.1.11) mit einem externen Peer (10.0.1.254). Der dritte Knoten der Steuerungsebene (10.0.2.10) ist Peering mit einem weiteren externen Peer (10.0.2.254). Diese Konfiguration ist nützlich, wenn Sie alle Knoten mit allen Peers verbinden möchten. Angenommen, Sie möchten Knoten der Steuerungsebene nur über eine Peering-Verbindung mit den entsprechenden ToR-Switches (Top-of-Rack) steuern.

Dieselben externen Peers sind über eine der Floating-IP-Adressen (10.0.1.100 oder 10.0.2.100) erreichbar, die für Peering-Sitzungen mit Dienst-Load-Balancing reserviert sind. Die Floating-IP-Adressen können Knoten zugewiesen werden, die sich im selben Subnetz befinden.

Wie im folgenden Beispiel für die Clusterkonfiguration gezeigt, beschränken Sie, welche Knoten der Steuerungsebene eine Verbindung zu einem bestimmten Peer herstellen kann. Geben Sie dazu im Abschnitt bgpPeers im Feld controlPlaneNodes die IP-Adressen an.

Die Floating-IP-Adressen zur Verwendung für Load-Balancing-Peering-Sitzungen für Dienste legen Sie in der benutzerdefinierten NetworkGatewayGroup-Ressource fest. Da in diesem Beispiel kein BGPLoadBalancer angegeben ist, werden die Peers der Steuerungsebene automatisch für die BGP-Sitzungen der Datenebene verwendet.

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

Steuerungsebene und Datenebene separat konfigurieren

Wie im folgenden Diagramm dargestellt, führt diese Konfiguration zu einem Peering mit zwei Knoten der Steuerungsebene (10.0.1.10 und 10.0.1.11) mit einem externen Peer (10.0.1.254) und einem Peering des dritten Knotens der Steuerungsebene (10.0.2.11) mit einem weiteren externen Peer (10.0.2.254).

Ein dritter externer Peer (10.0.3.254) ist über eine der Floating-IP-Adressen (10.0.3.100 oder 10.0.3.101) erreichbar, die für Peering-Sitzungen mit Dienst-Load-Balancing reserviert ist. Die Floating-IP-Adressen können Knoten zugewiesen werden, die sich im selben Subnetz befinden.

Wie im folgenden Beispiel für die Clusterkonfiguration gezeigt, beschränken Sie, welche Knoten der Steuerungsebene eine Verbindung zu einem bestimmten Peer herstellen kann. Geben Sie dazu im Abschnitt bgpPeers im Feld controlPlaneNodes die IP-Adressen an.

Die Floating-IP-Adressen zur Verwendung für Load-Balancing-Peering-Sitzungen für Dienste legen Sie in der benutzerdefinierten NetworkGatewayGroup-Ressource fest.

So konfigurieren Sie das Load-Balancing auf Datenebene:

• Geben Sie den externen Peer für die Datenebene in der BGPPeer-Ressource an und fügen Sie ein Label hinzu, das für die Peer-Auswahl verwendet werden soll, z. B. cluster.baremetal.gke.io/default-peer: "true".

• Geben Sie das entsprechende Label für das Feld peerSelector in der BGPLoadBalancer-Ressource an.

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

BGP-basierte Load-Balancing-Konfiguration ändern

Nachdem Sie den Cluster für die Verwendung des gebündelten Load-Balancing mit BGP erstellt haben, können einige Konfigurationseinstellungen aktualisiert werden. Einige können jedoch nach dem Erstellen des Clusters nicht mehr aktualisiert werden.

Verwenden Sie die kubeconfig-Datei des Administratorclusters, wenn Sie die BGP-bezogenen Ressourcen (NetworkGatewayGroup, BGPLoadBalancer und BGPPeer) aktualisieren. Der Administratorcluster gleicht dann die Änderungen mit dem Nutzercluster ab. Wenn Sie diese Ressourcen auf dem Nutzercluster direkt bearbeiten, überschreibt der Administratorcluster Ihre Änderungen bei späteren Abgleichungen.

Steuerungsebene

Informationen zum BGP-Peering der Steuerungsebene können in der Cluster-Ressource aktualisiert werden. Sie können Peers hinzufügen oder entfernen, die im Abschnitt zum Load-Balancing auf Steuerungsebene angegeben sind.

In den folgenden Abschnitten werden die Best Practices für das Aktualisieren der BGP-Peering-Informationen auf Steuerungsebene beschrieben.

Peer-Status vor dem Aktualisieren prüfen

Um das Risiko einer Fehlkonfiguration von Peers zu minimieren, prüfen Sie, ob sich die BGP-Peering-Sitzungen der Steuerungsebene im erwarteten Zustand befinden, bevor Sie Änderungen vornehmen. Wenn Sie beispielsweise davon ausgehen, dass alle BGP-Peering-Sitzungen derzeit aktiv sind, prüfen Sie, ob alle bgp-advertiser-Pods ready melden, was bedeutet, dass die Sitzungen aktiv sind. Wenn der aktuelle Status nicht Ihren Erwartungen entspricht, beheben Sie das Problem, bevor Sie eine Peer-Konfiguration aktualisieren.

Informationen zum Abrufen von BGP-Sitzungsdetails auf Steuerungsebene finden Sie unter BGP-Sitzungen der Steuerungsebene.

Peers kontrolliert aktualisieren

Aktualisieren Sie nach Möglichkeit nur einen Peer auf einmal, um mögliche Probleme zu isolieren:

1. Fügen Sie einen einzelnen Peer hinzu oder aktualisieren Sie einen.
2. Warten Sie, bis die Konfiguration abgeglichen wurde.
3. Prüfen Sie, ob der Cluster eine Verbindung zum neuen oder aktualisierten Peer herstellen kann.
4. Entfernen Sie die alten oder nicht benötigten Peers.

Dienste

Bearbeiten Sie nodePoolSpec in der Cluster-Ressource, um Adresspools und Load-Balancer-Knoteneinstellungen zu aktualisieren.

Bearbeiten Sie die benutzerdefinierten NetworkGatewayGroup- und BGPLoadBalancer-Ressourcen, um die BGP-Peering-Konfiguration zu ändern, nachdem Ihr Cluster erstellt wurde. Alle Änderungen an den Peering-Informationen in diesen benutzerdefinierten Ressourcen werden in der Konfiguration der Load-Balancing-Lösung im Zielcluster widergespiegelt.

Nehmen Sie nur Aktualisierungen in den Quellressourcen im Cluster-Namespace im Administratorcluster vor. Alle Änderungen, die an den Ressourcen im Zielcluster (Nutzercluster) vorgenommen wurden, werden überschrieben.

Fehlerbehebung

In den folgenden Abschnitten wird beschrieben, wie Sie auf Informationen zur Fehlerbehebung für das gebündelte Load-Balancing mit BGP zugreifen.

BGP-Sitzungen der Steuerungsebene

Die BGP-Peering-Konfiguration auf Steuerungsebene wird während der Clustererstellung mit Preflight-Prüfungen validiert. Die Preflight-Prüfungen versuchen Folgendes:

• Mit jedem Peer eine BGP-Verbindung herstellen.
• Die VIP der Steuerungsebene bewerben.
• Prüfen, ob der Knoten der Steuerungsebene über die VIP erreichbar ist.

Wenn die Clustererstellung bei Preflight-Prüfungen fehlschlägt, prüfen Sie die Preflight-Prüflogs auf Fehler. Die getesteten Preflight-Prüflogdateien befinden sich im Verzeichnis baremetal/bmctl-workspace/CLUSTER_NAME/log.

Zur Laufzeit werden die BGP-Speaker der Steuerungsebene als statische Pods auf jedem Knoten der Steuerungsebene ausgeführt und Ereignisinformationen in Logs geschrieben. Diese statischen Pods enthalten "bgpadvertiser" im Namen. Verwenden Sie daher den folgenden kubectl get pods-Befehl, um den Status der BGP-Speaker-Pods aufzurufen:

kubectl -n kube-system get pods | grep bgpadvertiser

Wenn die Pods ordnungsgemäß funktionieren, sieht die Antwort in etwa so aus:

bgpadvertiser-node-01                            1/1     Running   1          167m
bgpadvertiser-node-02                            1/1     Running   1          165m
bgpadvertiser-node-03                            1/1     Running   1          163m

Verwenden Sie den folgenden Befehl, um die Logs für den Pod bgpadvertiser-node-01 aufzurufen:

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

BGP-Sitzungen für Dienste

Die BGPSession-Ressource enthält Informationen zu den aktuellen BGP-Sitzungen. Zum Abrufen von Sitzungsinformationen rufen Sie zuerst die aktuellen Sitzungen und dann die BGPSession-Ressource für eine der Sitzungen ab.

Verwenden Sie den folgenden kubectl get-Befehl, um die aktuellen Sitzungen aufzulisten:

kubectl -n kube-system get bgpsessions

Der Befehl gibt eine Liste der Sitzungen wie im folgenden Beispiel zurück:

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

Rufen Sie mit dem folgenden kubectl describe-Befehl die BGPSession-Ressource für die BGP-Sitzung 10.0.1.254-node-01 ab:

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

Die zurückgegebene BGPSession-Ressource sollte in etwa so aussehen:

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

Verwenden Sie den Befehl kubectl get, um die Ressourcen BGPAdvertisedRoute abzurufen:

kubectl -n kube-system get bgpadvertisedroutes

Die Antwort, die in etwa wie das folgende Beispiel aussehen sollte, enthält die aktuell beworbenen Routen:

NAME                                    PREFIX           METRIC
default-default-load-balancer-example   10.1.1.34/32
default-gke-system-istio-ingress        10.1.1.107/32

Mit kubectl describe können Sie Details zu den nächsten Hops abrufen, die jede Route bewirbt.

Zugriff auf die VIP der Steuerungsebene für selbstverwaltete Cluster wiederherstellen

Wenn Sie wieder Zugriff auf die VIP der Steuerungsebene in einem Administrator-, Hybrid- oder eigenständigen Cluster erhalten möchten, müssen Sie die BGP-Konfiguration im Cluster aktualisieren. Wie im folgenden Befehlsbeispiel gezeigt, stellen Sie über SSH eine Verbindung zum Knoten her und öffnen Sie dann mit kubectl die Clusterressource zum Bearbeiten.

ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP

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

Ersetzen Sie Folgendes:

• IDENTITY_FILE: der Name der SSH-Identitätsdatei, die den Identitätsschlüssel für die Authentifizierung mit einem öffentlichen Schlüssel enthält.
• CLUSTER_NODE_IP: die IP-Adresse für den Clusterknoten.
• CLUSTER_NAMESPACE: den Namespace des Clusters.
• CLUSTER_NAME ist der Name des Clusters.

Ändern Sie die BGP-Peering-Konfiguration im Clusterobjekt. Beobachten Sie nach dem Speichern der neuen Clusterkonfiguration den Status der bgpadvertiser-Pods. Wenn die Konfiguration funktioniert, werden die Pods neu gestartet und werden fehlerfrei, sobald sie eine Verbindung zu ihren Peers herstellen.

Manuelle BGP-Überprüfung

Dieser Abschnitt enthält Anleitungen zum manuellen Prüfen Ihrer BGP-Konfiguration. Mit dem Verfahren wird eine lang andauernde BGP-Verbindung eingerichtet, damit Sie die BGP-Konfiguration mit Ihrem Netzwerkteam weiter debuggen können. Mit diesem Verfahren können Sie Ihre Konfiguration prüfen, bevor Sie einen Cluster erstellen, oder wenn der Vorgang mit BGP-bezogenen Preflight-Prüfungen fehlschlägt.

Preflight-Prüfungen automatisieren die folgenden BGP-Überprüfungsaufgaben:

• Richten Sie eine BGP-Verbindung zu einem Peer ein.
• Die VIP der Steuerungsebene bewerben.
• Prüfen Sie, ob der Traffic, der von allen anderen Clusterknoten an die VIP gesendet wird, den aktuellen Load-Balancer-Knoten erreicht.

Diese Aufgaben werden für jeden BGP-Peer auf jedem Knoten der Steuerungsebene ausgeführt. Das Übergeben dieser Prüfungen ist beim Erstellen eines Clusters wichtig. Die Preflight-Prüfungen erstellen jedoch keine lang andauernden Verbindungen, sodass die Behebung eines Fehlers schwierig ist.

In den folgenden Abschnitten finden Sie eine Anleitung zum Einrichten einer BGP-Verbindung und zum Bewerben einer Route von einem einzelnen Clustercomputer zu einem Peer. Wiederholen Sie die Anweisungen mit einer anderen Kombination aus Maschine und Peer, um mehrere Maschinen und mehrere Peers zu testen.

Denken Sie daran, dass die BGP-Verbindungen von den Knoten der Steuerungsebene hergestellt werden. Testen Sie dieses Verfahren daher von einem Ihrer geplanten Steuerungsebenenknoten.

Binärdatei des BGP-Testprogramms abrufen

Führen Sie die Schritte in diesem Abschnitt auf Ihrer neuen Administrator-Workstation aus. Mit diesen Schritten wird das Programm bgpadvertiser abgerufen, mit dem BGP-Verbindungen getestet werden. Außerdem wird es in die Steuerungsebenenknoten kopiert, auf denen Sie Tests durchführen möchten.

1. Rufen Sie das Docker-Image des Ansible-Runners ab:

   Ohne Registry-Spiegelung

   Wenn Sie keinen Registry-Spiegelung verwenden, führen Sie die folgenden Befehle aus, um das Docker-Runner-Docker-Image abzurufen:

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

   Mit Registry-Spiegelung

   Wenn Sie eine Registry-Spiegelung verwenden, führen Sie die folgenden Befehle aus, um das Docker-Runner-Docker-Image abzurufen:

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

   Ersetzen Sie REGISTRY_HOST durch den Namen des Registry-Spiegelungsservers.

2. So extrahieren Sie die Binärdatei bgpadvertiser.

   Ohne Registry-Spiegelung

   Führen Sie den folgenden Befehl aus, um die Binärdatei bgpadvertiser zu extrahieren:

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

   Mit Registry-Spiegelung

   Führen Sie den folgenden Befehl aus, um die Binärdatei bgpadvertiser zu extrahieren:

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

3. Führen Sie den folgenden Befehl aus, um die Binärdatei bgpadvertiser auf den Knoten der Steuerungsebene zu kopieren, mit dem Sie testen möchten:

   scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/
   

   Dabei gilt:

   • USERNAME: Nutzername, den Sie für den Zugriff auf den Knoten der Steuerungsebene verwenden.

   • CP_NODE_IP: die IP-Adresse des Knotens der Steuerungsebene.

BGP-Verbindung einrichten

Führen Sie die Schritte in diesem Abschnitt auf einem Knoten der Steuerungsebene aus.

1. Erstellen Sie auf dem Knoten unter /tmp/bgpadvertiser.conf eine Konfigurationsdatei, die so aussieht:

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

   Dabei gilt:

   • NODE_IP: IP-Adresse des Knotens der Steuerungsebene, auf dem Sie sich befinden.
   • CLUSTER_ASN: die vom Cluster verwendete autonome Systemnummer.
   • PEER_IP: die IP-Adresse eines der externen Peers, die Sie testen möchten.
   • PEER_ASN: die autonome Systemnummer für das Netzwerk, das das externe Peer-Gerät enthält.

2. Führen Sie den Daemon bgpadvertiser aus und ersetzen Sie im folgenden Befehl die VIP der Steuerungsebene:

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

   Ersetzen Sie CONTROL_PLANE_VIP durch die IP-Adresse, die Sie für die VIP Ihrer Steuerungsebene verwenden möchten. Dieser Befehl bewirkt, dass der BGP-Werbetreibenden diese Adresse dem Peer anbietet.

3. Sehen Sie sich die Programmausgabe an.

   An diesem Punkt startet der Daemon bgpadvertiser, versucht, eine Verbindung zum Peer herzustellen, und bewirbt die VIP. Das Programm gibt regelmäßig Nachrichten aus (siehe folgende Beispielausgabe), die BGP_FSM_ESTABLISHED enthalten, wenn die BGP-Verbindung hergestellt wird.

   {"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}"
   

Wenn diese Meldungen nicht angezeigt werden, prüfen Sie die BGP-Konfigurationsparameter in der Konfigurationsdatei und überprüfen Sie dies mit dem Netzwerkadministrator. Jetzt ist eine BGP-Verbindung eingerichtet. Sie können beim Netzwerkadministrator prüfen, ob die Verbindung auf seiner Seite hergestellt wurde und ob die Route beworben wird.

Traffictest

Testen Sie, ob das Netzwerk Traffic an die VIP weiterleiten kann. Dazu fügen Sie die VIP Ihrem Knoten für die Steuerungsebene hinzu, auf dem bgpadvertiser ausgeführt wird. Führen Sie den folgenden Befehl in einem anderen Terminal aus, damit bgpadvertiser ausgeführt werden kann:

1. Fügen Sie die VIP Ihrem Knoten für die Steuerungsebene hinzu:

   ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME
   

   Ersetzen Sie Folgendes:

   • CONTROL_PLANE_VIP: das VIP---advertise-ip-Argument von bgpadvertiser.
   • INTF_NAME: die Kubernetes-Schnittstelle auf dem Knoten. Das heißt, die Schnittstelle mit der IP-Adresse, die Sie in der Google Distributed Cloud-Konfiguration für loadBalancer.bgpPeers.controlPlaneNodes einfügen.

2. Pingen Sie die VIP von einem anderen Knoten aus:

   ping CONTROL_PLANE_VIP
   

   Wenn der Ping-Befehl nicht erfolgreich ist, liegt möglicherweise ein Problem mit der BGP-Konfiguration auf dem Netzwerkgerät vor. Wenden Sie sich an Ihren Netzwerkadministrator, um die Konfiguration zu prüfen und das Problem zu beheben.

Bereinigen

Führen Sie die folgenden Schritte aus, um den Knoten zurückzusetzen, nachdem Sie manuell überprüft haben, ob BGP funktioniert. Wenn Sie den Knoten nicht ordnungsgemäß zurücksetzen, kann die manuelle Einrichtung die Preflight-Prüfung oder die nachfolgende Clustererstellung beeinträchtigen.

1. Entfernen Sie die VIP vom Knoten der Steuerungsebene, wenn Sie sie für den Traffictest hinzugefügt haben:

   ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME
   

2. Drücken Sie im Knoten der Steuerungsebene Ctrl + C im Terminal bgpadvertiser, um den BGB-Werbetreibenden zu beenden.

3. Prüfen Sie, ob keine bgpadvertiser-Prozesse ausgeführt werden:

   ps -ef | grep bgpadvertiser
   

4. Wenn Prozesse ausgeführt werden, beenden Sie diese mit dem Befehl kill.