Informationen zur benutzerdefinierten ClusterCIDRConfig-Ressource

Überblick

ClusterCIDRConfig ist eine benutzerdefinierte CIDR-Allocator-Ressource, mit der Sie weitere IP-Adressbereiche für Pods dynamisch zuweisen können.

IP-Adressverwaltung (IP Address Management, IPAM) ermöglicht eine effiziente Nutzung von IP-Subnetzen und vermeidet Überschneidungen in Adressbereichen, die Netzwerkkonflikte und -ausfälle verhindern. Kubernetes weist Pod-CIDRs pro Knoten zu, die als IP-Adressen für die Pods verwendet werden, die auf diesem Knoten ausgeführt werden.

Für das aktuelle Kubernetes NodeIPAM gelten folgende Einschränkungen:

• Alle Pod-CIDRs werden aus einem Cluster-CIDR zugewiesen. Sie müssen den gesamten IP-Adressbereich angeben, der den größten Cluster zum Zeitpunkt der Clustererstellung berücksichtigt. Durch diese Einschränkung können IP-Adressen verschwendet werden.

• Wenn Sie die Clustergröße erhöhen, ist es schwierig, weitere IP-Adressen hinzuzufügen.

• Der Cluster-CIDR ist ein großer Bereich. Es kann schwierig sein, einen zusammenhängenden Block von IP-Adressen zu finden, die die Anforderungen des Clusters erfüllen.

• Jeder Knoten erhält einen IP-Bereich mit fester Größe innerhalb eines Clusters. Wenn Knoten unterschiedliche Größen und Kapazitäten haben, können Sie einem bestimmten Knoten mit größerer Kapazität keinen größeren Pod-Bereich und Knoten mit geringerer Kapazität einen kleineren Bereich zuweisen. Dadurch werden viele IP-Adressen verschwendet. Bei einem großen Cluster mit vielen Knoten werden diese Verschwendung auf allen Knoten im Cluster verteilt.

Mit der Funktion ClusterCIDRConfig können Sie es vermeiden, einem Cluster einen großen CIDR-Block zuzuweisen, die Clustergröße der Skalierung Ihrer Pods zuzuordnen und so IP-Adressen beizubehalten. Sie können IP-Adressen speichern, indem Sie ClusterCIDRConfigs mit verschiedenen Kombinationen aus CIDR und perNodeMaskSize verwenden. Die ClusterCIDRConfig-Ressource unterstützt Folgendes:

• Mehrere nicht zusammenhängende IP-CIDR-Blöcke für Cluster-CIDR auf einer detaillierteren Ebene

• Knotenaffinität von CIDR-Blöcken

• Knoten unterschiedliche Blockgrößen zuweisen

Google Distributed Cloud verwendet die ClusterCIDRConfig-Funktionalität in den folgenden Funktionen:

• IPv4/IPv6-Dual-Stack-Netzwerk

• Flaches Netzwerkmodell im IPv4-Modus implementieren

• Flat-Mode-Netzwerkmodell mit BGP-Unterstützung implementieren

Cluster.spec.clusterNetwork.pods.cidrBlocks ist ein optionales Feld und nicht standardmäßig definiert. Sie müssen ihn definieren, wenn er für ein Element aus der vorherigen Liste nicht definiert ist. Er ist beispielsweise erforderlich, wenn die Cluster im IPv4-Inselmodus erstellt werden, und muss angegeben werden, da er als natives Routing-CIDR verwendet wird.

In der folgenden Tabelle ist die Verwendung des Feldverhaltens Cluster.spec.clusterNetwork.pods.cidrBlocks von ClusterCIDRConfig für verschiedene Netzwerkmodi aufgeführt.

