Benutzerdefinierte Ressource „ClusterCIDRConfig“

Überblick

ClusterCIDRConfig ist eine benutzerdefinierte CIDR-Zuweisungsressource, mit der Sie Pods dynamisch weitere IP‑Adressbereiche zuweisen können.

Die IP-Adressverwaltung (IP Address Management, IPAM) ermöglicht eine effiziente Nutzung von IP-Subnetzen und hilft, Überlappungen in Adressbereichen zu vermeiden. Dies begrenzt letztlich auch Netzwerkkonflikte und -ausfälle. 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 die aktuelle Kubernetes-NodeIPAM-Version gelten die folgenden Einschränkungen:

• Alle Pod-CIDRs werden aus einem Cluster-CIDR zugewiesen. Sie müssen den gesamten IP-Adressbereich angeben, der dem größten Cluster zum Zeitpunkt der Clustererstellung entspricht. Diese Einschränkung kann zu einer Verschwendung von IP-Adressen führen.

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

• Der CIDR-Bereich des Clusters ist ein großer Bereich. Es kann schwierig sein, einen zusammenhängenden Block von IP-Adressen zu finden, der den Anforderungen des Clusters entspricht.

• Jeder Knoten erhält innerhalb eines Clusters einen IP-Bereich mit fester Größe. 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 keinen kleineren Bereich zuweisen. Das ist eine Verschwendung von vielen IP-Adressen. Bei einem großen Cluster mit vielen Knoten wird dieser Verschwendung auf alle Knoten im Cluster verteilt.

Mit der ClusterCIDRConfig-Funktion können Sie vermeiden, einem Cluster einen großen CIDR-Block zuzuweisen, können die Clustergröße an den Umfang Ihrer Pods anpassen und so IP-Adressen aufsparen. Sie können IP-Adressen aufsparen, 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, die Knoten zugewiesen sind

In Google Distributed Cloud wird die ClusterCIDRConfig-Funktion in den folgenden Funktionen verwendet:

• IPv4/IPv6-Dual-Stack-Netzwerk

• Netzwerkmodell im flachen IPv4-Modus implementieren

• Netzwerkmodell im flachen Modus mit BGP-Unterstützung implementieren

Cluster.spec.clusterNetwork.pods.cidrBlocks ist ein optionales Feld und wird standardmäßig nicht definiert. Sie müssen es definieren, wenn es für eine der Funktionen in der Liste oben nicht definiert ist. Es ist beispielsweise erforderlich, wenn die Cluster im IPv4-Inselmodus erstellt werden. Es muss dann außerdem angegeben werden, da es als nativer Routing-CIDR verwendet wird.

In der folgenden Tabelle wird das Verwenden des Verhaltens des Felds Cluster.spec.clusterNetwork.pods.cidrBlocks von ClusterCIDRConfig für verschiedene Netzwerkmodi aufgeführt.

Netzwerkmodus:	ClusterCIDRConfig-Wert
IPv4-Insel (Standard)	(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-Insel, IPv4-Flat)	Geben Sie das IPv4-CIDR an. Geben Sie unter Cluster.spec.clusterNetwork.pods.cidrBlocks keinen IPv6-CIDR-Bereich an. Geben Sie ClusterCIDRConfigs mit sowohl IPv4- als auch IPv6-CIDRs an. Das in allen ClusterCIDRConfigs konfigurierte IPv4-CIDR muss mit dem IPv4-CIDR aus Cluster.spec.clusterNetwork.pods.cidrBlocks übereinstimmen, einschließlich des PerNodeMask-Werts für IPv4. Weitere Informationen zu ClusterCIDRConfig und Beispiele für die Verwendung finden Sie unter Beispiele: Dual-Stack (IPv4-Insel, IPv6-Flat).
Dual-Stack (flacher IPv4-, flacher IPv6)	Sie können Cluster.spec.clusterNetwork.pods.cidrBlocks überspringen, da diese vollständig ignoriert werden. Sie müssen ClusterCIDRConfigs (pro Knoten, pro Knotenpool und/oder pro Cluster) sowohl mit IPv4- als auch mit IPv6-CIDRs explizit definieren.

Benutzerdefinierte CIDR-Zuweisungsressource „ClusterCIDRConfig“ konfigurieren

ClusterCIDRConfig

Beachten Sie beim Konfigurieren der benutzerdefinierten CIDR-Zuweisungsressource „ClusterCIDRConfig“ Folgendes:

• Die Pod-CIDR-Zuweisung von einer bestimmten ClusterCIDRConfig an einen Knoten basiert auf Label-Selectoren. Das ähnelt dem nodeSelector-Mechanismus, der zum Planen von Pods auf einem Knoten verwendet wird.

• Sie müssen ClusterCIDRConfig während der Clustererstellung in der YAML-Datei für die Clusterkonfiguration konfigurieren. Nachdem Sie ClusterCIDRConfigs angegeben haben, können Sie die Werte nicht mehr ändern.

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

• Wenn für einen Knoten keine übereinstimmende ClusterCIDRConfig gefunden wird, bleibt der Knoten im Status „Nicht bereit“, bis eine ClusterCIDRConfig mit übereinstimmenden Labels erstellt wird.

• Wenn in der ClusterCIDRConfig mit der besten Übereinstimmung keine weiteren CIDRs für die Zuordnung verfügbar sind, wird das nächste beste CIDR ausgewählt und die Pod-CIDRs werden aus den verfügbaren CIDRs zugewiesen.

• Wenn Sie den Knoten im Dual-Stack-Modell Dual-Stack-Pod-CIDRS zuweisen möchten, gehen Sie so vor:

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

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

  • Achten Sie darauf, dass sowohl IPv4- als auch IPv6-CIDRs dieselbe 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 gilt: 32 – 24 = 128 – 120, da die Differenz 8 beträgt.

• Mehrere ClusterCIDRConfigs können die Labels aus dem NodeSelector mit Knotenlabels abgleichen.

Zuweisungsregeln für ClusterCIDRConfig

Mit den folgenden Regeln zum Tie-Breaking können Sie ermitteln, welche ClusterCIDRConfig verwendet wird, um dem aktuellen Knoten Pod-CIDRs zuzuweisen. Implementieren Sie diese Regeln in der angegebenen Reihenfolge. Implementieren Sie die nächste Regel nur, wenn der Gleichstand nicht durch die vorherige Regel aufgelöst wird.

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) wird vor 25 (2^(32-25) = 128 IP-Adressen) gewählt

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

5. Wählen Sie die ClusterCIDRConfig aus, deren CIDR-IP einen niedrigeren Wert hat. Unabhängig davon, ob es sich um eine IPv4- oder eine Dual-Stack-Konfiguration handelt, 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 diese 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 (Standard)

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

Cluster Config

  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 eines knotenpoolweiten Pod-CIDR

Hinweis: Die beiden Flat-IP-Modi haben 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 dynamische 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 konfiguriert

Hinweis: Die beiden Flat-IP-Modi haben 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 dynamische 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: Dual-Stack (IPv4-Insel, IPv6-Flat)

Cluster Config

  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 eines knotenpoolweiten Pod-CIDR

Hinweis: Die beiden Flat-IP-Modi haben 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 dynamische 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 konfiguriert

Hinweis: Die beiden Flat-IP-Modi haben 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 dynamische 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: Dual-Stack (IPv4 Flat, IPv6 Flat)

Cluster Config

    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 Flat-IP-Modi haben 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 dynamische 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 für die Angabe eines knotenpoolweiten Pod-CIDR

Hinweis: Die beiden Flat-IP-Modi haben 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 dynamische 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 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