Version 1.8. Diese Version wird nicht mehr unterstützt. Weitere Informationen finden Sie in der Richtlinie zu unterstützten Versionen. Informationen zum Upgrade auf Version 1.9 finden Sie unter Upgrade von Anthos auf BareMetal ausführen in der Dokumentation zu 1.9.

Verfügbare unterstützte Versionen: 1.14 | 1.13 | 1.12

Diese Seite wurde von der Cloud Translation API übersetzt.

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 Anthos-Cluster 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. Auf 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-way-Funktion für Aktiv/Aktiv-Load-Balancing, um ein schnelleres 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 kompatibel ist, die mit eBGP kompatibel sind.
Rechenzentren, in denen ein erweiterter SDN-Stack (softwarebasiertes Netzwerkstack) ausgeführt wird, können die Layer-3-Grenze bis zu den Clustern auszuweiten.

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 AnthosNetworkGateway-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.
Die Verwendung der BGP-Funktion ADD-PATH im Empfangsmodus wird für Peering-Sitzungen dringend 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 Anthos-Cluster on Bare Metal-Steuerungsebene werden mit ihrem TOR verbunden.

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 weitere Peering-Sitzungen für LoadBalancer-Dienste initiiert. Diese Peering-Sitzungen werden nicht direkt von IP-Adressen des Clusterknotens initiiert, sondern verwenden 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 ermöglichen. Die Floating-IP-Adressen werden in der benutzerdefinierten Ressource (Custom Resource, CR) AnthosNetworkGateway 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 Anthos Network Gateway-Controller übernimmt die Zuweisung von AnthosNetworkGateway zu Knoten und verwaltet auch die Floating-IP-Adressen. Wenn ein Knoten ausfällt, weist der Anthos Network Gateway-Controller Floating-IP-Adressen neu zu, damit externe Peers eine deterministische IP-Adresse haben, mit der sie verbunden werden können.

Externe Peers

Die externen Peers, die für Peering-Sitzungen verwendet werden, werden mit den Floating-IP-Adressen in der benutzerdefinierten BGPLoadBalancer-Ressource festgelegt. Diese fügen Sie der Clusterkonfigurationsdatei hinzu. Die externen Peers können mit denen identisch sein, die für das Peering auf Steuerungsebene im Abschnitt loadBalancer.controlPlaneBGP der Clusterkonfigurationsdatei angegeben wurden. Sie können aber auch verschiedene Peers angeben.

Der Anthos Network Gateway-Controller versucht, für jeden externen Peer zwei Sitzungen aus der Gruppe der 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 AnthosNetworkGateway-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

Um den gebündelten Load-Balancer mit BGP verwenden zu 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.

Fügen Sie der Clusterkonfigurationsdatei die Annotation baremetal.cluster.gke.io/enable-anthos-network-gateway hinzu und setzen Sie sie auf true.

Diese Annotation aktiviert den Anthos Network Gateway-Controller.

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

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
    ...
```
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
...
```
Dabei gilt:
- 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.

Diese BGP-Peering-Konfiguration für die Steuerungsebene kann nach dem Erstellen des Clusters nicht aktualisiert werden.

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

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