Netzwerkmodus	ClusterCIDRConfig-Wert
IPv4-Insel (Standardeinstellung)	(Pflichtfeld) Geben Sie Cluster.spec.clusterNetwork.pods.cidrBlocks an.
IPv4 Flat (Standard)	Cluster.spec.clusterNetwork.pods.cidrBlocks werden vollständig ignoriert und können übersprungen werden. Nutzer müssen ClusterCIDRConfigs explizit definieren (pro Knoten, pro Knotenpool und/oder pro Cluster).
Dual-Stack (IPv4 Island, IPv4 Flat)	Geben Sie das IPv4-CIDR an. Geben Sie in Cluster.spec.clusterNetwork.pods.cidrBlocks kein IPv6-CIDR an. Geben Sie ClusterCIDRConfigs mit IPv4- und IPv6-CIDRs an. Die in allen ClusterCIDRConfigs konfigurierte IPv4-CIDR muss mit dem IPv4-CIDR aus Cluster.spec.clusterNetwork.pods.cidrBlocks identisch sein, einschließlich des PerNodeMask-Werts für IPv4. Weitere Informationen zu ClusterCIDRConfig und Beispiele zu seiner Verwendung finden Sie unter Beispiele: Dualstack (IPv4-Insel, IPv6 Flat)
Dual-Stack (Flat IPv4, Flat IPv6)	Sie können Cluster.spec.clusterNetwork.pods.cidrBlocks überspringen, da sie vollständig ignoriert werden. Sie müssen ClusterCIDRConfigs (pro Knoten, pro Knotenpool und/oder pro Cluster) explizit mit IPv4- und IPv6-CIDRs definieren.

Benutzerdefinierte CIDR-Allocator-Ressource ClusterCIDRConfig konfigurieren

ClusterCIDRConfig

Berücksichtigen Sie beim Konfigurieren der benutzerdefinierten CIDR-Zuteilungsressource ClusterCIDRConfig die folgenden Punkte:

• Die Pod-CIDR-Zuweisung von einer bestimmten ClusterCIDRConfig zu einem Knoten basiert auf Labelselektoren. Dies ähnelt dem nodeSelector-Mechanismus, der zum Planen von Pods auf einem Knoten verwendet wird.

• Sie müssen die ClusterCIDRConfig beim Erstellen des Clusters in der YAML-Datei für die Clusterkonfiguration konfigurieren. Nachdem Sie ClusterCIDRConfigs angegeben haben, können Sie die Werte später nicht mehr ändern.

• Sie können mehrere ClusterCIDRConfigs mit überlappenden CIDRs angeben.

• Wenn für einen Knoten keine passende ClusterCIDRConfig gefunden wird, bleibt der Knoten im Status NotReady, bis eine ClusterCIDRConfig mit passenden Labels erstellt wird.

• Wenn der am besten passenden ClusterCIDRConfig keine weiteren CIDRs für die Zuweisung zur Verfügung stehen, wird das nächstbeste CIDR ausgewählt und die Pod-CIDRs werden aus den verfügbaren CIDRs zugewiesen.

• Wenn Sie bei einem Dual-Stack-Modell Dual-Stack-Pod-CIDRs für die Knoten zuweisen möchten, gehen Sie so vor:

  • Konfigurieren Sie sowohl IPv4- als auch IPv6-CIDRs in ClusterCIDRConfig.

  • Achten Sie darauf, dass alle ClusterCIDRConfig DualStack CIDRs hat, wenn mehrere ClusterCIDRConfig konfiguriert sind.

  • Achten Sie darauf, dass sowohl die IPv4- als auch die IPv6-CIDRs die gleiche Anzahl von zuweisbaren IP-Adressen pro Knoten haben.

  Beispiel: 32 - spec.IPv4.PerNodeMaskSize == 128 - spec.IPv6.PerNodeMaskSize

  spec.IPv4.PerNodeMaskSize = 24

  spec.IPv6.PerNodeMaskSize = 120

  32 - 24 = 128 - 120, da die Differenz 8 ist.

• Mehrere ClusterCIDRConfigs können die Labels von nodeSelector mit Knotenlabels abgleichen.

ClusterCIDRConfig-Zuweisungsregeln

Um zu ermitteln, welche ClusterCIDRConfig verwendet wird, um dem aktuellen Knoten Pod-CIDRs zuzuweisen, verwenden Sie die folgenden Tiebreaker-Regeln. Implementieren Sie diese Regeln in der angegebenen Reihenfolge. Implementieren Sie die nächste Regel nur, wenn die vorherige Regel nicht gleichwertig ist.

1. Wählen Sie die ClusterCIDRConfig aus, deren NodeSelector mit den meisten Labels auf dem Knoten übereinstimmt. Beispiel: {'node.kubernetes.io/instance-type':'medium', 'rack': 'rack1'} (Match Count: 2) wird vor {'node.kubernetes.io/instance-type': 'medium'}. (Match Count: 1) ausgewählt.

