Informationen zur benutzerdefinierten Ressource „ClusterCIDRConfig“

Version 1.16 

• Neueste
• Version 1.16
• Frühere Versionen (nicht unterstützt)

Überblick

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

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

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

• Alle Pod-CIDRs werden von 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-Bereich ist ein großer Bereich. Es kann schwierig sein, einen zusammenhängenden Block von IP-Adressen zu finden, der die Anforderungen des Clusters erfüllt.

• 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 vermehrt sich dieser Verschwendung auf allen Knoten im Cluster.

Mit der ClusterCIDRConfig-Funktion können Sie die Zuweisung eines großen CIDR-Blocks zu einem Cluster vermeiden, die Clustergröße der Größe Ihrer Pods zuordnen und so IP-Adressen beibehalten. Sie können IP-Adressen speichern, indem Sie ClusterCIDRConfigs mit verschiedenen Kombinationen von 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

• Unterschiedliche Blockgrößen den Knoten zugewiesen

GKE on Bare Metal verwendet die ClusterCIDRConfig-Funktionalität in den folgenden Features:

• IPv4/IPv6-Dual-Stack-Netzwerk

• Flat-IPv4-Netzwerkmodell 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 sie definieren, wenn sie in einem der Features 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 wird 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-Flach (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 nicht das IPv6-CIDR an. Geben Sie ClusterCIDRConfigs sowohl mit IPv4- als auch mit IPv6-CIDRs an. Das in allen ClusterCIDRConfigs konfigurierte IPv4-CIDR muss mit dem IPv4-CIDR-Bereich von Cluster.spec.clusterNetwork.pods.cidrBlocks übereinstimmen, einschließlich des Werts „PerNodeMask“ für IPv4. Weitere Informationen zu ClusterCIDRConfig und Beispiele für die Verwendung finden Sie unter Beispiele: Dualstack (IPv4 Island, IPv6 Flat)
Dual-Stack (flacher IPv4, flaches IPv6)	Sie können „Cluster.spec.clusterNetwork.pods.cidrBlocks“ überspringen, da diese Angaben vollständig ignoriert werden. Sie müssen ClusterCIDRConfigs (pro Knoten, pro Knotenpool und/oder pro Cluster) explizit mit IPv4- und IPv6-CIDRs definieren.

Benutzerdefinierte CIDRConfig-Ressource vom Typ ClusterCIDRConfig konfigurieren

ClusterCIDRConfig

Beachten Sie beim Konfigurieren der benutzerdefinierten CIDRConfig-Ressource „ClusterCIDRConfig“ die folgenden Punkte:

• Die Pod-CIDR-Zuweisung von einer bestimmten ClusterCIDRConfig zu einem Knoten basiert auf der Labelauswahl. 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 entsprechende ClusterCIDRConfig gefunden wird, behält dieser den Status „NotReady“ bei, bis eine ClusterCIDRConfig mit übereinstimmenden Labels erstellt wird.

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

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

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

  • Wenn mehrere ClusterCIDRConfig konfiguriert sind, müssen alle ClusterCIDRConfigs DualStack-CIDRs haben.

  • Achten Sie darauf, dass sowohl die konfigurierten 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

  Daher ist 32 - 24 == 128 - 120, da die Differenz 8 beträgt.

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

ClusterCIDRConfig-Zuweisungsregeln

Mit den folgenden Regeln für Tiebreaking ermitteln Sie, welche ClusterCIDRConfig zum Zuweisen von Pod-CIDRs zum aktuellen Knoten verwendet wird. Implementieren Sie diese Regeln in der angegebenen Reihenfolge. Implementieren Sie die nächste Regel nur, wenn die vorherige Regel nicht gegen sie verstößt.

1. Wählen Sie die ClusterCIDRConfig aus, deren NodeSelector mit den meisten Labels im Knoten übereinstimmt. Beispielsweise wird {'node.kubernetes.io/instance-type':'medium', 'rack': 'rack1'} (Match Count: 2) 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. Beispielsweise wird {CIDR: "10.0.0.0/16", PerNodeMaskSize: "16"} (1 possible Pod CIDR) 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) wird vor 25 (2^(32-25)=128 IP-Adressen) ausgewählt.

4. Wählen Sie die ClusterCIDRConfig aus, deren entsprechendes NodeSelector-Label einen niedrigeren alphanumerischen Wert hat. Beispielsweise wird {'kubernetes.io/hostname': 'node-1'} statt {'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 eine 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 finden Sie Konfigurationsbeispiele für Cluster und ClusterCIDRConfig für alle Netzwerkmodi.

Achtung :Verwenden Sie die Beispiele nicht so, wie sie hier aufgeführt sind. 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-Flat Mode

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 zum Angeben eines Knotenpool-weiten Pod-CIDR

Hinweis: Die beiden flachen IP-Modi haben unterschiedliche Einschränkungen:

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

    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 ist konfiguriert

Hinweis: Die beiden flachen IP-Modi haben unterschiedliche Einschränkungen:

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

    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 Island, 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 zum Angeben eines Knotenpool-weiten Pod-CIDR

Hinweis: Die beiden flachen IP-Modi haben unterschiedliche Einschränkungen:

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

    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 ist konfiguriert

Hinweis: Die beiden flachen IP-Modi haben unterschiedliche Einschränkungen:

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

    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: Die beiden flachen IP-Modi haben unterschiedliche Einschränkungen:

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

    ---
    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 zum Angeben eines Knotenpool-weiten Pod-CIDR

Hinweis: Die beiden flachen IP-Modi haben unterschiedliche Einschränkungen:

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

    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 ist 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