Gestione di pool di nodi di diversi tipi di macchine virtuali

Questo argomento spiega come creare, aggiornare ed eliminare pool di nodi in un cluster del carico di lavoro. I pool di nodi consentono a un singolo cluster del carico di lavoro di contenere e gestire diversi tipi di nodi per supportare le esigenze delle varie applicazioni.

Ad esempio, un cluster può utilizzare nodi con capacità di storage elevata per eseguire un datastore e nodi con capacità di storage inferiore per elaborare le richieste delle applicazioni.

Nota

Per creare e utilizzare pool di nodi in cluster del carico di lavoro creati da vSphere with Tanzu, è necessario eseguire vSphere v7.0 U3 o versione successiva.

Se si utilizza vSphere with Tanzu, i cluster di vSphere with Tanzu devono utilizzare l'API v1alpha2 per eseguire correttamente i comandi node-pool. Per ulteriori informazioni, vedere la documentazione di vSphere with Tanzu.

Informazioni sui pool di nodi

I pool di nodi definiscono le proprietà per i set di nodi worker utilizzati da un cluster del carico di lavoro.

Alcune proprietà del pool di nodi dipendono dalle opzioni della macchina virtuale disponibili nell'infrastruttura sottostante, ma tutti i pool di nodi in tutte le infrastrutture cloud condividono le seguenti proprietà:

  • name: identificatore univoco per il pool di nodi, utilizzato per operazioni come aggiornamenti ed eliminazioni.
  • replicas: numero di nodi nel pool che condividono tutti le stesse proprietà.
  • labels: coppie chiave/valore impostate come metadati nei nodi per associare i carichi di lavoro ai nodi nel pool. Per ulteriori informazioni ed etichette di esempio, vedere Etichette e selettori nella documentazione di Kubernetes.

Per i cluster del carico di lavoro in vSphere, i cluster di gestione autonomi per impostazione predefinita seguono regole di anti-affinità per distribuire i worker del pool di nodi e i nodi del piano di controllo in host ESXi diversi. Per disattivare le regole di anti-affinità per il posizionamento dei nodi, vedere Disattivazione delle regole di anti-affinità.

Tutti i cluster del carico di lavoro vengono creati con un primo pool di nodi originale. Quando si creano pool di nodi aggiuntivi per un cluster, come descritto di seguito, il primo pool di nodi fornisce i valori predefiniti per le proprietà non impostate nelle definizioni del nuovo pool di nodi.

Elenco dei pool di nodi

Per ispezionare i pool di nodi attualmente disponibili in un cluster, eseguire:

tanzu cluster node-pool list CLUSTER-NAME

Il comando restituisce un elenco di tutti i pool di nodi nel cluster e lo stato delle repliche in ogni pool di nodi.

Creazione di un pool di nodi

Per creare un pool di nodi in un cluster:

  1. Creare un file di configurazione per il pool di nodi. Per un file di configurazione di esempio, vedere Configurazione di esempio.

    Per un elenco completo delle proprietà di configurazione, vedere Proprietà di configurazione.

  2. Creare il pool di nodi definito dal file di configurazione:

    tanzu cluster node-pool set CLUSTER-NAME -f /PATH/TO/CONFIG-FILE

    Opzioni:

    • --namespace specifica lo spazio dei nomi del cluster. Il valore predefinito è default.
    • (Cluster legacy) --base-machine-deployment specifica l'oggetto MachineDeployment di base da cui creare il nuovo pool di nodi.
      • Impostare questo valore come identificatore di MachineDeployment come indicato nell'output di tanzu cluster get in Details.
      • Il valore predefinito è il primo nell'array di oggetti MachineDeployment del nodo worker del cluster, rappresentato internamente come workerMDs[0].

Configurazione di esempio

Di seguito viene illustrata una configurazione di esempio per l'infrastruttura sottostante.

Configurazione di vSphere
Oltre alle proprietà name, replicas e labels obbligatorie, i file di configurazione per i pool di nodi in vSphere possono includere un blocco vsphere per definire proprietà facoltative specifiche della configurazione delle macchine virtuali in vSphere.