2. Wählen Sie die ClusterCIDRConfig mit den wenigsten zuweisbaren Pod-CIDRs aus. Beispiel: {CIDR: "10.0.0.0/16", PerNodeMaskSize: "16"} (1 possible Pod CIDR) wird vor {CIDR: "192.168.0.0/20", PerNodeMaskSize: "22"} (4 possible Pod CIDRs) ausgewählt.

3. Wählen Sie die ClusterCIDRConfig aus, deren PerNodeMaskSize die wenigsten IP-Adressen hat. Beispiel: 27 (2^(32 - 27)= 32 IP-Adressen), die vor 25 ausgewählt wurden (2^(32 – 25)=128 IP-Adressen).

4. Wählen Sie die ClusterCIDRConfig aus, deren entsprechendes NodeSelector-Label einen niedrigeren alphanumerischen Wert hat. Beispielsweise wird {'kubernetes.io/hostname': 'node-1'} vor {'node.kubernetes.io/instance-type':'medium'} ausgewählt.

5. Wählen Sie die ClusterCIDRConfig aus, deren CIDR-IP-Adresse einen niedrigeren Wert hat. Unabhängig davon, ob die Konfiguration eine IPv4- oder DualStack-Konfiguration ist, werden nur die IPv4-CIDRs verglichen. Beispiel: {CIDR: "10.0.0.0/16"} is picked over {CIDR: "192.168.0.0/16"}.

Konfigurationsbeispiele

In diesem Abschnitt sind Konfigurationsbeispiele für Cluster und ClusterCIDRConfig für alle Netzwerkmodi aufgeführt.

Achtung :Verwenden Sie die hier aufgeführten Beispiele nicht. Ersetzen Sie die Adressbereiche durch Werte, die für Ihr Netzwerk geeignet sind.

Beispiele: IPv4-Inselmodus (Standardeinstellung)

Clusterkonfiguration (Standard)

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: bm-cluster
      namespace: cluster-default
    spec:
    ...
      clusterNetwork:
        # Pods specify the IP ranges from which pod networks are allocated.
        pods:
          cidrBlocks:
          - 192.168.0.0/16
        services:
          cidrBlocks:
          - 10.96.0.0/12

      ... (other cluster config omitted)
  

Beispiele: IPv4-Flachmodus

Clusterkonfiguration

  apiVersion: baremetal.cluster.gke.io/v1
  kind: Cluster
  metadata:
    name: bm-cluster
    namespace: cluster-default
  spec:
  ...
    clusterNetwork:
      flatIPv4: true
      services:
        cidrBlocks:
        - 10.96.0.0/12

    ... (other cluster config omitted)
  

ClusterCIDRConfig

Beispiel 1: ClusterCIDRConfig pro Knoten konfigurieren

    ---
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node1
      namespace: cluster-default    # Cluster namespace
    spec:
      ipv4:
        cidr: "222.1.0.0/24"
        perNodeMaskSize: 24
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-1
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node2
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.1.1.0/24"
        perNodeMaskSize: 24
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-2
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node3
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.1.2.0/24"
        perNodeMaskSize: 24
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-3

  

Beispiel 2: Beispiel für die Angabe einer Pod-CIDR für Knotenpools

Hinweis: Für die beiden flachen IP-Modi gelten unterschiedliche Einschränkungen:

• Für statische Flat IP (ohne BGP): Kann nur verwendet werden, wenn sich alle Knoten in derselben Layer-2-Domain befinden.
• Für Dynamic Flat IP (mit BGP): Kann auch dann verwendet werden, wenn die Knoten sich über mehrere Subdomains erstrecken.

    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: nodepool-wide-1
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.2.0.0/18"
        perNodeMaskSize: 24
      nodeSelector:
        matchLabels:
          baremetal.cluster.gke.io/node-pool: workers
  

Beispiel 3: Clusterweites PodCIDR konfigurieren – Kein nodeSelector konfiguriert

Hinweis: Für die beiden flachen IP-Modi gelten unterschiedliche Einschränkungen:

• Für statische Flat IP (ohne BGP): Kann nur verwendet werden, wenn sich alle Knoten in derselben Layer-2-Domain befinden.
• Für Dynamic Flat IP (mit BGP): Kann auch dann verwendet werden, wenn die Knoten sich über mehrere Subdomains erstrecken.

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

Beispiele: Dualstack (IPv4-Insel, IPv6 Flat)

