Comprendi la risorsa personalizzata ClusterCIDRConfig

Panoramica

ClusterCIDRConfig è una risorsa di allocatore CIDR personalizzato che consente di allocano 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 avere sovrapposizioni negli intervalli di indirizzi, evitando così conflitti di rete e interruzioni del servizio. Kubernetes assegna i CIDR dei pod per nodo, che vengono 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 rappresentando il cluster più grande al momento per la creazione del cluster. Questo limite può causare lo spreco di indirizzi IP.

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

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

• Ogni nodo riceve un intervallo IP di dimensioni fisse all'interno di un cluster. Se i nodi sono di dimensioni e capacità diverse, non puoi allocare un intervallo di pod più ampio un dato nodo con una capacità maggiore e un intervallo più piccolo di nodi con minore e la capacità di archiviazione. Questo fa sprecare molti indirizzi IP. Per un cluster di grandi dimensioni con molti nodi, questo spreco si aggrava in tutti i nodi del cluster.

Con la funzionalità ClusterCIDRConfig, puoi evitare di assegnare un blocco CIDR di grandi dimensioni a un cluster, mappa le dimensioni del cluster alla scalabilità dei tuoi pod e conservare gli indirizzi IP. Puoi salvare gli indirizzi IP utilizzando ClusterCIDRConfigs con diverse combinazioni di CIDR e perNodeMaskSize. ClusterCIDRConfig supporta quanto segue:

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

• Affinità nodo dei blocchi CIDR

• Dimensioni dei blocchi diverse allocate ai nodi

Google Distributed Cloud utilizza la funzionalità ClusterCIDRConfig nelle seguenti funzionalità:

• Networking a doppio stack IPv4/IPv6

• Implementare un modello di rete in modalità IPv4 flat

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

Cluster.spec.clusterNetwork.pods.cidrBlocks è un campo facoltativo e non è per impostazione predefinita. Devi definirla se una qualsiasi delle caratteristiche nella precedente non lo ha definito nell'elenco. Ad esempio, è obbligatorio quando i cluster creati in modalità isola IPv4 e devono essere specificati perché vengono utilizzati come server CIDR di routing.

La tabella seguente elenca l'uso di ClusterCIDRConfig Comportamento del campo Cluster.spec.clusterNetwork.pods.cidrBlocks per un altro modalità di rete.

Modalità rete	Valore ClusterCIDRConfig
Isola IPv4 (predefinita)	(Campo obbligatorio) Specifica Cluster.spec.clusterNetwork.pods.cidrBlocks.
IPv4 piatto (predefinito)	Cluster.spec.clusterNetwork.pods.cidrBlocks vengono completamente ignorati e possono essere ignorati. Gli utenti devono definire esplicitamente ClusterCIDRConfigs (per nodo, per pool di nodi e/o per cluster).
Dual stack (isola IPv4, IPv4 piatto)	Specifica il CIDR IPv4. Non specificare CIDR IPv6 in Cluster.spec.clusterNetwork.pods.cidrBlocks. Specifica ClusterCIDRConfigs con CIDR IPv4 e IPv6. Il CIDR IPv4 configurato in tutti i ClusterCIDRConfigs deve essere uguale al CIDR IPv4 di Cluster.spec.clusterNetwork.pods.cidrBlocks, incluso il valore PerNodeMask per IPv4. Per ulteriori informazioni su ClusterCIDRConfig ed esempi su come utilizzarlo, consulta Esempi: Dualstack (isola IPv4, IPv6 Flat)
Dual stack (IPv4 piatto, IPv6 piatto)	Puoi saltare Cluster.spec.clusterNetwork.pods.cidrBlocks perché vengono completamente ignorati. Devi definire in modo esplicito i ClusterCIDRConfig (per nodo, per pool di nodi e/o per cluster) con CIDR IPv4 e IPv6.

Configurazione della risorsa allocatore CIDR personalizzato ClusterCIDRConfig

ClusterCIDRConfig

Quando configuri la risorsa allocatore CIDR personalizzata ClusterCIDRConfig, tieni in considerazione i seguenti punti:

• L'assegnazione CIDR dei pod da un determinato ClusterCIDRConfig a un nodo è basata sui selettori delle etichette. È simile al meccanismo nodeSelector utilizzato per pianificazione dei pod su un nodo.

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

• Puoi specificare più ClusterCIDRConfig con CIDR sovrapposti.

• Se non viene trovata alcuna ClusterCIDRConfig corrispondente per un nodo, il nodo rimane in un Stato NotReady, fino a quando non viene creato un ClusterCIDRConfig con etichette corrispondenti.

• Se la corrispondenza migliore ClusterCIDRConfig non ha altri CIDR disponibili per viene scelto il CIDR successivo migliore e vengono allocati i CIDR dei pod dai CIDR disponibili.

• Nel caso del modello a doppio 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 più ClusterCIDRConfig è configurato.

  • Assicurati che 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

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

• Più ClusterCIDRConfigs può abbinare le etichette di nodeSelector a delle etichette dei nodi.

Regole di assegnazione ClusterCIDRConfig

per determinare quale ClusterCIDRConfig viene utilizzato per assegnare i CIDR dei pod all'attuale utilizza le seguenti regole di tie-breaking. Implementare queste regole nel ordine. Implementa la regola successiva solo se il legame non è rotto dalla precedente personalizzata.

1. Scegli il ClusterCIDRConfig il cui NodeSelector corrisponde alla maggior parte delle etichette sulla Nodo. Ad esempio, {'node.kubernetes.io/instance-type':'medium', 'rack': 'rack1'} (Match Count: 2) viene scelto prima {'node.kubernetes.io/instance-type': 'medium'}. (Match Count: 1).

2. Scegli il ClusterCIDRConfig con il minor numero di CIDR dei pod allocabili. Per esempio, {CIDR: "10.0.0.0/16", PerNodeMaskSize: "16"} (1 possible Pod CIDR) viene selezionato prima di {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) selezionati prima 25 (2^(32-25)=128 indirizzi IP).

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

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

Esempi di configurazione

Questa sezione elenca esempi di configurazione per Cluster e ClusterCIDRConfig per per tutte le modalità di networking.

Attenzione :non utilizzare questi esempi come vengono qui mostrati. Sostituisci l'indirizzo con 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 di ClusterCIDRConfig per nodo

    ---
    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 per specificare un PodCIDR a livello di pool di nodi

Nota: le due modalità IP flat 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 flat dinamico (con BGP): può essere utilizzato anche quando i nodi coprono 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: configura il PodCIDR a livello di cluster - Nessun nodeSelector configurato

Nota: le due modalità IP flat 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 flat dinamico (con BGP): può essere utilizzato anche quando i nodi coprono 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 di ClusterCIDRConfig per nodo

    ---
    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 per specificare un PodCIDR a livello di pool di nodi

Nota: le due modalità IP flat 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 flat dinamico (con BGP): può essere utilizzato anche quando i nodi coprono 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: configura il PodCIDR a livello di cluster - Nessun nodeSelector configurato

Nota: le due modalità IP flat 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 flat dinamico (con BGP): può essere utilizzato anche quando i nodi coprono 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 piatto, IPv6 piatto)

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 di ClusterCIDRConfig per nodo

Nota: le due modalità IP flat 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 flat dinamico (con BGP): può essere utilizzato anche quando i nodi coprono 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 per specificare un PodCIDR a livello di pool di nodi

Nota: le due modalità IP flat 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 flat dinamico (con BGP): può essere utilizzato anche quando i nodi coprono 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: configura il PodCIDR a livello di cluster - Nessun nodeSelector configurato

    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