Informazioni sulla risorsa personalizzata ClusterCIDRConfig

Version 1.15 

• Più recente
• Versione 1.16
• Versioni precedenti (non supportate)

Panoramica

ClusterCIDRConfig è una risorsa di allocatore CIDR personalizzata che consente di allocare più intervalli di indirizzi IP per i pod in modo dinamico.

La gestione degli indirizzi IP (IPAM) consente un uso efficiente delle subnet IP ed evita sovrapposizioni negli intervalli di indirizzi, evitando così conflitti di rete e interruzioni di rete. Kubernetes assegna CIDR pod per nodo, utilizzati come indirizzi IP per i pod in esecuzione su quel nodo.

L'attuale NodeIPAM di Kubernetes ha le seguenti limitazioni:

• Tutti i CIDR dei pod sono allocati da un CIDR del cluster. Devi specificare l'intero intervallo di indirizzi IP, che rappresenta il cluster più grande al momento della creazione del cluster. Questa limitazione può causare lo spreco di indirizzi IP.

• Se aumenti le dimensioni del cluster, è difficile aggiungere altri indirizzi IP.

• Il CIDR del cluster è un intervallo ampio. Potrebbe essere difficile trovare un blocco contiguo di indirizzi IP che soddisfi le esigenze del cluster.

• Ogni nodo riceve un intervallo IP a dimensione fissa all'interno di un cluster. Se i nodi hanno dimensioni e capacità diverse, non puoi allocare un intervallo di pod più ampio a un determinato nodo con capacità maggiore e un intervallo più ridotto ai nodi con capacità minore. Questo comporta uno spreco di molti indirizzi IP. Per un cluster di grandi dimensioni con molti nodi, questi rifiuti vengono aggravati in tutti i nodi del cluster.

Con la funzionalità ClusterCIDRConfig, puoi evitare di assegnare un blocco CIDR di grandi dimensioni a un cluster, mappare le dimensioni del cluster alla scala dei pod e, di conseguenza, preservare gli indirizzi IP. Puoi salvare gli indirizzi IP utilizzando ClusterCIDRConfigs con diverse combinazioni di CIDR e perNodeMaskSize. La risorsa ClusterCIDRConfig supporta quanto segue:

• Più blocchi CIDR IP discontinui per il CIDR del cluster a un livello più granulare

• Affinità nodo dei blocchi CIDR

• Diverse dimensioni dei blocchi allocate ai nodi

GKE su Bare Metal utilizza la funzionalità ClusterCIDRConfig nelle seguenti funzionalità:

• Networking IPv4/IPv6 dual stack

• Implementare un modello di rete in modalità IPv4 semplice

• Implementare il modello di rete in modalità flat con supporto BGP

Cluster.spec.clusterNetwork.pods.cidrBlocks è un campo facoltativo e non è definito per impostazione predefinita. Devi definirlo se non è stato definito per una delle caratteristiche dell'elenco precedente. Ad esempio, è obbligatorio quando i cluster vengono creati in modalità isola IPv4 e deve essere specificato in quanto viene utilizzato come CIDR di routing nativo.

La seguente tabella elenca l'utilizzo del comportamento del campo Cluster.spec.clusterNetwork.pods.cidrBlocks di ClusterCIDRConfig per diverse modalità di rete.

Modalità di rete	Valore ClusterCIDRConfig
Isola IPv4 (predefinita)	(Campo obbligatorio) Specifica Cluster.spec.clusterNetwork.pods.cidrBlocks.
IPv4 stabile (impostazione predefinita)	Cluster.spec.clusterNetwork.pods.cidrBlocks vengono completamente ignorati e possono essere ignorati. Gli utenti devono definire esplicitamente ClusterCIDRConfig (per nodo, per pool di nodi e/o per cluster).
Doppio stack (isola IPv4, piano IPv4)	Specifica il CIDR IPv4. Non specificare il CIDR IPv6 in Cluster.spec.clusterNetwork.pods.cidrBlocks. Specifica i ClusterCIDRConfig con CIDR IPv4 e IPv6. Il CIDR IPv4 configurato in tutti i ClusterCIDRConfig deve essere lo stesso del CIDR IPv4 di Cluster.spec.clusterNetwork.pods.cidrBlocks, incluso il valore PerNodeMask per IPv4. Per ulteriori informazioni su ClusterCIDRConfig ed esempi sul suo utilizzo, consulta Esempi: Dualstack (isola IPv4, IPv6 Flat)
Dual-stack (IPv4 fisso, IPv6 piatto)	Puoi saltare Cluster.spec.clusterNetwork.pods.cidrBlocks perché vengono ignorati del tutto. Devi definire esplicitamente ClusterCIDRConfig (per nodo, per pool di nodi e/o per cluster) con CIDR IPv4 e IPv6.

