Netzwerkmodell im flachen Modus mit BGP-Unterstützung implementieren

Version 1.16 

• Neueste
• Version 1.16
• Frühere Versionen (nicht unterstützt)

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. Ein Flat-Mode-Netzwerk mit BGP wird manchmal als dynamische flache IP-Adresse 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

Das Flat-Mode-Netzwerk mit BGP wird 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 an einigen Konfigurationseinstellungen Änderungen vornehmen.

So implementieren Sie einen Cluster in einem Netzwerkmodell im Flat-Modus mit BGP-Unterstützung:

1. Bearbeiten Sie die Clusterkonfigurationsdatei:

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

   • Wenn Sie ein Netzwerk im Flat-Modus für IPv4 aktivieren möchten, setzen Sie das Feld spec.clusterNetwork.flatIPv4 auf true.

     Eine Alternative finden Sie unter Dual-Stack-Cluster (IPv4-Insel, IPv6 Dynamic Flat IP), in dem der 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. Sie müssen jedoch ein ClusterCIDRConfigs-Manifest in der Clusterkonfigurationsdatei 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 lauten und der Namespace ist der Cluster-Namespace. Der peerSelector-Wert flatip-peer: "true" entspricht den Labels in den BGPPeer-Objekten bgppeer1 und bgppeer2 (definiert im folgenden Schritt), sodass beide Peers für ein Netzwerk im Flat-Modus verwendet werden.

   Das folgende FlatIPMode-Manifest gilt für IPv4-Einzelstack-, Flat-Mode-Netzwerke mit BGP. Alternative 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. Der ClusterCIDRConfig wird auch für Dual-Stack-Netzwerke verwendet. Weitere Informationen zur benutzerdefinierten Ressource ClusterCIDRConfig, einschließlich Nutzungsbeispielen, finden Sie unter Informationen zur benutzerdefinierten Ressource „ClusterCIDRConfig“.

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 Ihren 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-Ressourcen (NetworkGatewayGroup, FlatIPMode und BGPPeer) 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.

Beispielkonfigurationen

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

Achtung: Die in den folgenden Konfigurationsbeispielen angezeigten IP-Adressen sind nur Beispiele. Ersetzen Sie die IP-Adressen durch Ihre eigenen.

Single-Stack-IPv4-Cluster

Das folgende Beispiel für eine Clusterkonfigurationsdatei zeigt die Einstellungen zum Konfigurieren eines Single-Stack-IPv4-Clusters mit einem Flat-Mode-Netzwerk mit 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, dynamische IPv6-Flat-IP-Adresse)

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 für diese Konfiguration weggelassen werden. Wir haben dieses Feld zur einfacheren Vergleiche in das folgende Beispiel aufgenommen.

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, IPv6 Dynamic Flat IP)

Das folgende Beispiel für eine Clusterkonfigurationsdatei zeigt die Einstellungen zum Konfigurieren eines Dual-Stack-Clusters mit einem Flat-Mode-Netzwerk mit 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 dem Flat-Mode-Netzwerk mit BGP zu helfen:

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

   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 wird:

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