Netzwerkmodell im flachen IPv4-Modus implementieren

Übersicht

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

In einem Netzwerkmodell im flachen Modus haben Pods clusterübergreifend eindeutige IP-Adressen. Die zugewiesenen Pod-CIDRs müssen eindeutig sein und dürfen 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. Daher können Pods auf jedem Knoten mit allen Pods auf allen anderen Knoten kommunizieren. Für die Kommunikation vom Pod zu einer externen IP-Adresse ist keine Netzwerkadressübersetzung (NAT) erforderlich. Weitere Informationen zum Netzwerkmodell im flachen Modus und zum Vergleich mit dem standardmäßigen Inselnetzwerkmodell finden Sie unter Netzwerkmodelle im flachen Modus 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 mit den ClusterCIDRConfigs dynamisch konfigurieren. Sie können ClusterCIDRConfigs nach dem Erstellen des Clusters hinzufügen oder löschen. Weitere Informationen zu ClusterCIDRConfig und Beispiele für die Verwendung finden Sie in Weitere Informationen zur benutzerdefinierten Ressource „ClusterCIDRConfig“.

Weitere Informationen zum flachen Modus mit BGP finden Sie unter Netzwerkmodell im flachen Modus 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 die IP-Adressen von Pods nur erreichbar, wenn sich die Pods in derselben Layer-2-Domain befinden. Die Knoten müssen zur selben Layer-2-Domain gehören. Die IP-Adressen, die Sie für Ihre Pods angeben (mit ClusterCIDRConfigs), müssen sich im selben Subnetz wie die Clusterknoten befinden. Die konfigurierten CIDRs für Pods müssen aus dem Subnetz der Knoten stammen. Wenn beispielsweise das Subnetz 222.1.0.0/16 von den Knoten in einem Cluster verwendet wird, wählen Sie ein kleineres Subnetz innerhalb des Subnetzes für die Pods aus, z. B. 222.1.2.0/24. Achten Sie darauf, dass keine andere Ressource in Ihrem Cluster eine IP-Adresse aus dem für Ihre Pods zugewiesenen Bereich verwendet.

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

Statisches Netzwerk im Flat-Modus implementieren

Standardmäßig wird ein Google Distributed Cloud-Cluster 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:

Das Netzwerk im Flat-Modus kann für einen Cluster nur während der Clustererstellung aktiviert werden. So erstellen Sie einen neuen Cluster mit Flat-Modus-Netzwerk:

  1. Bearbeiten Sie die Clusterkonfigurationsdatei, um clusterNetwork.flatIPv4 hinzuzufügen und auf true festzulegen.

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

  2. Fügen Sie der Clusterkonfigurationsdatei ein ClusterCIDRConfig-Manifest an.

    Fügen Sie dem ClusterCIDRConfig-Manifest die folgenden Informationen hinzu:

    • metadata.namespace: der Namespace Ihres Clusters.

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

    • perNodeMaskSize: Bei den Vorabprüfungen vor der Clustererstellung wird geprüft, ob der Wert für perNodeMaskSize ausreicht, um die in maxPodsPerNode angegebene Anzahl von Pods bereitzustellen.

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

Der folgende Auszug aus einer Clusterkonfigurationsdatei zeigt, wie ein Netzwerk im Flat-Modus ohne BGP-Unterstützung implementiert wird. Die in diesem Auszug angezeigten CIDRs sind nur Beispiele und müssen durch Ihre eigenen CIDRs ersetzt werden. Achten Sie beim Ersetzen der CIDRs durch Ihre eigenen darauf, dass sie die Kriterien für die Pod-Erreichbarkeit erfüllen, die im Artikel Pod-IP-Adresserreichbarkeit beschrieben sind.

---
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 Google Distributed Cloud hat folgende Einschränkungen:

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

  • Der IPAM-Controller von Google Distributed Cloud überwacht die Verfügbarkeit von IP-Adressen innerhalb der konfigurierten Pod-CIDRs. Es werden keine IP-Adressen erfasst, die bereits von anderen Geräten verwendet werden. Daher dürfen andere IP-Adressen in der Layer 2-Domain nicht mit den POD-CIDRs in Konflikt stehen. Weitere Informationen finden Sie unter IP-Adresserreichbarkeit von Pods.