Configurazione della risorsa allocatore CIDR personalizzato di ClusterCIDRConfig

ClusterCIDRConfig

Quando configuri la risorsa allocatore CIDR personalizzato ClusterCIDRConfig, considera i seguenti punti:

• L'assegnazione CIDR di un pod da un determinato ClusterCIDRConfig a un nodo si basa sui selettori di etichette. È simile al meccanismo nodeSelector utilizzato per pianificare i pod su un nodo.

• Devi configurare ClusterCIDRConfig durante il processo di creazione del cluster nel file YAML di configurazione del cluster. Dopo aver specificato ClusterCIDRConfigs, non puoi modificare i valori in un secondo momento.

• Puoi specificare più ClusterCIDRConfig con CIDR sovrapposti.

• Se per un nodo non viene trovato alcun ClusterCIDRConfig corrispondente, quest'ultimo rimane in stato NotReady fino a quando non viene creato un ClusterCIDRConfig con etichette corrispondenti.

• Se la corrispondenza migliore per ClusterCIDRConfig non ha più CIDR disponibili per l'allocazione, viene scelto il CIDR migliore successivo e i CIDR dei pod vengono allocati dai CIDR disponibili.

• Nel caso del modello a due stack, se vuoi assegnare CIDR dei pod a doppio stack ai nodi:

  • Configura i CIDR IPv4 e IPv6 in ClusterCIDRConfig.

  • Assicurati che tutti i ClusterCIDRConfig abbiano CIDR DualStack, se sono configurati più ClusterCIDRConfig.

  • Assicurati che entrambi i CIDR IPv4 e IPv6 configurati abbiano un numero uguale di indirizzi IP allocabili per nodo.

  Ad esempio, 32 - spec.IPv4.PerNodeMaskSize == 128 - spec.IPv6.PerNodeMaskSize

  spec.IPv4.PerNodeMaskSize = 24

  spec.IPv6.PerNodeMaskSize = 120

  Pertanto, 32 - 24 == 128 - 120, poiché la differenza è 8.

• Più ClusterCIDRConfig possono far corrispondere le etichette di nodeSelector alle etichette dei nodi.

Regole di assegnazione ClusterCIDRConfig

Per determinare quale ClusterCIDRConfig viene utilizzato per assegnare CIDR dei pod al nodo attuale, utilizza le seguenti regole di tie-break. Implementa queste regole nell'ordine specificato. Implementa la regola successiva solo se la parità non viene rotta dalla regola precedente.

1. Scegli il ClusterCIDRConfig il cui NodeSelector corrisponda al maggior numero di etichette nel nodo. Ad esempio, {'node.kubernetes.io/instance-type':'medium', 'rack': 'rack1'} (Match Count: 2) viene selezionato prima del giorno {'node.kubernetes.io/instance-type': 'medium'}. (Match Count: 1).

2. Scegli il ClusterCIDRConfig con il numero minimo di CIDR pod allocabili. Ad esempio, {CIDR: "10.0.0.0/16", PerNodeMaskSize: "16"} (1 possible Pod CIDR) viene selezionato prima del giorno {CIDR: "192.168.0.0/20", PerNodeMaskSize: "22"} (4 possible Pod CIDRs).

3. Scegli il ClusterCIDRConfig il cui PerNodeMaskSize ha il minor numero di indirizzi IP. Ad esempio, 27 (2^(32-27)= 32 indirizzi IP) scelti prima di 25 (2^(32-25)=128 indirizzi IP).