Die Floating-IP-Adressen werden in Peering-Sitzungen für das Load-Balancing der Datenebene verwendet.
```
...
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
...
```
Dabei gilt:
- CLUSTER_NAMESPACE: der Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für Anthos-Cluster auf Bare-Metal der Name des Clusters, dem cluster- vorangestellt ist. Wenn Sie Ihren Cluster beispielsweise test benennen, 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.
Ein Beispiel dafür, wie die benutzerdefinierte Ressourcenspezifikation AnthosNetworkGateway aussehen könnte, finden Sie unter Beispielkonfigurationen.
Geben Sie die BGP-Peering-Informationen für die Datenebene an, indem Sie die benutzerdefinierte Ressource BGPLoadBalancer konfigurieren:
```
...
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: CLUSTER_NAMESPACE
spec:
  localASN: CLUSTER_ASN
  peers:
  - peerIP: PEER_IP
    peerASN: PEER_ASN
    ...
```
Dabei gilt:
- CLUSTER_NAMESPACE: der Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für Anthos-Cluster auf Bare-Metal der Name des Clusters, dem cluster- vorangestellt ist. Wenn Sie Ihren Cluster beispielsweise test benennen, lautet der Namespace cluster-test.
- CLUSTER_ASN: die Nummer des autonomen Systems für den zu erstellenden Cluster.
- PEER_IP: die IP-Adresse des externen Peer-Geräts. Sie müssen mindestens einen Peer angeben. Wir empfehlen jedoch, mindestens zwei Peers anzugeben. Sie können dieselben Peers verwenden, die auf der Steuerungsebene angegeben wurden.
- PEER_ASN: die autonome Systemnummer für das Netzwerk, das das externe Peer-Gerät enthält.
Sie können mehrere externe Peers angeben. peers verwendet eine Liste von Zuordnungspaaren. 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.
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.

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

Es wird dringend 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 Front-End-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 Anthos-Cluster on Bare Metal 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

In der Vorschauversion dieses Features weist Anthos-Cluster on Bare Metal 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. Anthos-Cluster auf Bare-Metal gewährleisten, dass die Floating-IP-Adresszuweisungen und das BGP-Peering nur von Load-Balancer-Knoten ausgeführt 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.

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 AnthosNetworkGateway-Ressource fest. Sie geben die entsprechenden externen Peers 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.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

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

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.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

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

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.10

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

Steuerungsebene und Datenebene separat konfigurieren

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

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

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

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.11

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
  name: bgplb
  namespace: cluster-bm
spec:
  bgp:
    localASN: 65001
    peers:
    - peerIP: 10.0.3.254
      peerASN: 65002

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.

Steuerungsebene

Änderungen an der Konfiguration des Load-Balancing der Steuerungsebene werden während der Vorschau nicht unterstützt.

Dienste

Sie können die BGP-Peering-Konfiguration nach dem Erstellen des Clusters ändern, indem Sie die Antwortvorlagen AnthosNetworkGateway und BGPLoadBalancer bearbeiten. Alle Änderungen an den Peering-Informationen in diesen CRs 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, sollte die Antwort in etwa so aussehen:

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                            AGE
10.0.1.254-node-01              170m
10.0.1.254-node-05              170m
10.0.3.254-node-01              170m
10.0.3.254-node-05              170m

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/v1alpha1
Kind:         BGPSession
Metadata:
 (omitted)
Spec:
  Floating IP:  10.0.1.178
  Local ASN:    65500
  Local IP:     10.0.1.178
  Node Name:    node-01
  Peer ASN:     65000
  Peer IP:      10.0.1.254
Status:
  Advertised Routes:
    10.0.4.1/32
  Last Report Time:  2021-06-14T22:09:36Z
  State:             Established

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                                  AGE
bgplb-default-load-balancer-example   5d5h
bgplb-gke-system-istio-ingress        6d

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

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.

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

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

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:

Fügen Sie die VIP Ihrem Knoten für die Steuerungsebene hinzu:
```
ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME
```
Dabei gilt:
- CONTROL_PLANE_VIP: das Argument --advertise-ip der VIP von bgpadvertiser.
- INTF_NAME: die Kubernetes-Schnittstelle auf dem Knoten. Das heißt, die Schnittstelle mit der IP-Adresse, die Sie in den Anthos-Clustern in die Bare-Metal-Konfiguration für loadBalancer.bgpPeers.controlPlaneNodes einfügen.
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.

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
```
Drücken Sie im Knoten der Steuerungsebene Ctrl + C im Terminal bgpadvertiser, um den BGB-Werbetreibenden zu beenden.
Prüfen Sie, ob keine bgpadvertiser-Prozesse ausgeführt werden:
```
ps -ef | grep bgpadvertiser
```
Wenn Prozesse ausgeführt werden, beenden Sie diese mit dem Befehl kill.