Clusterkonfiguration

  apiVersion: baremetal.cluster.gke.io/v1
  kind: Cluster
  metadata:
    name: bm-cluster
    namespace: cluster-default
  spec:
  ...
    clusterNetwork:
      # Pods specify the IP ranges from which pod networks are allocated.
      pods:
        cidrBlocks:
        - 192.168.0.0/16
      services:
        cidrBlocks:
        - 10.96.0.0/12
        # Additional IPv6 cidrBlock, determines if the cluster is DualStack
        - 2620:0:1000:2630:5:2::/112

    ... (other cluster config omitted)
  

ClusterCIDRConfig

Beispiel 1: ClusterCIDRConfig pro Knoten konfigurieren

    ---
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node1
      namespace: cluster-default    # Cluster namespace
    spec:
      ipv4:
        cidr: "192.168.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:1::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-1
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node2
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "192.168.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:2::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-2
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node3
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "192.168.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-3
    

Beispiel 2: Beispiel für die Angabe einer Pod-CIDR für Knotenpools

Hinweis: Für die beiden flachen IP-Modi gelten unterschiedliche Einschränkungen:

• Für statische Flat IP (ohne BGP): Kann nur verwendet werden, wenn sich alle Knoten in derselben Layer-2-Domain befinden.
• Für Dynamic Flat IP (mit BGP): Kann auch dann verwendet werden, wenn die Knoten sich über mehrere Subdomains erstrecken.

    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: nodepool-wide-1
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "192.168.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/112"
        perNodeMaskSize: 118
      nodeSelector:
        matchLabels:
          baremetal.cluster.gke.io/node-pool: workers
    

Beispiel 3: Clusterweites PodCIDR konfigurieren – Kein nodeSelector konfiguriert

Hinweis: Für die beiden flachen IP-Modi gelten unterschiedliche Einschränkungen:

• Für statische Flat IP (ohne BGP): Kann nur verwendet werden, wenn sich alle Knoten in derselben Layer-2-Domain befinden.
• Für Dynamic Flat IP (mit BGP): Kann auch dann verwendet werden, wenn die Knoten sich über mehrere Subdomains erstrecken.

    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: cluster-wide-1
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "192.168.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/112"
        perNodeMaskSize: 120
    

Beispiele: Dualstack (IPv4 Flat, IPv6 Flat)

Clusterkonfiguration

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: bm-cluster
      namespace: cluster-default
    spec:
    ...
      clusterNetwork:
        flatIPv4: true
        services:
          cidrBlocks:
          - 10.96.0.0/12
          # Additional IPv6 cidrBlock, determines if the cluster is DualStack
          - 2620:0:1000:2630:5:2::/112

      ... (other cluster config omitted)
  

ClusterCIDRConfig

Beispiel 1: ClusterCIDRConfig pro Knoten konfigurieren

Hinweis: Für die beiden flachen IP-Modi gelten unterschiedliche Einschränkungen:

• Für statische Flat IP (ohne BGP): Kann nur verwendet werden, wenn sich alle Knoten in derselben Layer-2-Domain befinden.
• Für Dynamic Flat IP (mit BGP): Kann auch dann verwendet werden, wenn die Knoten sich über mehrere Subdomains erstrecken.

    ---
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node1
      namespace: cluster-default    # Cluster namespace
    spec:
      ipv4:
        cidr: "222.1.0.0/24"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:1::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-1
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node2
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.1.1.0/24"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:2::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-2
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node3
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.1.2.0/24"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-3
    

Beispiel 2: Beispiel für die Angabe einer Pod-CIDR für Knotenpools

Hinweis: Für die beiden flachen IP-Modi gelten unterschiedliche Einschränkungen:

• Für statische Flat IP (ohne BGP): Kann nur verwendet werden, wenn sich alle Knoten in derselben Layer-2-Domain befinden.
• Für Dynamic Flat IP (mit BGP): Kann auch dann verwendet werden, wenn die Knoten sich über mehrere Subdomains erstrecken.

    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: nodepool-wide-1
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.2.0.0/18"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/112"
        perNodeMaskSize: 118
      nodeSelector:
        matchLabels:
          baremetal.cluster.gke.io/node-pool: workers
    

Beispiel 3: Clusterweites PodCIDR konfigurieren – Kein nodeSelector konfiguriert

    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: cluster-wide-1
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.3.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/112"
        perNodeMaskSize: 120