È possibile scalare un cluster TKG Service orizzontalmente modificando il numero di nodi oppure verticalmente modificando la classe di macchine virtuali che ospita i nodi. È inoltre possibile scalare i volumi collegati ai nodi del cluster.

Operazioni di scalabilità manuale supportate

Nella tabella sono elencate le operazioni di scalabilità supportate per i cluster TKG.
Tabella 1. Operazioni di scalabilità supportate per i cluster TKGS
Nodo Scalabilità orizzontale Scalabilità verticale Scala verticale Scala del volume
Piano di controllo Sì No Sì Sì*
Worker Sì Sì Sì Sì
Tenere presenti le considerazioni seguenti:
  • Il numero di nodi del piano di controllo deve essere dispari, 1 o 3. Per il piano di controllo, è supportata la scalabilità orizzontale ma non la scalabilità verticale. Vedere Scalare orizzontalmente il piano di controllo.
  • Mentre si scala verticalmente un nodo del cluster, potrebbe non essere possibile eseguire i carichi di lavoro nel nodo per mancanza di risorse disponibili. Di conseguenza, la scala orizzontale è in genere l'approccio preferito. Vedere Scalare orizzontalmente i nodi di lavoro.
  • Le classi di macchine virtuali non sono modificabili. Se si esegue la scalabilità orizzontale di un cluster TKG dopo aver modificato una classe di macchine virtuali utilizzata da tale cluster, i nuovi nodi del cluster utilizzano la definizione della classe aggiornata, ma i nodi del cluster esistenti continuano a utilizzare la definizione della classe iniziale, causando una mancata corrispondenza. Vedere Informazioni sulle classi di macchine virtuali.
  • I volumi dei nodi worker possono essere modificati dopo il provisioning. Analogamente, è possibile modificare i nodi del piano di controllo purché si stia utilizzando vSphere 8 U3 o versioni successive e una TKr compatibile. Vedere Scalabilità dei volumi dei nodi del cluster.

Prerequisito di scalabilità: configurare la modifica di Kubectl

Per scalare un cluster TKG, aggiornare il manifest del cluster usando il comando kubectl edit CLUSTER-KIND/CLUSTER-NAME. Quando si salva le modifiche del manifest, il cluster viene aggiornato con le modifiche. Vedere Configurazione di un editor di testo per Kubectl.

Ad esempio: 
kubectl edit tanzukubernetescluster/tkg-cluster-1
tanzukubernetescluster.run.tanzu.vmware.com/tkg-cluster-1 edited
Per annullare le modifiche, chiudere l'editor senza salvare. 
kubectl edit tanzukubernetescluster/tkg-cluster-1
Edit cancelled, no changes made.

Scalare orizzontalmente il piano di controllo

Scalare orizzontalmente un cluster TKG aumentando da 1 a 3 il numero di nodi del piano di controllo.
Nota: I cluster di produzione richiedono 3 nodi del piano di controllo.
  1. Accedere a Supervisore. 
    kubectl vsphere login --server=SUPERVISOR-IP-ADDRESS --vsphere-username USERNAME
  2. Passare al contesto Spazio dei nomi vSphere in cui è in esecuzione il cluster TKG.
    kubectl config use-context tkg-cluster-ns
  3. Elencare i cluster Kubernetes in esecuzione in Spazio dei nomi vSphere.

    Utilizzare la sintassi seguente:

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Ad esempio, per un cluster dell'API v1alpha3: 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Ad esempio, per un cluster dell'API v1beta1: 
    kubectl get cluster -n tkg-cluster-ns
  4. Ottenere il numero di nodi in esecuzione nel cluster di destinazione.

    Per un cluster dell'API v1alpha3: 

    kubectl get tanzukubernetescluster tkg-cluster-1
    Il cluster TKG ha 1 nodo del piano di controllo e 3 nodi worker. 
    NAMESPACE             NAME             CONTROL PLANE   WORKER   TKR NAME                   AGE     READY