Definizione del pool di nodi di esempio per il cluster vSphere:

    name: tkg-wc-oidc-md-1
    replicas: 4
    labels:
      key1: value1
      key2: value2
    vsphere:
      memoryMiB: 8192
      diskGiB: 64
      numCPUs: 4
      datacenter: dc0
      datastore: iscsi-ds-0
      storagePolicyName: name
      folder: vmFolder
      resourcePool: rp-1
      vcIP: 10.0.0.1
      template: templateName
      cloneMode: clone-mode
      network: network-name

Tutti i valori non impostati in vsphere bloccano l'eredità dai valori del primo pool di nodi del cluster.

Per il valore vcIP, i pool di nodi del cluster del carico di lavoro devono essere eseguiti nello stesso vCenter del piano di controllo del cluster.

Per i cluster distribuiti da un supervisore di vSphere with Tanzu, definire storageClass, tkr e vmClass. Per ulteriori informazioni su queste proprietà, vedere TanzuKubernetesCluster v1alpha3 API - Con annotazioni nella documentazione di vSphere with Tanzu.

Per impostazione predefinita, i cluster del carico di lavoro in vSphere vengono distribuiti in base a regole di anti-affinità che distribuiscono i nodi del piano di controllo e i nodi worker in ogni pool di nodi in più host ESXi. Per disattivare o riattivare le regole anti-affinità, vedere Disattivazione della regola di anti-affinità (vSphere) di seguito.

Configurazione di AWS
Oltre alle proprietà name, replicas e labels obbligatorie, i file di configurazione per i pool di nodi in AWS supportano le proprietà facoltative seguenti:
  • az: Zona disponibilità
  • nodeMachineType: Tipo di istanza

Queste impostazioni possono essere omesse. In questo caso, ereditano i loro valori dal primo pool di nodi del cluster.

Definizione del pool di nodi di esempio per un cluster AWS:

name: tkg-aws-wc-np-1
replicas: 2
az: us-west-2b
nodeMachineType: t3.large
labels:
  key1: value1
  key2: value2
Nota

I pool di nodi del cluster del carico di lavoro in AWS devono trovarsi nella stessa zona di disponibilità del cluster di gestione autonomo.

Configurazione di Azure
Oltre alle proprietà name, replicas e labels obbligatorie precedenti, i file di configurazione per i pool di nodi in Microsoft Azure supportano le proprietà facoltative seguenti:
  • az: Zona disponibilità
  • nodeMachineType: Tipo di istanza

Se le impostazioni vengono omesse, i loro valori vengono ereditati dal primo pool di nodi del cluster.

Definizione del pool di nodi di esempio per il cluster di Azure:

name: tkg-azure-wc-np-1
replicas: 2
az: 2
nodeMachineType: Standard_D2s_v3
labels:
  key1: value1
  key2: value2

Proprietà di configurazione

Nella tabella seguente sono elencate tutte le proprietà che è possibile definire nel file di configurazione di un pool di nodi per i cluster del carico di lavoro.

Nome Tipo Oggetto cluster Provider Note
name string Qualsiasi Tutti Nome del pool di nodi da creare o aggiornare.
replicas integer Qualsiasi Tutti Numero di nodi nel pool di nodi.
az string Qualsiasi TKG in AWS o Azure ZD in cui posizionare i nodi.
nodeMachineType string Qualsiasi TKG in AWS o Azure instanceType o vmSize per il nodo in AWS e Azure rispettivamente.
labels map[string]string Qualsiasi Tutti Etichette da impostare nel nodo utilizzando kubeletExtraArgs (‐‐node-labels).
vmClass string Qualsiasi Tutti Nome di un oggetto vmClass di Kubernetes. Corrisponde al valore di vmClass definito nel cluster TKC. Questa classe imposta la CPU e la memoria disponibili per il nodo. Per visualizzare un elenco delle classi di macchina virtuale disponibili, eseguire kubectl describe virtualmachineclasses.
storageClass string Qualsiasi Tutti Nome di un elemento StorageClass Kubernetes da utilizzare per il pool di nodi. Questa classe si applica ai dischi che archiviano i file system root dei nodi. Per visualizzare un elenco delle classi di storage disponibili, eseguire kubectl describe storageclasses.
volumes:
  • name, string
  • mountPath, string
  • capacity, corev1.ResourceList
  • storageClass, string
 []object Qualsiasi Tutti Volumi da utilizzare per i nodi.
