Benutzerdefinierte Ressource „ClusterCIDRConfig“

Übersicht

ClusterCIDRConfig ist eine benutzerdefinierte CIDR-Zuweisungsressource, mit der Sie dynamisch weitere IP-Adressbereiche für Pods 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 jedem Knoten Pod-CIDRs zu, die als IP-Adressen für die Pods verwendet werden, die auf diesem Knoten ausgeführt werden.

Für die aktuelle Kubernetes-NodeIPAM gelten die folgenden Einschränkungen:

• Alle Pod-CIDRs werden aus einem Cluster-CIDR zugewiesen. Sie müssen den gesamten IP-Adressbereich für den größten Cluster zum Zeitpunkt der Clustererstellung angeben. 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 Cluster-CIDR 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 einen IP-Bereich mit fester Größe innerhalb eines Clusters. Wenn Knoten unterschiedliche Größen und Kapazitäten haben, können Sie einem 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

• Knoten werden unterschiedliche Blockgrößen zugewiesen

Google Distributed Cloud verwendet die ClusterCIDRConfig-Funktion in den folgenden Features:

• IPv4/IPv6-Dual-Stack-Netzwerk

• Flaches IPv4-Netzwerkmodell 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 (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-Insel, flacher IPv4)	Geben Sie die IPv4-CIDR an. Geben Sie in Cluster.spec.clusterNetwork.pods.cidrBlocks keinen IPv6-CIDR-Bereich an. Geben Sie ClusterCIDRConfigs mit IPv4- und IPv6-CIDRs an. Der 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 sie vollständig ignoriert werden. Sie müssen ClusterCIDRConfigs (pro Knoten, pro Knotenpool und/oder pro Cluster) mit sowohl IPv4- als auch IPv6-CIDRs explizit definieren.

Benutzerdefinierte Ressource „ClusterCIDRConfig“ für die benutzerdefinierte CIDR-Zuweisung 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. Dies ähnelt dem nodeSelector-Mechanismus, der zum Planen von Pods auf einem Knoten verwendet wird.

• Sie müssen die ClusterCIDRConfig während der Clustererstellung 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 sich überschneidenden 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 für die ClusterCIDRConfig mit der besten Übereinstimmung keine weiteren CIDRs für die Zuweisung verfügbar sind, wird die nächstbeste CIDR ausgewählt und die Pod-CIDRs werden aus den verfügbaren CIDRs zugewiesen.

• Wenn Sie im Fall eines Dual-Stack-Modells den Knoten 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 die konfigurierten IPv4- als auch die IPv6-CIDRs die gleiche Anzahl an 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 ist.

• Mehrere ClusterCIDRConfigs können mit den Labels aus dem nodeSelector mit Knotenlabels übereinstimmen.

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. Wenden Sie die nächste Regel nur an, wenn die vorherige Regel nicht zu einer Entscheidung geführt hat.

1. Wählen Sie die ClusterCIDRConfig aus, deren NodeSelector die meisten Labels auf dem Knoten enthält. 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 {'node.kubernetes.io/instance-type':'medium'} vorgezogen.

5. Wählen Sie die ClusterCIDRConfig aus, deren CIDR-IP einen niedrigeren Wert hat. Unabhängig davon, ob es sich bei der Konfiguration um eine IPv4- oder eine DualStack-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: Flacher IPv4-Modus

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 NodePool-weiten PodCIDR

Hinweis:Für die beiden Flat-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 dynamische Flat-IP (mit BGP): Kann auch verwendet werden, wenn sich die Knoten ü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: PodCIDR für den gesamten Cluster konfigurieren – kein nodeSelector konfiguriert

Hinweis:Für die beiden Flat-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 dynamische Flat-IP (mit BGP): Kann auch verwendet werden, wenn sich die Knoten ü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: Dual-Stack (IPv4 Island, 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 NodePool-weiten PodCIDR

Hinweis:Für die beiden Flat-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 dynamische Flat-IP (mit BGP): Kann auch verwendet werden, wenn sich die Knoten ü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: PodCIDR für den gesamten Cluster konfigurieren – kein nodeSelector konfiguriert

Hinweis:Für die beiden Flat-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 dynamische Flat-IP (mit BGP): Kann auch verwendet werden, wenn sich die Knoten ü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: Dual-Stack (flacher IPv4, flacher IPv6)

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:Für die beiden Flat-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 dynamische Flat-IP (mit BGP): Kann auch verwendet werden, wenn sich die Knoten ü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 eines NodePool-weiten PodCIDR

Hinweis:Für die beiden Flat-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 dynamische Flat-IP (mit BGP): Kann auch verwendet werden, wenn sich die Knoten ü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: PodCIDR für den gesamten Cluster 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