Netzwerkmodell im flachen Modus mit BGP-Unterstützung implementieren

In diesem Dokument wird beschrieben, wie Sie ein flaches Netzwerkmodell mit Unterstützung für das Border Gateway Protocol (BGP) implementieren. Wenn Sie ein Netzwerkmodell mit BGP-Unterstützung implementieren, stellt BGP dynamisch sicher, dass Pods in verschiedenen Layer-2-Domains miteinander kommunizieren können. Netzwerke im flachen Modus mit BGP werden manchmal als dynamische Flat-IP bezeichnet.

Weitere Informationen zu Netzwerkmodellen im flachen Modus finden Sie unter Netzwerkmodelle im flachen Modus und im Inselmodus.

Netzwerk im flachen Modus implementieren, das BGP verwendet

Flache Netzwerke mit BGP werden aktiviert, wenn Sie einen neuen Cluster erstellen. Sie können dieses Feature nicht für einen vorhandenen Cluster aktivieren. Sobald dieses Feature aktiviert ist, können Sie Änderungen an einigen Konfigurationseinstellungen vornehmen.

So implementieren Sie einen Cluster in einem flachen Netzwerkmodell mit BGP-Unterstützung:

1. Bearbeiten Sie die Clusterkonfigurationsdatei:

   • Setzen Sie das Feld spec.clusterNetwork.advancedNetworking auf true.

   • Wenn Sie flache Netzwerke für IPv4 aktivieren möchten, setzen Sie das Feld spec.clusterNetwork.flatIPv4 auf true.

     Alternativ können Sie sich den Artikel Dual-Stack-Cluster (IPv4-Insel, IPv6 Dynamic Flat IP) ansehen, in dem Ihr Cluster mit einem Flat-Mode-Netzwerk nur für IPv6 konfiguriert wird.

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: bm
     namespace: cluster-bm
   spec:
     type: user
     ...
     clusterNetwork:
       advancedNetworking: true
       flatIPv4: true
     ...
   

   Wenn spec.clusterNetwork.flatIPv4 auf true gesetzt ist, wird das Feld spec.clusterNetwork.pods.cidrBlocks ignoriert und kann ausgelassen werden. Allerdings müssen Sie in der Clusterkonfigurationsdatei ein ClusterCIDRConfigs-Manifest hinzufügen (pro Knoten, pro Knotenpool und/oder pro Cluster).

2. Hängen Sie ein NetworkGatewayGroup-Manifest an die Clusterkonfigurationsdatei an:

   Geben Sie die Floating-IP-Adressen an, die für das BGP-Peering verwendet werden sollen. Achten Sie darauf, dass der Ressourcenname default und der Namespace der Cluster-Namespace ist.

   ---
   apiVersion: networking.gke.io/v1
   kind: NetworkGatewayGroup
   metadata:
     name: default
     namespace: cluster-bm
   spec:
     floatingIPs:
     - 10.0.1.100
     - 10.0.2.100
   

   Die benutzerdefinierte Ressource NetworkGatewayGroup verwaltet eine Liste mit einer oder mehreren Floating-IP-Adressen. Die BGP-Peering-Sitzungen werden über Floating-IP-Adressen initiiert, die Sie in der benutzerdefinierten Ressource NetworkGatewayGroup angeben.

3. Hängen Sie ein FlatIPMode-Manifest an die Clusterkonfigurationsdatei an:

   Der Name der Ressource FlatIPMode muss default sein und der Namespace ist der Cluster-Namespace. Der peerSelector-Wert flatip-peer: "true" stimmt mit den Labels in den BGPPeer-Objekten bgppeer1 und bgppeer2 überein (definiert im folgenden Schritt), sodass beide Peers für Flat-Mode-Netzwerke verwendet werden.

   Das folgende FlatIPMode-Manifest gilt für IPv4-Einzelstack-, Flat-Mode-Netzwerke mit BGP. Informationen zu alternativen Konfigurationen finden Sie unter Konfigurationsbeispiele.

   ---
   apiVersion: baremetal.cluster.gke.io/v1alpha1
   kind: FlatIPMode
   metadata:
     name: default
     namespace: cluster-bm
   spec:
     enableBGPIPv4: true
     enableBGPIPv6: false
     peerSelector:
       flatip-peer: "true"
   