tkg-cluster-ns        tkg-cluster-1    1               3        v1.24.9---vmware.1-tkg.4   5d12h   True

    Per un cluster dell'API v1beta1: 

    kubectl get cluster tkg-cluster-1
  5. Caricare il manifesto del cluster per la modifica utilizzando il comando kubectl edit.
    Per un cluster dell'API v1alpha3: 
    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Per un cluster dell'API v1beta1: 
    kubectl edit cluster/tkg-cluster-1

    Il manifesto del cluster viene aperto nell'editor di testo definito dalle variabili di ambiente KUBE_EDITOR o EDITOR.

  6. Aumentare il numero di nodi del piano di controllo da 1 a 3 nella sezione spec.topology.controlPlane.replicas del manifesto.
    Per un cluster dell'API v1alpha3: 
    ...
spec:
  topology:
    controlPlane:
      replicas: 1
...

    ...
spec:
  topology:
    controlPlane:
      replicas: 3
...
    Per un cluster dell'API v1beta1: 
    ...
spec:
  ...
  topology:
    class: tanzukubernetescluster
    controlPlane:
      metadata: {}
      replicas: 1
    variables:
...

    ...
spec:
  ...
  topology:
    class: tanzukubernetescluster
    controlPlane:
      metadata: {}
      replicas: 3
    variables:
...
  7. Salvare il file nell'editor di testo per applicare le modifiche. (Per annullare, chiudere l'editor senza salvare.)

    Quando si salva le modifiche del manifest, kubectl applica le modifiche al cluster. In background, il Servizio macchina virtuale in Supervisore esegue il provisioning del nuovo nodo del piano di controllo.

  8. Verificare che i nuovi nodi siano stati aggiunti.

    Per un cluster dell'API v1alpha3:

    kubectl get tanzukubernetescluster tkg-cluster-1
    Il piano di controllo scalato orizzontalmente ora presenta 3 nodi. 
    NAMESPACE             NAME             CONTROL PLANE   WORKER   TKR NAME                   AGE     READY
tkg-cluster-ns        tkg-cluster-1    3               3        v1.24.9---vmware.1-tkg.4   5d12h   True

    Per un cluster dell'API v1beta1: 

    kubectl get cluster tkg-cluster-1

Scalare orizzontalmente i nodi di lavoro

È possibile scalare orizzontalmente un cluster TKG aumentando il numero di nodi worker.

  1. Accedere a Supervisore. 
    kubectl vsphere login --server=SVC-IP-ADDRESS --vsphere-username USERNAME
  2. Passare al contesto Spazio dei nomi vSphere in cui è in esecuzione il cluster TKG.
    kubectl config use-context tkg-cluster-ns
  3. Elencare i cluster Kubernetes in esecuzione in Spazio dei nomi vSphere.

    Utilizzare la sintassi seguente:

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Ad esempio, per un cluster dell'API v1alpha3: 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Ad esempio, per un cluster dell'API v1beta1: 
    kubectl get cluster -n tkg-cluster-ns
  4. Ottenere il numero di nodi in esecuzione nel cluster di destinazione.

    Per un cluster dell'API v1alpha3:

    kubectl get tanzukubernetescluster tkg-cluster-1
    Ad esempio, il cluster seguente presenta 3 nodi del piano di controllo e 3 nodi di lavoro. 
    NAMESPACE             NAME             CONTROL PLANE   WORKER   TKR NAME                   AGE     READY
tkg-cluster-ns        tkg-cluster-1    3               3        v1.24.9---vmware.1-tkg.4   5d12h   True
    Per un cluster dell'API v1beta1: 
    kubectl get cluster tkg-cluster-1
  5. Caricare il manifesto del cluster per la modifica utilizzando il comando kubectl edit.

    Per un cluster dell'API v1alpha3:

    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Per un cluster dell'API v1beta1: 
    kubectl edit cluster/tkg-cluster-1

    Il manifesto del cluster viene aperto nell'editor di testo definito dalle variabili di ambiente KUBE_EDITOR o EDITOR.

  6. Aumentare il numero di nodi di lavoro modificando il valore spec.topology.nodePools.NAME.replicas per il pool di nodi di lavoro di destinazione.
    Per un cluster dell'API v1alpha3: 
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 3
...
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 4
...
    Per un cluster dell'API v1beta1: 
    ...
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  ...
spec:
  ...
  topology:
    ...
    class: tanzukubernetescluster
    controlPlane:
    ...
    workers:
      machineDeployments:
      - class: node-pool
        metadata: {}
        name: node-pool-1
        replicas: 3