tkr:
  • reference, string
 object Basato su TKC Tutti Nome del TKR da utilizzare per il pool di nodi. Ad esempio, v1.24.10—vmware.2-tkg.2.
tkrResolver string Basato sulla classe Tutti Obbligatorio per i cluster basati sulla classe. Valore dell'annotazione run.tanzu.vmware.com/resolve-os-image della risorsa Cluster.
nodeDrainTimeout metav1.Duration Qualsiasi Tutti Timeout dello svuotamento del nodo.
vsphere object Qualsiasi Tutti Vedere Proprietà di configurazione (solo vSphere).
workerClass string Basato sulla classe Tutti Obbligatorio per i cluster basati sulla classe. workerClass dell'elemento ClusterClass che si desidera venga utilizzato dal pool di nodi.

Proprietà di configurazione (solo vSphere)

Per informazioni sulle variabili di configurazione di VSPHERE_*, vedere vSphere nelle Informazioni di riferimento sulle variabili del file di configurazione.

Nome Tipo Tipo di cluster di gestione Note
cloneMode string Autonomo Uguale a VSPHERE_CLONE_MODE.
datacenter string Autonomo Uguale a VSPHERE_DATACENTER.
datastore string Autonomo Uguale a VSPHERE_DATASTORE.
storagePolicyName string Autonomo Uguale a VSPHERE_STORAGE_POLICY_NAME.
taints []corev1.Taint Supervisore Taint da applicare al nodo.
folder string Autonomo Uguale a VSPHERE_FOLDER.
network string Autonomo Uguale a VSPHERE_NETWORK.
nameservers []string Autonomo Uguale a VSPHERE_WORKER_NAMESERVERS.
tkgIPFamily string Autonomo Uguale a TKG_IP_FAMILY.
resourcePool string Autonomo Uguale a VSPHERE_RESOURCE_POOL.
vcIP string Autonomo Uguale a VSPHERE_SERVER.
template string Autonomo Uguale a VSPHERE_TEMPLATE.
memoryMiB integer Autonomo Uguale a VSPHERE_WORKER_MEM_MIB.
diskGiB integer Autonomo Uguale a VSPHERE_WORKER_DISK_GIB.
numCPUs integer Autonomo Uguale a VSPHERE_WORKER_NUM_CPUS.

Assegnare carichi di lavoro a un pool di nodi

Per assegnare un carico di lavoro a un pool di nodi:

  1. Nella risorsa del carico di lavoro Kubernetes o nelle risorse che gestiscono i pod, impostare nodeSelector sul valore di labels definito nel file di configurazione del pool di nodi. Per informazioni sulle risorse del carico di lavoro Kubernetes, vedere Carichi di lavoro nella documentazione di Kubernetes.
  2. Applicare la configurazione eseguendo il comando kubectl apply -f.

Per riassegnare un carico di lavoro a un pool di nodi diverso:

  1. Nella risorsa del carico di lavoro Kubernetes o nelle risorse che gestiscono i pod, aggiornare il valore di nodeSelector al nuovo valore.
  2. Applicare l'aggiornamento della configurazione eseguendo il comando kubectl apply -f.

Aggiornamento del pool di nodi

Se è necessario modificare solo il numero di nodi di un pool di nodi, utilizzare il comando della CLI di Tanzu indicato in Modifica del solo numero di nodi. Se si desidera aggiungere le etichette, eseguire la procedura descritta in Aggiunta di etichette e modifica del numero dei nodi.

Attenzione

non utilizzare queste procedure per modificare le etichette esistenti, la zona di disponibilità, il tipo di istanza del nodo (in AWS o Azure) o le proprietà della macchina virtuale (in vSphere) del pool di nodi. Queste modifiche possono infatti avere effetti negativi sui carichi di lavoro in esecuzione. Per modificare queste proprietà, creare un nuovo pool di nodi con le proprietà e riassegnare i carichi di lavoro nel nuovo pool di nodi prima di eliminare l'originale. Per istruzioni, vedere Assegnazione dei carichi di lavoro a un pool di nodi sopra.