4. Scegli il ClusterCIDRConfig la cui etichetta NodeSelector corrispondente ha un valore alfanumerico inferiore. Ad esempio, {'kubernetes.io/hostname': 'node-1'} è scelto su {'node.kubernetes.io/instance-type':'medium'}.

5. Scegli il ClusterCIDRConfig il cui IP CIDR ha un valore inferiore. Indipendentemente dal fatto che la configurazione sia una configurazione IPv4 o una configurazione DualStack, vengono confrontati solo i CIDR IPv4. Ad esempio, {CIDR: "10.0.0.0/16"} is picked over {CIDR: "192.168.0.0/16"}.

Esempi di configurazione

In questa sezione sono elencati esempi di configurazione per Cluster e ClusterCIDRConfig per tutte le modalità di networking.

Attenzione: non utilizzare questi esempi come appaiono qui. Sostituisci gli intervalli di indirizzi con i valori appropriati per la tua rete.

Esempi: modalità isola IPv4 (predefinita)

Configurazione cluster (predefinita)

    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)
  

Esempi: modalità flat IPv4

Configurazione cluster

  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

Esempio 1: configurazione per nodo ClusterCIDRConfig

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

  

Esempio 2: esempio di specifica di un PodCIDR a livello di pool di nodi

Nota: le due modalità IP fisse hanno vincoli diversi:

• Per IP fisso statico (senza BGP): può essere utilizzato solo se tutti i nodi si trovano nello stesso dominio di livello 2.
• Per IP piatto dinamico (con BGP): può essere utilizzato anche quando i nodi comprendono più sottodomini.

    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
  

Esempio 3: configurazione di un PodCIDR a livello di cluster - non è configurato alcun nodeSelector

Nota: le due modalità IP fisse hanno vincoli diversi:

• Per IP fisso statico (senza BGP): può essere utilizzato solo se tutti i nodi si trovano nello stesso dominio di livello 2.
• Per IP piatto dinamico (con BGP): può essere utilizzato anche quando i nodi comprendono più sottodomini.

    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
  

Esempi: Dualstack (isola IPv4, IPv6 piatto)

Configurazione cluster

  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

Esempio 1: configurazione per nodo ClusterCIDRConfig

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

Esempio 2: esempio di specifica di un PodCIDR a livello di pool di nodi

Nota: le due modalità IP fisse hanno vincoli diversi:

• Per IP fisso statico (senza BGP): può essere utilizzato solo se tutti i nodi si trovano nello stesso dominio di livello 2.
• Per IP piatto dinamico (con BGP): può essere utilizzato anche quando i nodi comprendono più sottodomini.

    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
    

Esempio 3: configurazione di un PodCIDR a livello di cluster - non è configurato alcun nodeSelector

Nota: le due modalità IP fisse hanno vincoli diversi:

• Per IP fisso statico (senza BGP): può essere utilizzato solo se tutti i nodi si trovano nello stesso dominio di livello 2.
• Per IP piatto dinamico (con BGP): può essere utilizzato anche quando i nodi comprendono più sottodomini.

    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
    

Esempi: Dualstack (IPv4 Flat, IPv6 Flat)

Configurazione cluster

    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

Esempio 1: configurazione per nodo ClusterCIDRConfig

Nota: le due modalità IP fisse hanno vincoli diversi:

• Per IP fisso statico (senza BGP): può essere utilizzato solo se tutti i nodi si trovano nello stesso dominio di livello 2.
• Per IP piatto dinamico (con BGP): può essere utilizzato anche quando i nodi comprendono più sottodomini.

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

Esempio 2: esempio di specifica di un PodCIDR a livello di pool di nodi

Nota: le due modalità IP fisse hanno vincoli diversi:

• Per IP fisso statico (senza BGP): può essere utilizzato solo se tutti i nodi si trovano nello stesso dominio di livello 2.
• Per IP piatto dinamico (con BGP): può essere utilizzato anche quando i nodi comprendono più sottodomini.

    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
    

Esempio 3: configurazione di un PodCIDR a livello di cluster - non è configurato alcun nodeSelector

    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