...
    ...
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  ...
spec:
  ...
  topology:
    ...
    class: tanzukubernetescluster
    controlPlane:
    ...
    workers:
      machineDeployments:
      - class: node-pool
        metadata: {}
        name: node-pool-1
        replicas: 4
...
  7. Per applicare le modifiche, salvare il file nell'editor di testo. Per annullare le modifiche, chiudere l'editor senza salvare.

    Quando si salva il file, kubectl applica le modifiche al cluster. In background, il Servizio macchina virtuale su Supervisore esegue il provisioning del nuovo nodo di lavoro.

  8. Verificare che i nuovi nodi siano stati aggiunti.

    Per un cluster dell'API v1alpha3:

    kubectl get tanzukubernetescluster tkg-cluster-1
    Dopo la scalatura orizzontale, il cluster presenta 4 nodi di lavoro. 
    NAMESPACE             NAME             CONTROL PLANE   WORKER   TKR NAME                   AGE     READY
tkg-cluster-ns        tkg-cluster      3               4        v1.24.9---vmware.1-tkg.4   5d12h   True

    Per un cluster dell'API v1beta1: 

    kubectl get cluster tkg-cluster-1

Scalare verticalmente i nodi di lavoro

È possibile scalare verticalmente un cluster TKG diminuendo il numero di nodi worker.

  1. Accedere a Supervisore. 
    kubectl vsphere login --server=SVC-IP-ADDRESS --vsphere-username USERNAME
  2. Passare al contesto Spazio dei nomi vSphere in cui è in esecuzione il cluster TKG.
    kubectl config use-context tkg-cluster-ns
  3. Elencare i cluster Kubernetes in esecuzione in Spazio dei nomi vSphere.

    Utilizzare la sintassi seguente:

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Ad esempio, per un cluster dell'API v1alpha3: 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Ad esempio, per un cluster dell'API v1beta1: 
    kubectl get cluster -n tkg-cluster-ns
  4. Ottenere il numero di nodi in esecuzione nel cluster di destinazione.
    kubectl get tanzukubernetescluster tkg-cluster-1
  5. Ottenere il numero di nodi in esecuzione nel cluster di destinazione.

    Per un cluster dell'API v1alpha3:

    kubectl get tanzukubernetescluster tkg-cluster-1
    Ad esempio, il cluster seguente include 3 nodi del piano di controllo e 4 nodi di lavoro. 
    NAMESPACE             NAME             CONTROL PLANE   WORKER   TKR NAME                   AGE     READY
tkg-cluster-ns        tkg-cluster      3               4        v1.24.9---vmware.1-tkg.4   5d12h   True
    Per un cluster dell'API v1beta1: 
    kubectl get cluster tkg-cluster-1
  6. Caricare il manifesto del cluster per la modifica utilizzando il comando kubectl edit.

    Per un cluster dell'API v1alpha3:

    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Per un cluster dell'API v1beta1: 
    kubectl edit cluster/tkg-cluster-1

    Il manifesto del cluster viene aperto nell'editor di testo definito dalle variabili di ambiente KUBE_EDITOR o EDITOR.

  7. Ridurre il numero di nodi di lavoro modificando il valore spec.topology.nodePools.NAME.replicas per il pool di nodi di lavoro di destinazione.
    Per un cluster dell'API v1alpha3: 
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 4
...
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 3
...
    Per un cluster dell'API v1beta1: 
    ...
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  ...
spec:
  ...
  topology:
    ...
    class: tanzukubernetescluster
    controlPlane:
    ...
    workers:
      machineDeployments:
      - class: node-pool
        metadata: {}
        name: node-pool-1
        replicas: 4
...
    ...
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  ...
spec:
  ...
  topology:
    ...
    class: tanzukubernetescluster
    controlPlane:
    ...
    workers:
      machineDeployments:
      - class: node-pool
        metadata: {}
        name: node-pool-1
        replicas: 3
...
  8. Per applicare le modifiche, salvare il file nell'editor di testo. Per annullare le modifiche, chiudere l'editor senza salvare.

    Quando si salva il file, kubectl applica le modifiche al cluster. In background, il Servizio macchina virtuale su Supervisore esegue il provisioning del nuovo nodo di lavoro.

  9. Verificare che i nodi di lavoro siano stati rimossi.

    Per un cluster dell'API v1alpha3:

    kubectl get tanzukubernetescluster tkg-cluster-1
    Dopo la scalatura verticale, il cluster presenta 3 nodi di lavoro. 
    NAMESPACE             NAME             CONTROL PLANE   WORKER   TKR NAME                   AGE     READY
