Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.
Informazioni sulla risorsa personalizzata ClusterCIDRConfig
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Panoramica
ClusterCIDRConfig è una risorsa di allocazione CIDR personalizzata che consente di allocare dinamicamente più intervalli di indirizzi IP per i pod.
La gestione degli indirizzi IP (IPAM) consente un utilizzo efficiente delle subnet IP ed evita sovrapposizioni negli intervalli di indirizzi, evitando così conflitti e interruzioni della rete.
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 vengono 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. Questa limitazione può comportare 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. Ciò comporta uno spreco di 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. La risorsa 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à:
Cluster.spec.clusterNetwork.pods.cidrBlocks è un campo facoltativo e non è definito per impostazione predefinita. Devi definirla se una qualsiasi delle caratteristiche nella precedente
non lo ha definito nell'elenco. Ad esempio, è obbligatorio quando i cluster
vengono creati in modalità isola IPv4 e devono essere specificati perché vengono utilizzati come server
CIDR di routing.
La tabella seguente elenca l'utilizzo del comportamento del campo Cluster.spec.clusterNetwork.pods.cidrBlocks di ClusterCIDRConfig per diverse modalità di rete.
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 Flat)
Specifica il CIDR IPv4.
Non specificare il 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 di utilizzo, consulta Esempi: dual-stack (isola IPv4, IPv6 flat)
Doppio stack (IPv4 piatto, IPv6 piatto)
Puoi saltare Cluster.spec.clusterNetwork.pods.cidrBlocks perché vengono completamente ignorati. Devi definire esplicitamente ClusterCIDRConfigs (per nodo, per pool di nodi e/o per cluster) con i CIDR IPv4 e IPv6.
Configurazione della risorsa allocatore CIDR personalizzato ClusterCIDRConfig
ClusterCIDRConfig
Quando configuri la risorsa allocator CIDR personalizzata ClusterCIDRConfig,
tieni presente 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. Una volta specificati ClusterCIDRConfigs,
non potrai modificare i valori in un secondo momento.
Puoi specificare più ClusterCIDRConfig con CIDR sovrapposti.
Se non viene trovato alcun ClusterCIDRConfig corrispondente per un nodo, il nodo rimane in stato NotReady finché 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 possono associare le etichette del campo nodeSelector alle etichette dei nodi.
Regole di assegnazione di ClusterCIDRConfig
per determinare quale ClusterCIDRConfig viene utilizzato per assegnare i CIDR dei pod all'attuale
utilizza le seguenti regole di tie-breaking. Implementa queste regole nell'ordine specificato. Implementa la regola successiva solo se il legame non è rotto dalla precedente
personalizzata.
Scegli ClusterCIDRConfig il cui NodeSelector corrisponde al maggior numero di etichette sul Node. 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).
Scegli ClusterCIDRConfig con il minor numero di CIDR 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).
Scegli ClusterCIDRConfig per cui PerNodeMaskSize ha il minor numero di indirizzi IP.
Ad esempio, 27 (2^(32-27)= 32 indirizzi IP) scelto prima di
25 (2^(32-25)=128 indirizzi IP).
Scegli il ClusterCIDRConfig la cui etichetta NodeSelector corrispondente ha un valore inferiore
valore alfanumerico. Ad esempio, {'kubernetes.io/hostname': 'node-1'} viene scelto al posto di {'node.kubernetes.io/instance-type':'medium'}.
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.
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)
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2024-10-14 UTC."],[],[]]