Modifica del solo numero di nodi

Per modificare il numero di nodi in un pool di nodi, eseguire:

tanzu cluster scale CLUSTER-NAME -p NODE-POOL-NAME -w NODE-COUNT

In cui:

  • CLUSTER-NAME è il nome del cluster del carico di lavoro.
  • NODE-POOL-NAME è il nome del pool di nodi.
  • NODE-COUNT è il numero di nodi che appartengono al pool di nodi, espresso con un valore integer.

Aggiunta di etichette e modifica del numero dei nodi

È possibile aggiungere etichette in un pool di nodi e modificarne contemporaneamente il numero di nodi tramite il file di configurazione del pool di nodi.

  1. Aprire il file di configurazione per il pool di nodi che si desidera aggiornare.

  2. Se si aumenta o si diminuisce il numero di nodi in questo pool di nodi, aggiornare il numero dopo replicas.

  3. Se si aggiungono etichette, inserirle con rientro sotto labels. Ad esempio:

    labels:
  key1: value1
  key2: value2

  4. Salvare il file di configurazione del pool di nodi.

  5. In un terminale, eseguire:

    tanzu cluster node-pool set CLUSTER-NAME -f /PATH/TO/CONFIG-FILE

    Se CLUSTER-NAME nel comando e name nel file di configurazione corrispondono a un pool di nodi nel cluster, questo comando aggiorna il pool di nodi esistente anziché crearne uno nuovo.

Eliminazione di pool di nodi

Per eliminare un pool di nodi, eseguire:

tanzu cluster node-pool delete CLUSTER-NAME -n NODE-POOL-NAME

In cui CLUSTER-NAME è il nome del cluster del carico di lavoro e NODE-POOL-NAME è il nome del pool di nodi.

Facoltativamente, utilizzare --namespace per specificare lo spazio dei nomi del cluster. Il valore predefinito è default.

Attenzione

Prima di eseguire questa operazione, riassegnare tutti i carichi di lavoro di questi nodi in altri nodi. tanzu cluster node-pool delete non esegue la migrazione dei carichi di lavoro dei nodi prima di eliminarli. Per istruzioni, vedere Assegnazione dei carichi di lavoro a un pool di nodi sopra.

Disattivare la regola di anti-affinità (vSphere)

Per impostazione predefinita, i cluster del carico di lavoro in vSphere vengono distribuiti in base a regole di anti-affinità che distribuiscono i nodi del piano di controllo e i nodi worker in ogni pool di nodi in più host ESXi. Per disattivare o riattivare le regole di anti-affinità durante la creazione del cluster, eseguire le operazioni seguenti:

  1. Impostare il contesto di kubectl sul cluster di gestione:

    kubectl config use-context MGMT-CLUSTER-NAME-admin@MGMT-CLUSTER-NAME

    In cui MGMT-CLUSTER-NAME è il nome del cluster.

  2. Eseguire kubectl get deployment nel controller CAPV per raccogliere i valori args per il container manager, ad esempio:

    kubectl get deployment -n capv-system capv-controller-manager -o=json | jq '.spec.template.spec.containers[] | select(.name=="manager") | .args'
[
  "--leader-elect",
  "--logtostderr",
  "--v=4",
  "--feature-gates=NodeAntiAffinity=true,NodeLabeling=true"
]

  3. Con l'output copiato dal passaggio precedente, modificare i valori --feature-gates e passare l'elenco degli argomenti a un comando kubectl patch che modifica i valori nell'oggetto. Ad esempio, per impostare i gate delle funzionalità NodeAntiAffinity e NodeLabeling su false disattivando le regole di anti-affinità del nodo:

    kubectl patch deployment -n capv-system capv-controller-manager --type=json -p '[{"op":"replace", "path":"/spec/template/spec/containers/0/args", "value": [
"--leader-elect",
"--logtostderr",
"--v=4",
"--feature-gates=NodeAntiAffinity=false,NodeLabeling=false"
]}]'
check-circle-line exclamation-circle-line close-line
Scroll to top icon