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, gewährleistet BGP dynamisch, dass Pods in verschiedenen Layer 2-Domains miteinander kommunizieren können. Ein Netzwerk im flachen Modus mit BGP wird manchmal als dynamische flache 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

Ein Netzwerk im flachen Modus mit BGP wird aktiviert, wenn Sie einen neuen Cluster erstellen. Sie können diese Funktion nicht für einen bestehenden Cluster aktivieren. Sobald diese Funktion aktiviert ist, können Sie einige der Konfigurationseinstellungen ändern.

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

1. Bearbeiten Sie die Clusterkonfigurationsdatei:

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

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

     Eine Alternative dazu finden Sie unter Dual-Stack-Cluster (IPv4 Island, IPv6 Dynamic Flat IP), der Ihren Cluster mit einem Flat-Mode-Netzwerk nur für IPv6 konfiguriert.

   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 dem Cluster ein ClusterCIDRConfigs-Manifest in der Konfigurationsdatei 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 von Ihnen angegebene Floating-IP-Adressen in der benutzerdefinierten Ressource NetworkGatewayGroup initiiert.

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

   Der Name der Ressource FlatIPMode muss default und der Namespace der Cluster-Namespace sein. Der peerSelector-Wert flatip-peer: "true" entspricht den Labels in den BGP-Peer-Objekten bgppeer1 und bgppeer2 (im folgenden Schritt definiert), sodass beide Peers für Netzwerke im flachen Modus verwendet werden.

   Das folgende FlatIPMode-Manifest ist für IPv4 Single-Stack, 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 im Cluster-Namespace sein.

   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 den Knoten dynamisch zugewiesen werden. Der CNI verwendet die auf einem Knoten zugewiesenen Pod-CIDR-Bereiche, um den einzelnen Pods, die auf dem Knoten laufen, IP-Adressen zuzuweisen. ClusterCIDRConfig wird auch verwendet für Dual-Stack-Netzwerke. Weitere Informationen über die benutzerdefinierte Ressource ClusterCIDRConfig, einschließlich Anwendungsbeispielen, finden Sie unter Benutzerdefinierte Ressource ClusterCIDRConfig verstehen.

6. Erstellen Sie den Cluster:

   bmctl create cluster
   

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

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

BGP-basierte Netzwerkkonfiguration im flachen Modus ändern

Nachdem Sie den Cluster für die Verwendung eines Netzwerkmodells im flachen Modus mit BGP erstellt haben, können einige Konfigurationseinstellungen aktualisiert werden. Verwenden Sie die kubeconfig-Datei des Administratorclusters, wenn Sie nachfolgende Aktualisierungen der BGP-bezogenen Ressourcen (NetworkGatewayGroup, FlatIPMode und BGPPeer) vornehmen. Der Administratorcluster gleicht dann die Änderungen mit dem Nutzercluster ab. Wenn Sie diese Ressourcen auf dem Nutzercluster direkt bearbeiten, überschreibt der Administratorcluster Ihre Änderungen bei späteren Abgleichungen.

Beispielkonfigurationen

Die folgenden Abschnitte enthalten Cluster-Konfigurationsbeispiele für verschiedene Varianten des Flat-Mode-Netzwerkmodells mit BGP. Die Beispielkonfigurationsdateien sind nicht vollständig. Die meisten Cluster-Einstellungen, die für Flat-Mode-Netzwerke mit BGP nicht relevant sind, wurden weggelassen.

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

Single-Stack-IPv4-Cluster

Das folgende Beispiel für die Clusterkonfigurationsdatei zeigt die Einstellungen für das 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 Island, Dynamic Flat IP IPv6)

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

Hinweis: Das Feld spec.flatIPv4 ist standardmäßig auf false gesetzt und kann für diese Konfiguration ausgelassen werden. Wir haben dieses Feld in das folgende Beispiel aufgenommen, um den Vergleich zu erleichtern.

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

Das folgende Beispiel für die Clusterkonfigurationsdatei zeigt die Einstellungen für das 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

Damit Sie Probleme im Zusammenhang mit Netzwerken im Flatmodus mit BGP beheben können, enthält dieser Abschnitt eine Anleitung zum Prüfen Ihrer Konfiguration:

1. Prüfen Sie, ob ein FlatIPModes-Objekt im Namespace des Clusters auf dem Administratorcluster 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 aufzurufen:

   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 aktuell 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. Beispiel: route-via-222-22-208-240 aus der vorherigen Beispielantwort zeigt an, dass der nächste Hop für das beworbene Präfix 222.2.0.0/24 222.22.208.240 ist.