tkg-cluster-ns        tkg-cluster-1    3               3        v1.24.9---vmware.1-tkg.4   5d12h   True

    Per un cluster dell'API v1beta1: 

    kubectl get cluster tkg-cluster-1

Scalare verticalmente un cluster

TKG in Supervisore supporta la scalabilità verticale per i nodi del piano di controllo e i nodi worker del cluster. È possibile scalare verticalmente un cluster TKG modificando la classe macchina virtuale utilizzata per i nodi del cluster. La classe di macchine virtuali deve essere associata al Spazio dei nomi vSphere in cui viene eseguito il provisioning del cluster TKG.

TKG in Supervisore supporta la scalabilità verticale tramite il meccanismo di aggiornamento in sequenza incorporato nel sistema. Quando si modifica la definizione di VirtualMachineClass, il sistema implementa nuovi nodi con la nuova classe e rende inattivi i nodi precedenti. Vedere Aggiornamento dei cluster TKG Service.

  1. Accedere a Supervisore.
    kubectl vsphere login --server=SVC-IP-ADDRESS --vsphere-username USERNAME
  2. Passare al contesto Spazio dei nomi vSphere in cui è in esecuzione il cluster TKG.
    kubectl config use-context tkg-cluster-ns
  3. Elencare i cluster Kubernetes in esecuzione in Spazio dei nomi vSphere.

    Utilizzare la sintassi seguente:

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Ad esempio, per un cluster dell'API v1alpha3: 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Ad esempio, per un cluster dell'API v1beta1: 
    kubectl get cluster -n tkg-cluster-ns
  4. Descrivere il cluster TKG di destinazione e controllare la classe di macchine virtuali.

    Per un cluster dell'API v1alpha3:

    kubectl describe tanzukubernetescluster tkg-cluster-1

    Ad esempio, il cluster seguente utilizza la classe di macchine virtuali best effort medium.

    spec:
  topology:
    controlPlane:
      replicas: 3
      vmClass: best-effort-medium
      ...
    nodePools:
    - name: worker-nodepool-a1
      replicas: 3
      vmClass: best-effort-medium
      ...

    Per un cluster dell'API v1beta1:

    kubectl describe cluster tkg-cluster-1

    Ad esempio, il cluster seguente utilizza la classe di macchine virtuali best effort medium.

    ...
Topology:
      ...
    Variables:
      ...
      Name:   vmClass
      Value:  best-effort-medium
    ...
    Nota: Per i cluster dell'API v1beta1, per impostazione predefinita vmClass viene impostata globalmente come singola variabile. È possibile sostituire questa impostazione e utilizzare una classe di macchine virtuali diversa per i nodi del piano di controllo e i nodi worker. Vedere vmClassnella documentazione di riferimento dell'API.
  5. Elencare e descrivere le classi di macchine virtuali disponibili.
    kubectl get virtualmachineclass
    kubectl describe virtualmachineclass
    Nota: La classe di macchine virtuali deve essere associata allo Spazio dei nomi vSphere. Vedere Utilizzo di classi di macchine virtuali con i cluster Servizio TKG.
  6. Aprire per modificare il manifesto del cluster di destinazione.

    Per un cluster dell'API v1alpha3:

    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Per un cluster dell'API v1beta1: 
    kubectl edit cluster/tkg-cluster-1

    Il manifesto del cluster viene aperto nell'editor di testo definito dalle variabili di ambiente KUBE_EDITOR o EDITOR.

  7. Modificare il manifesto modificando la classe di macchine virtuali.
    Per un cluster dell'API v1alpha3, impostare la classe di macchine virtuali per il piano di controllo su guaranteed-medium e la classe di macchine virtuali per i nodi worker su guaranteed-large. 
    spec:
  topology:
    controlPlane:
      replicas: 3
      vmClass: guaranteed-medium
      ...
    nodePools:
    - name: worker-nodepool-a1
      replicas: 3
      vmClass: guaranteed-large
      ...
    Per un cluster dell'API v1beta1, impostare la classe di macchine virtuali su guaranteed-large. 
    ...