4. Hängen Sie ein oder mehrere BGPPeer-Manifeste an die Clusterkonfigurationsdatei an:

   Sie wählen die Namen für die Ressourcen aus, aber alle BGPPeer-Ressourcen müssen sich im Cluster-Namespace befinden.

   Hinweis: IPv6 wird für BGP-Peers und -Sitzungen nicht unterstützt. Sie können BGP-Peers nur mit IPv4-Adressen konfigurieren.

   ---
   apiVersion: networking.gke.io/v1
   kind: BGPPeer
   metadata:
     name: bgppeer1
     namespace: cluster-bm
     labels:
       flatip-peer: "true"
   spec:
     localASN: 65001
     peerASN: 65000
     peerIP: 10.0.1.254
     sessions: 2
   ---
   apiVersion: networking.gke.io/v1
   kind: BGPPeer
   metadata:
     name: bgppeer2
     namespace: cluster-bm
     labels:
       flatip-peer: "true"
   spec:
     localASN: 65001
     peerASN: 65000
     peerIP: 10.0.2.254
     sessions: 2
   

5. Hängen Sie ein ClusterCIDRConfig-Manifest an die Clusterkonfigurationsdatei an:

   Die Ressource CusterCIDRConfig muss sich auch im Cluster-Namespace befinden.

   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
   

   ClusterCIDRConfig ist eine benutzerdefinierte Ressource, die Pod-CIDR-Bereiche angibt, die Knoten dynamisch zugewiesen werden sollen. Das CNI verwendet die auf einem Knoten zugewiesenen Pod-CIDR-Bereiche, um den einzelnen Pods, die auf dem Knoten ausgeführt werden, IP-Adressen zuzuweisen. ClusterCIDRConfig wird auch für Dual-Stack-Netzwerke verwendet. Weitere Informationen zur benutzerdefinierten Ressource ClusterCIDRConfig, einschließlich Nutzungsbeispielen, finden Sie unter Informationen zur benutzerdefinierten ClusterCIDRConfig-Ressource.

6. Erstellen Sie den Cluster:

   bmctl create cluster
   

   Weitere Informationen zum Erstellen von Clustern finden Sie unter Clustererstellung – Übersicht.

   Wenn Ihre Umgebung Multi-Protokoll-BGP (MP-BGP) unterstützt, können IPv4- und IPv6-Routen über diese IPv4-Sitzungen beworben werden. Beispiele für verschiedene Konfigurationen, einschließlich Beispielen mit MP-BGP, finden Sie unter Konfigurationsbeispiele.

BGP-basierte Flat-Mode-Netzwerkkonfiguration ändern

Nachdem Sie den Cluster für die Verwendung eines Flat-Mode-Netzwerkmodells mit BGP konfiguriert haben, können einige Konfigurationseinstellungen aktualisiert werden. Verwenden Sie die kubeconfig-Datei des Administratorclusters, wenn Sie nachfolgende Aktualisierungen an den BGP-bezogenen Ressourcen vornehmen (NetworkGatewayGroup, FlatIPMode und BGPPeer). Der Administratorcluster gleicht dann die Änderungen am Nutzercluster ab. Wenn Sie diese Ressourcen direkt im Nutzercluster bearbeiten, überschreibt der Administratorcluster Ihre Änderungen in nachfolgenden Abgleichen.

Beispielkonfigurationen

Die folgenden Abschnitte enthalten Beispiele für die Clusterkonfiguration für verschiedene Varianten des flachen Netzwerkmodells mit BGP. Die Beispielkonfigurationsdateien sind nicht vollständig. Die meisten Clustereinstellungen, die für Flat-Mode-Netzwerke mit BGP nicht relevant sind, wurden ausgelassen.

Achtung: Die IP-Adressen, die in den folgenden Konfigurationsbeispielen angezeigt werden, sind nur Beispiele. Ersetzen Sie die IP-Adressen durch Ihre eigene.

Einzelstack-IPv4-Cluster

Das folgende Beispiel für eine Clusterkonfigurationsdatei zeigt die Einstellungen zum Konfigurieren eines Einzelstack-IPv4-Clusters mit flachem Netzwerk und BGP:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
  ...
  clusterNetwork:
    advancedNetworking: true
    flatIPv4: true
    services:
      cidrBlocks:
      - 10.96.0.0/12
  ...
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig          
metadata:
  name: cluster-wide-1
  namespace: cluster-bm          # Must match the cluster namespace
spec:
  ipv4:
    cidr: "222.2.0.0/16"
    perNodeMaskSize: 24
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm           # Must match the cluster namespace
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.3.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: FlatIPMode
metadata:
  name: default
  namespace: cluster-bm            # Must match the cluster namespace
spec:
  enableBGPIPv4: true
  enableBGPIPv6: false
  peerSelector:
    flatipmode-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.1.254
  sessions: 2
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer2
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

Dual-Stack-Cluster (IPv4-Insel, IPv6 Dynamic Flat IP)

Das folgende Beispiel für eine Clusterkonfigurationsdatei zeigt die Einstellungen zum Konfigurieren eines Dual-Stack-Clusters (IPv4/IPv6) mit Flat-Mode-Netzwerk und BGP nur für IPv6:

Hinweis: Das Feld spec.flatIPv4 ist standardmäßig auf false gesetzt und kann bei dieser Konfiguration weggelassen werden. Wir haben dieses Feld in das folgende Beispiel aufgenommen, um Vergleiche anzustellen.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
  ...
  clusterNetwork:
    advancedNetworking: true
    flatIPv4: false
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/12
      # Additional IPv6 CIDR block determines if the cluster is dual-stack
      - 2620:0:1000:2630:5:2::/112
  ... 
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig          
metadata:
  name: cluster-wide-1
  namespace: cluster-bm          # Must match the cluster namespace
spec:
  ipv4:
    cidr: "192.168.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "2222:3::/112"
    perNodeMaskSize: 120
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm           # Must match the cluster namespace
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.3.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: FlatIPMode
metadata:
  name: default
  namespace: cluster-bm            # Must match the cluster namespace
spec:
  enableBGPIPv4: false
  enableBGPIPv6: true
  peerSelector:
    flatipmode-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.1.254
  sessions: 2
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer2
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

Dual-Stack-Cluster (Dynamic Flat IP IPv4, dynamisches Flat IP IPv6)

Das folgende Beispiel für eine Clusterkonfigurationsdatei zeigt die Einstellungen zum Konfigurieren eines Dual-Stack-Clusters mit flachem Netzwerk und BGP:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
  ...
  clusterNetwork:
    advancedNetworking: true
    flatIPv4: true
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/12
      # Additional IPv6 CIDR block determines if the cluster is dual-stack
      - 2620:0:1000:2630:5:2::/112
  ... 
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig          
metadata:
  name: cluster-wide-1
  namespace: cluster-bm          # Must match the cluster namespace
spec:
  ipv4:
    cidr: "222.2.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "2222:3::/112"
    perNodeMaskSize: 120
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm           # Must match the cluster namespace
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.3.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: FlatIPMode
metadata:
  name: default
  namespace: cluster-bm            # Must match the cluster namespace
spec:
  enableBGPIPv4: true
  enableBGPIPv6: true
  peerSelector:
    flatipmode-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.1.254
  sessions: 2
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer2
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

Fehlerbehebung

Dieser Abschnitt enthält Anweisungen zum Prüfen Ihrer Konfiguration, um Ihnen bei der Behebung von Problemen im Zusammenhang mit Flat-Mode-Netzwerken mit BGP zu helfen:

1. Prüfen Sie, ob im Cluster-Namespace des Administratorclusters ein FlatIPModes-Objekt erstellt wurde:

   kubectl get flatipmodes -A --kubeconfig ADMIN_KUBECONFIG
   

   Die Antwort sollte in etwa so aussehen:

   NAMESPACE                 NAME      AGE
   cluster-bm                default   2d17h
   

2. Prüfen Sie, ob im Nutzercluster ein flatipmodes.networking.gke.io-Objekt erstellt wurde:

   Das Objekt flatipmodes.networking.gke.io ist clusterbezogen.

   kubectl get flatipmodes.networking.gke.io --kubeconfig USER_KUBECONFIG
   

   Die Antwort sollte in etwa so aussehen:

   NAME      AGE
   default   2d17h
   

3. Rufen Sie die BGPSessions-Ressourcen ab, um die aktuellen Sitzungen anzusehen:

   kubectl get bgpsessions -A --kubeconfig USER_KUBECONFIG
   

   Die Antwort sollte in etwa so aussehen:

   NAMESPACE     NAME                LOCAL ASN   PEER ASN   LOCAL IP       PEER IP        STATE            LAST REPORT
   kube-system   10.0.1.254-node-01  65500       65000      10.0.1.100     10.0.1.254     Established      2s
   kube-system   10.0.1.254-node-02  65500       65000      10.0.3.100     10.0.1.254     NotEstablished   2s
   kube-system   10.0.3.254-node-01  65500       65000      10.0.1.100     10.0.3.254     NotEstablished   2s
   kube-system   10.0.3.254-node-02  65500       65000      10.0.3.100     10.0.3.254     Established      2s
   

4. Rufen Sie die Ressourcen BGPAdvertisedRoute ab, um die derzeit beworbenen Routen zu sehen:

   kubectl get bgpadvertisedroutes -A --kubeconfig USER_KUBECONFIG
   

   Die Antwort sollte in etwa so aussehen:

   NAMESPACE     NAME                     PREFIX         METRIC
   kube-system   route-via-222-22-208-240   222.2.0.0/24   
   kube-system   route-via-222-22-209-240   222.2.1.0/24   
   

   Die Routennamen geben den nächsten Hop an. Beispielsweise gibt route-via-222-22-208-240 aus der vorherigen Beispielantwort an, dass der nächste Hop für das beworbene Präfix 222.2.0.0/24 222.22.208.240 ist.