Flaches Netzwerkmodell im IPv4-Modus implementieren

Überblick

Im flachen Modus gibt es zwei Netzwerkmodelle im statischen und dynamischen Modus (unter Verwendung des Border Gateway Protocol). Der statische Flat-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 flachen Netzwerkmodell haben Pods in allen Clustern eindeutige IP-Adressen. Die zugewiesenen Pod-CIDRs müssen eindeutig sein und sich nicht mit anderen Subnetzen überschneiden. IP-Adressen dürfen sich beispielsweise 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, sodass Pods auf jedem Knoten mit allen Pods auf allen anderen Knoten kommunizieren können. Für die Kommunikation vom Pod mit einer externen IP-Adresse ist keine Network Address Translation (NAT) erforderlich. Weitere Informationen zum flachen Netzwerkmodell und seinem Vergleich mit dem Standard-Netzwerkmodell im Inselmodus finden Sie unter Netzwerkmodelle im flachen und im Inselmodus.

Verwenden Sie ein Netzwerkmodell im flachen 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 nach dem Erstellen des Clusters hinzufügen oder löschen. Weitere Informationen zu ClusterCIDRConfig und Beispiele zu seiner Verwendung finden Sie unter Informationen zur benutzerdefinierten Ressource ClusterCIDRConfig.

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

Informationen zur Erreichbarkeit von Pod-IP-Adressen

Im Static-Flat-Netzwerkmodus für IPv4 basiert die Erreichbarkeit von Pod-IP-Adressen auf ARP-Paketen (Address Resolution Protocol). Daher sind Pod-IP-Adressen nur 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 für Ihre Pods (mit ClusterCIDRConfigs) angeben, müssen sich im selben Subnetz wie die Clusterknoten befinden. Die konfigurierten Pod-CIDRs müssen aus dem Subnetz der Knoten stammen. Beispiel: Das Subnetz 222.1.0.0/16 wird von den Knoten in einem Cluster verwendet. Wählen Sie dann ein kleineres Subnetz innerhalb des Subnetzes für die Pods aus, 222.1.2.0/24. Achten Sie darauf, dass keine andere Ressource im Cluster eine IP-Adresse aus dem Bereich verwendet, der Ihren Pods zugewiesen ist.

Der folgende Abschnitt beschreibt die Konfiguration von Flat-Mode-Netzwerken für IPv4.

Statisches Flat-Mode-Netzwerk implementieren

Standardmäßig wird Google Distributed Cloud-Cluster im Netzwerk im Inselmodus erstellt. In diesem Abschnitt wird beschrieben, wie Sie ein flaches Netzwerk für Ihren Cluster einrichten.

Nehmen Sie die folgenden Änderungen an der Clusterkonfigurationsdatei vor, um einen Cluster mit einem flachen Netzwerkmodell bereitzustellen:

Netzwerke im flachen Modus können für einen Cluster nur während der Clustererstellung aktiviert werden. Führen Sie die folgenden Schritte aus, um einen neuen Cluster mit flachem Netzwerk zu erstellen:

  1. Fügen Sie in der Clusterkonfigurationsdatei clusterNetwork.flatIPv4 hinzu und legen Sie dafür true fest.

    Wenn Sie Netzwerke im flachen Modus aktivieren, wird das in der Clusterkonfigurationsdatei (clusterNetwork.pods.cidrBlocks) angegebene Pod-CIDR ignoriert.

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

    Geben Sie im ClusterCIDRConfig-Manifest die folgenden Informationen an:

    • metadata.namespace ist der Namespace Ihres Clusters.

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

    • perNodeMaskSize: Preflight-Prüfungen bei der Clustererstellung prüfen, ob der Wert perNodeMaskSize ausreicht, 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 Sie ein Flat-Mode-Netzwerk ohne BGP-Unterstützung implementieren. Die in diesem Auszug aufgeführten CIDRs sind nur Beispiele. Sie müssen sie durch Ihre eigenen CIDRs ersetzen. Wenn Sie die CIDRs durch Ihre eigenen ersetzen, achten Sie darauf, dass sie die Kriterien für die Pod-Erreichbarkeit erfüllen, wie unter Informationen zur Erreichbarkeit der Pod-IP-Adresse beschrieben.

---
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 Flachmodus-Netzwerk für Google Distributed Cloud hat die folgenden Einschränkungen:

  • Pods, die Netzwerke im flachen Modus verwenden, wären innerhalb der einzelnen Ebene-2-Domain erreichbar. Alle anderen Maschinen, die sich nicht im Cluster, aber in derselben Ebene-2-Domain befinden, können die Pods ebenfalls erreichen. Diese Einschränkung gilt auch für IPv6, wenn Dual-Stack-Cluster erstellt werden und sich IPv6 im Flat-Modus ohne BGP befindet. Weitere Informationen finden Sie unter Informationen zur Erreichbarkeit von Pod-IP-Adressen.

  • Der Google Distributed Cloud IPAM-Controller verfolgt die Verfügbarkeit von 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 die POD-CIDRs nicht beeinträchtigen. Weitere Informationen finden Sie unter Informationen zur Erreichbarkeit von Pod-IP-Adressen.