Topology:
      ...
    Variables:
      ...
      Name:   vmClass
      Value:  guaranteed-large
    ...
  8. Per applicare le modifiche, salvare il file nell'editor di testo. Per annullare le modifiche, chiudere l'editor senza salvare.

    Quando si salva il file, kubectl applica le modifiche al cluster. In background, il TKG su Supervisore esegue un aggiornamento in continuo del cluster TKG.

  9. Verificare che il cluster TKG venga aggiornato con la nuova classe di macchine virtuali.

    Per un cluster dell'API v1alpha3:

    kubectl describe tanzukubernetescluster tkg-cluster-1

    Per un cluster dell'API v1beta1:

    kubectl describe cluster tkg-cluster-1

Scalabilità dei volumi dei nodi del cluster

Nella specifica del cluster TKG per i nodi, facoltativamente è possibile dichiarare uno o più volumi persistenti per il nodo. La dichiarazione di un volume di nodi è utile per i componenti ad alta rotazione come il runtime del container e kubelet nei nodi worker.

Se si desidera aggiungere o modificare uno o più volumi di nodi dopo la creazione del cluster, tenere presenti le considerazioni seguenti:
Nodo di volume Descrizione

Sono consentite modifiche al volume del nodo di lavoro

Dopo aver eseguito il provisioning di un cluster TKG, è possibile aggiungere o aggiornare volumi del nodo di lavoro. Quando si avvia un aggiornamento in rollback, il cluster viene aggiornato con il volume nuovo o modificato.

Avviso: Se si scala il nodo di lavoro con un volume nuovo o modificato, i dati nel volume corrente vengono eliminati durante l'aggiornamento in corso. Fare riferimento alla spiegazione che segue.

Un volume dichiarato per un nodo del cluster TKG viene considerato non effimero. Un cluster TKG utilizza un'attestazione di volume persistente (PVC) nello spazio dei nomi vSphere in modo che la capacità del volume venga conteggiata rispetto alla quota di storage del cluster TKG. Se si aumenta la capacità di un volume TKC, l'API del cluster Kubernetes (CAPI) eseguirà il rollout dei nuovi worker con un nuovo PVC. TKG non esegue alcuna migrazione dei dati in questo caso, ma Kubernetes (ri)pianifica i pod del carico di lavoro di conseguenza.

Le modifiche al volume del nodo del piano di controllo sono consentite se si utilizza vSphere 8 U3 o versioni successive

Se si utilizza vSphere 8 U3 o versioni successive e una versione di Tanzu Kubernetes compatibile, è possibile aggiungere o aggiornare un volume del nodo del piano di controllo dopo il provisioning di un cluster TKG Service.

Se non si utilizza vSphere 8 U3 o versioni successive, l'API del cluster Kubernetes (CAPI) impedisce le modifiche successive alla creazione di spec.toplogy.controlPlane.volumes.

Se si tenta di aggiungere o modificare un volume del piano di controllo dopo la creazione del cluster, la richiesta viene rifiutata e viene visualizzato il messaggio di errore "Gli aggiornamenti ai campi non modificabili non sono consentiti".

Di seguito è disponibile un estratto della specifica del cluster basata sull'API v1alpha3 con i volumi dei nodi dichiarati. Fare riferimento all'esempio del cluster TKG completo da cui questo estratto proviene in base alle necessità: Esempio v1alpha3: TKC con volumi di storage e nodi predefiniti. Per un esempio di cluster dell'API v1beta1, vedere Esempio v1beta1: cluster personalizzato basato su ClusterClass predefinita.

apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesCluster
...
spec:
   topology:
     controlPlane:
       replicas: 3
       storageClass: tkg-storage-policy
       vmClass: guaranteed-medium
       tkr:
         reference:
           name: v1.24.9---vmware.1-tkg.4
     nodePools:
     - name: worker-nodepool-a1
       replicas: 3
       storageClass: tkg-storage-policy
       vmClass: guaranteed-large
       tkr:
         reference:
           name: v1.24.9---vmware.1-tkg.4
       volumes:
       - name: containerd
         mountPath: /var/lib/containerd
         capacity:
           storage: 50Gi
       - name: kubelet
         mountPath: /var/lib/kubelet
         capacity:
           storage: 50Gi
     - name: worker-nodepool-a2
       ...
   settings:
     ...