Ein flaches Netzwerkmodell im IPv4-Modus implementieren

Überblick

Es gibt zwei Arten von Netzwerkmodellen im flachen Modus: statische Netzwerke und Netzwerke im dynamischen Modus (mit Border Gateway Protocol). Der statische flache Modus kann verwendet werden, wenn Knoten eine einzelne Ebene-2-Domain umfassen. Verwenden Sie für Knoten, die sich über mehrere Layer-2-Domains erstrecken, den flachen IP-Modus mit BGP.

In einem Netzwerkmodell im Flat-Modus haben Pods in allen Clustern eindeutige IP-Adressen. Achten Sie darauf, dass die zugewiesenen Pod-CIDRs eindeutig sind und sich nicht mit anderen Subnetzen überschneiden. Beispielsweise dürfen sich IP-Adressen nicht mit IP-Adressen überschneiden, die für die Knoten oder die anderen Pod-CIDRs in anderen Clustern verwendet werden. Auf diese IP-Adressen kann extern zugegriffen werden. Daher können Pods auf jedem Knoten mit allen Pods auf anderen Knoten kommunizieren. Für die Kommunikation vom Pod mit einer externen IP-Adresse ist keine Network Address Translation (NAT) erforderlich. Weitere Informationen zum Netzwerkmodell im flachen Modus und dessen Vergleich mit dem standardmäßigen Inselnetzwerkmodell finden Sie unter Netzwerkmodelle im flachen und im Inselmodus.

Verwenden Sie ein Netzwerkmodell im Flat-Modus, wenn Sie einen großen IP-Adressbereich haben und einem Cluster ein eindeutiges Pod-CIDR zuweisen können. Sie können die Pod-CIDRs mithilfe der ClusterCIDRConfigs dynamisch konfigurieren. Sie können ClusterCIDRConfigs hinzufügen oder löschen, nachdem der Cluster erstellt wurde. Weitere Informationen zu ClusterCIDRConfig und Beispiele zu seiner Verwendung finden Sie unter Benutzerdefinierte Ressource „ClusterCIDRConfig“.

Weitere Informationen zum Flat-Modus mit BGP finden Sie unter Flat-Mode-Netzwerkmodell mit BGP-Unterstützung implementieren.

Erreichbarkeit von Pod-IP-Adressen

Im statischen flachen Netzwerkmodus für IPv4 basiert die Erreichbarkeit von Pod-IP-Adressen auf ARP-Paketen (Address Resolution Protocol). Daher sind Pod-IP-Adressen nur dann erreichbar, wenn sich die Pods in derselben Ebene-2-Domain befinden. Die Knoten müssen zur selben Ebene-2-Domain gehören. Die IP-Adressen, die Sie mit ClusterCIDRConfigs für Ihre Pods angeben, müssen sich im selben Subnetz wie die Clusterknoten befinden. Die konfigurierten Pod-CIDRs müssen aus dem Subnetz des Knotens stammen. Das Subnetz 222.1.0.0/16 wird beispielsweise von den Knoten in einem Cluster verwendet. Wählen Sie dann ein kleineres Subnetz innerhalb des Subnetzes für die Pods aus, nämlich 222.1.2.0/24. Achten Sie darauf, dass keine andere Ressource in Ihrem Cluster eine IP-Adresse aus dem Bereich verwendet, der Ihren Pods zugewiesen ist.

Im folgenden Abschnitt wird die Konfiguration für Flat-Mode-Netzwerke für IPv4 beschrieben.

Statisches Flat-Mode-Netzwerk implementieren

Standardmäßig wird der GKE on Bare Metal-Cluster in einem Netzwerk im Inselmodus erstellt. In diesem Abschnitt wird beschrieben, wie Sie ein Netzwerk im Flat-Modus für Ihren Cluster einrichten.

Nehmen Sie die folgenden Änderungen an der Clusterkonfigurationsdatei vor, um einen Cluster mit einem Netzwerkmodell im Flat-Modus bereitzustellen:

Ein flaches Netzwerk kann für einen Cluster nur während der Clustererstellung aktiviert werden. Führen Sie die folgenden Schritte aus, um einen neuen Cluster mit einem Flat-Modus-Netzwerk zu erstellen:

  1. Fügen Sie der Clusterkonfigurationsdatei clusterNetwork.flatIPv4 hinzu und legen Sie sie auf true fest.

    Wenn Sie ein Netzwerk im Flat-Modus aktivieren, wird der in der Clusterkonfigurationsdatei (clusterNetwork.pods.cidrBlocks) angegebene Pod-CIDR-Bereich ignoriert.

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

    Geben Sie im ClusterCIDRConfig-Manifest die folgenden Informationen an:

    • metadata.namespace: der Namespace Ihres Clusters.

    • spec.ipv4.cidr: der für Pods in Ihrem Cluster zu verwendende IP-Adressbereich im CIDR-Blockformat. Dieser Bereich muss aus demselben Subnetz wie die Clusterknoten stammen.

    • perNodeMaskSize: Bei Preflight-Prüfungen bei der Clustererstellung wird der Wert perNodeMaskSize ausreichend, um die in maxPodsPerNode angegebene Anzahl von Pods bereitzustellen.

    • nodeSelector: Wenn keine Knotenlabels mit dem Wert nodeSelector übereinstimmen, bleibt der Knotenabgleich ausstehend und die Clustererstellung wird nicht abgeschlossen.

Der folgende Auszug einer Clusterkonfigurationsdatei zeigt, wie ein Flachmodus-Netzwerk ohne BGP-Unterstützung implementiert wird. Die in diesem Auszug angezeigten CIDRs sind nur Beispiele und Sie müssen sie durch Ihre eigenen CIDRs ersetzen. Wenn Sie die CIDRs durch Ihre eigenen ersetzen, müssen Sie dafür sorgen, dass sie die unter Erreichbarkeit von Pod-IP-Adressen beschriebenen Kriterien für die Pod-Erreichbarkeit erfüllen.

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: flat-mode
  namespace: cluster-flat-mode
spec:
... (other cluster config omitted)

...
  # Cluster networking configuration
  clusterNetwork:
    flatIPv4: true
    services:
      cidrBlocks:
      - 10.96.0.0/12
... (other cluster config omitted)

...
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-flat-mode
spec:
  ipv4:
    cidr: "222.1.0.0/16"
    perNodeMaskSize: 24

Beschränkungen

Das statische Netzwerk im Flat-Modus für GKE on Bare Metal hat die folgenden Einschränkungen:

  • Pods, die Flat-Mode-Netzwerke verwenden, wären innerhalb der einzelnen Ebene-2-Domain erreichbar. Jede andere Maschine, die sich nicht im Cluster, aber in derselben Ebene-2-Domain befindet, kann die Pods ebenfalls erreichen. Diese Einschränkung gilt sowohl für IPv6 als auch für das Erstellen von Dual-Stack-Clustern und wenn sich IPv6 im flachen Modus ohne BGP befindet. Weitere Informationen finden Sie unter Erreichbarkeit von Pod-IP-Adressen.

  • Der IPAM-Controller von GKE on Bare Metal verfolgt die Verfügbarkeit der IP-Adressen innerhalb der konfigurierten Pod-CIDRs. IP-Adressen, die bereits von anderen Geräten verwendet werden, werden nicht erfasst. Daher dürfen andere IP-Adressen in der Ebene-2-Domain nicht die POD-CIDRs beeinträchtigen. Weitere Informationen finden Sie unter Erreichbarkeit von Pod-IP-Adressen.