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, sorgt BGP dynamisch dafür, dass Pods in verschiedenen Layer-2-Domains miteinander kommunizieren können. Ein flaches Netzwerk mit BGP wird 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
Flat-Mode-Netzwerke mit BGP werden aktiviert, wenn Sie einen neuen Cluster erstellen. Sie können dieses Feature nicht für einen vorhandenen Cluster aktivieren. Wenn diese Funktion aktiviert ist, können Sie an einigen Konfigurationseinstellungen Änderungen vornehmen.
So implementieren Sie einen Cluster in einem Flat-Mode-Netzwerkmodell mit BGP-Unterstützung:
Bearbeiten Sie die Clusterkonfigurationsdatei:
- Setzen Sie das Feld
spec.clusterNetwork.advancedNetworking
auftrue
. Wenn Sie ein Flat-Mode-Netzwerk für IPv4 aktivieren möchten, setzen Sie das Feld
spec.clusterNetwork.flatIPv4
auftrue
.Eine Alternative finden Sie unter Dual-Stack-Cluster (IPv4 Island, IPv6 Dynamic Flat IP), in dem Sie Ihren Cluster mit einem Flat-Mode-Netzwerk nur für IPv6 konfigurieren.
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
auftrue
gesetzt ist, wird das Feldspec.clusterNetwork.pods.cidrBlocks
ignoriert und kann ausgelassen werden. Allerdings müssen Sie in der Clusterkonfigurationsdatei einClusterCIDRConfigs
-Manifest hinzufügen (pro Knoten, pro Knotenpool und/oder pro Cluster).- Setzen Sie das Feld
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 von Floating-IP-Adressen initiiert, die Sie in der benutzerdefinierten RessourceNetworkGatewayGroup
angeben.Hängen Sie ein
FlatIPMode
-Manifest an die Clusterkonfigurationsdatei an:Der Name der
FlatIPMode
-Ressource mussdefault
sein und der Namespace ist der Cluster-Namespace. DerpeerSelector
-Wertflatip-peer: "true"
stimmt mit den Labels in den BGPPeer-Objektenbgppeer1
undbgppeer2
überein (definiert im folgenden Schritt), sodass beide Peers für ein Flat-Mode-Netzwerk 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"
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.--- 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
Hängen Sie ein
ClusterCIDRConfig
-Manifest an die Clusterkonfigurationsdatei an:Die Ressource
CusterCIDRConfig
muss sich ebenfalls 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 dynamisch Knoten 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 RessourceClusterCIDRConfig
, einschließlich Verwendungsbeispiele, finden Sie unter Benutzerdefinierte Ressource „ClusterCIDRConfig“.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 (NetworkGatewayGroup
, FlatIPMode
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.
Beispielkonfigurationen
Die folgenden Abschnitte enthalten Beispiele für Clusterkonfigurationen für verschiedene Varianten des Netzwerkmodells im flachen Modus mit BGP. Die Beispielkonfigurationsdateien sind nicht vollständig. Die meisten Clustereinstellungen, die für ein Flat-Modus-Netzwerk mit BGP nicht relevant sind, wurden ausgelassen.
Single-Stack-IPv4-Cluster
Das folgende Beispiel für die Clusterkonfigurationsdatei zeigt die Einstellungen zum Konfigurieren eines Einzelstack-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, IPv6 Dynamic Flat IP)
Das folgende Beispiel einer Clusterkonfigurationsdatei zeigt die Einstellungen zum Konfigurieren eines Dual-Stack-Clusters (IPv4/IPv6) mit einem Flat-Mode-Netzwerk und BGP nur für IPv6:
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 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
Damit Sie Probleme im Zusammenhang mit einem Flat-Mode-Netzwerk mit BGP beheben können, enthält dieser Abschnitt eine Anleitung zum Prüfen Ihrer Konfiguration:
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
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
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
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.
route-via-222-22-208-240
aus der vorherigen Beispielantwort gibt beispielsweise an, dass der nächste Hop für das beworbene Präfix222.2.0.0/24
222.22.208.240
ist.