Flaches IPv4-Netzwerkmodell 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 sich Knoten über eine einzelne Layer 2-Domain erstrecken. Verwenden Sie für Knoten, die sich über mehrere Layer 2-Domains erstrecken, den Flat-IP-Modus mit BGP.

Beim 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 einem beliebigen 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 Standardnetzwerkmodell im Inselmodus 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 einen eindeutigen Pod-CIDR zuweisen können. Sie können die Pod-CIDRs dynamisch mit den ClusterCIDRConfigs konfigurieren. Sie können ClusterCIDRConfigs nach der Clustererstellung 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 Flat-Network-Modus 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 angeben (mit ClusterCIDRConfigs), müssen sich im selben Subnetz wie die Clusterknoten befinden. Die konfigurierten Pod-CIDRs 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 zu setzen.

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

  2. Hängen 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 für die Clustererstellung wird geprüft, 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 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. Wenn Sie die CIDRs durch Ihre eigenen ersetzen, achten Sie darauf, dass sie die Kriterien für die Erreichbarkeit von Pods erfüllen, die unter Erreichbarkeit von Pod-IP-Adressen 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, die Flat-Mode-Netzwerke verwenden, wären innerhalb der einzelnen Ebene-2-Domain erreichbar. Jeder andere Computer, der sich nicht im Cluster, aber in derselben Layer 2-Domain befindet, kann 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 Erreichbarkeit der Pod-IP-Adresse.

  • 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 Layer 2-Domäne nicht mit den POD-CIDRs in Konflikt geraten. Weitere Informationen finden Sie unter Erreichbarkeit der Pod-IP-Adresse.