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 GKE on Bare Metal 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. Administratorcluster unterstützen jedoch nur den Load-Balancing-Teil dieser Funktion der Steuerungsebene.

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 Top-of-Rack-Switches und -Routern von Drittanbietern (Top-of-Rack-Switches und -Router) von Drittanbietern betrieben wird, 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 Anthos Network Gateway-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.
  • Für Peering-Sitzungen wird die Verwendung der BGP-Funktion ADD-PATH im Empfangsmodus 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 GKE on Bare Metal-Steuerungsebene verbinden mit ihrem TOR.

Dienst-Load-Balancing mit BGP-Peering

Dienst-Load-Balancing

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

Dienste mit der Netzwerkrichtlinie externalTrafficPolicy=Local werden nicht unterstützt.

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 gewährleisten. 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 IP-Adressen zu BGP-Lautsprechern zu Knoten machen. Der Anthos Network Gateway-Controller weist den Knoten die NetworkGatewayGroup zu und verwaltet auch die Floating-IP-Adressen. Wenn ein Knoten ausfällt, weist der Anthos Network Gateway-Controller Floating-IP-Adressen neu zu, um sicherzustellen, dass externe Peers eine deterministische IP-Adresse für das Peering haben.

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

Dienst-Load-Balancing mit BGP-Peering

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 das BGP-Peering für die Dienst-VIPs verwendet. Wir empfehlen die Verwendung von zwei Floating-IP-Adressen und zwei Peers, um eine hohe Verfügbarkeit für BGP-Sitzungen zu gewährleisten. Das Reservieren von Floating-IP-Adressen wird im Abschnitt Cluster für gebündeltes Load-Balancing mit BGP konfigurieren beschrieben.

Nachdem 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 Labelselektoren 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 GKE on Bare Metal 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: 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. Wir empfehlen, mindestens zwei externe Peers für 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
...

    Ersetzen Sie Folgendes:

    • CLUSTER_NAMESPACE: Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für GKE on Bare Metal 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.

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

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

    ...
---
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 GKE on Bare Metal 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
  ...

    Ersetzen Sie Folgendes:

    • BGP_PEER_NAME: der Name des Peers.
    • CLUSTER_NAMESPACE: Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für GKE on Bare Metal 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: 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.

    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 Namespace des Nutzerclusters geleitet. Verwenden Sie die kubeconfig-Datei des Administratorclusters, wenn Sie nachfolgende Aktualisierungen dieser Ressourcen vornehmen. Der Administratorcluster gleicht dann die Änderungen mit dem Nutzercluster ab. Wenn Sie diese Ressourcen direkt im Nutzercluster bearbeiten, überschreibt der Administratorcluster Ihre Änderungen in nachfolgenden Abgleichen.

Wir empfehlen die Verwendung der BGP-Funktion ADD-PATH für Peering-Sitzungen gemäß RFC 7911. 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 GKE on Bare Metal Knoten zum Bewerben aus dem Load-Balancer-Knotenpool aus und versucht, die nächsten Hops für verschiedene VIPs auf verschiedene Knoten zu verteilen.

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

GKE on Bare Metal weist jedem Knoten im selben Subnetz wie die Floating-IP-Adresse automatisch Floating-IP-Adressen 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. GKE on Bare Metal sorgt dafür, dass die Floating-IP-Adresszuweisungen und das BGP-Peering nur von Load-Balancer-Knoten aus erfolgen.

BGP-Load-Balancing mit Dual-Stack-Netzwerk einrichten

Ab GKE on Bare Metal-Version 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 erforderlich sind, um gebündeltes Dual-Stack-Load-Balancing mit BGP zu konfigurieren.

Zum Aktivieren von Dual-Stack-LoadBalancer-Diensten sind die folgenden Konfigurationsänderungen erforderlich:

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

    • Geben Sie in der Clusterkonfigurationsdatei unter spec.clusterNetwork.services.cidrBlocks sowohl die IPv4- als auch die 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-Netzwerk.

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

Die folgende Beispielkonfiguration hebt die Änderungen hervor, die für das gebündelte Dual-Stack-Load-Balancing mit BGP erforderlich sind:

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 gebündeltes Dual-Stack-Load-Balancing mit BGP

Beachten Sie die folgenden Einschränkungen, wenn Sie Ihren Cluster für die Verwendung von Dual-Stack und gebündeltem Load-Balancing mit BGP konfigurieren:

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

  • IPv6-BGP-Sitzungen werden nicht unterstützt. IPv6-Routen können jedoch ü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. 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), die Knoten der Datenebene zugewiesen sind, erreichen alle die Peers.

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.

BGP-Load-Balancing, bei dem alle Knoten dieselben Peers verwenden

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.

BGP-Load-Balancing mit expliziter Zuordnung von Ebenen der Steuerungsebene zu Peers

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.

BGP-Load-Balancing mit separater Konfiguration für Steuerungsebene und Datenebene

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 Ressource BGPPeer an und fügen Sie ein Label für die Peer-Auswahl hinzu, 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 nachfolgende Aktualisierungen an den BGP-bezogenen Ressourcen (NetworkGatewayGroup, BGPLoadBalancer und BGPPeer) vornehmen. Der Administratorcluster gleicht die Änderungen dann mit dem Nutzercluster ab. Wenn Sie diese Ressourcen direkt im Nutzercluster bearbeiten, überschreibt der Administratorcluster Ihre Änderungen in nachfolgenden Abgleichen.

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 mit SSH eine Verbindung zum Knoten her. Verwenden Sie dann kubectl, um die Clusterressource zum Bearbeiten zu öffnen.

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 Registrierungsspiegel verwenden, führen Sie die folgenden Befehle aus, um das Docker-Image "ansible-runner" 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/

    Ersetzen Sie Folgendes:

    • 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

    Ersetzen Sie Folgendes:

    • 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 als virtuelle IP-Adresse der 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-Argument --advertise-ip von bgpadvertiser.
    • INTF_NAME: die Kubernetes-Schnittstelle auf dem Knoten. Das ist die Schnittstelle mit der IP-Adresse, die Sie in der GKE on Bare Metal-Konfiguration für loadBalancer.bgpPeers.controlPlaneNodes angegeben haben.

  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.