Vous pouvez faire évoluer un cluster TKG sur le Superviseur horizontalement en modifiant le nombre de nœuds ou verticalement en modifiant la classe de machine virtuelle hébergeant les nœuds. Vous pouvez également mettre à l'échelle des volumes persistants. Certaines limitations peuvent s'appliquer.

Opérations de mise à l'échelle prises en charge

Le tableau répertorie les opérations de mise à l'échelle prises en charge pour les clusters TKG.
Tableau 1. Opérations de mise à l'échelle prises en charge pour les clusters TKG 2.0
Nœud Montée en charge horizontale Réduction de charge horizontale Échelle verticale Échelle volumétrique
Plan de contrôle Oui Non Oui Non
Worker Oui Oui Oui Oui
Gardez à l'esprit les éléments suivants :
  • Le nombre de nœuds du plan de contrôle doit être impair, 1 ou 3. La montée en charge du plan de contrôle est prise en charge, mais la mise à l'échelle du plan de contrôle n'est pas prise en charge.
  • Lors d'une mise à l'échelle verticale d'un nœud de cluster, les charges de travail risquent de ne plus pouvoir s'exécuter sur le nœud en raison de l'absence de ressources disponibles. Pour cette raison, la mise à l'échelle horizontale peut être l'approche préférée.
  • Les classes de machine virtuelle ne sont pas immuables. Si vous faites monter en charge un cluster TKG après la modification d'une classe de machine virtuelle utilisée par ce cluster, les nouveaux nœuds de clusters utilisent la définition de classe mise à jour, mais les nœuds de clusters existants continuent d'utiliser la définition de classe initiale, ce qui entraîne une discordance.
  • Les volumes de nœuds worker peuvent être modifiés après le provisionnement, ce qui n'est pas le cas des volumes de nœuds de plan de contrôle.

Condition préalable à la mise à l'échelle : configurer la modification Kubectl

Pour mettre à l'échelle un cluster TKG, vous devez mettre à jour son manifeste à l'aide de la commande kubectl edit CLUSTER-KIND/CLUSTER-NAME. Lorsque vous enregistrez les modifications du manifeste, le cluster est mis à jour avec ces dernières. Reportez-vous à la section Configurer un éditeur de texte pour Kubectl.

Par exemple :
kubectl edit tanzukubernetescluster/tkg-cluster-1
tanzukubernetescluster.run.tanzu.vmware.com/tkg-cluster-1 edited
Pour annuler les modifications, fermez l'éditeur sans enregistrer.
kubectl edit tanzukubernetescluster/tkg-cluster-1
Edit cancelled, no changes made.

Monter en charge le plan de contrôle

Effectuez une montée en charge d'un cluster TKG 2.0 en augmentant le nombre de nœuds de plan de contrôle de 1 à 3.
Note : Les clusters de production nécessitent 3 nœuds de plan de contrôle.
  1. Connectez-vous à Superviseur.
    kubectl vsphere login --server=SUPERVISOR-IP-ADDRESS --vsphere-username USERNAME
  2. Faites basculer le contexte vers l'Espace de noms vSphere où le cluster TKG est en cours d'exécution.
    kubectl config use-context tkg-cluster-ns
  3. Répertoriez les clusters Kubernetes en cours d'exécution dans l'Espace de noms vSphere.
    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Par exemple :
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
  4. Obtenez le nombre de nœuds en cours d'exécution dans le cluster cible.
    kubectl get tanzukubernetescluster tkg-cluster-1
    Par exemple, le cluster TKG dispose de 1 nœud de plan de contrôle et de 3 nœuds 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
    
  5. Chargez le manifeste du cluster afin de le modifier à l'aide de la commande kubectl edit.
    kubectl edit tanzukubernetescluster/tkg-cluster-1

    Le manifeste du cluster s'ouvre dans l'éditeur de texte défini par vos variables d'environnement KUBE_EDITOR ou EDITOR.

  6. Augmentez le nombre de nœuds de plan de contrôle de 1 à 3 dans la section spec.topology.controlPlane.replicas du manifeste.
    Par exemple :
    ...
    spec:
      topology:
        controlPlane:
          replicas: 1
    ...
    
    ...
    spec:
      topology:
        controlPlane:
          replicas: 3
    ...
    
  7. Pour appliquer les modifications, enregistrez le fichier dans l'éditeur de texte. Pour annuler, fermez l'éditeur sans enregistrer.

    Lorsque vous enregistrez les modifications du manifeste, kubectl applique les modifications au cluster. En arrière-plan, le Service de machine virtuelle du Superviseur provisionne le nouveau nœud worker.

  8. Vérifiez que les nouveaux nodes sont ajoutés.
    kubectl get tanzukubernetescluster tkg-cluster-1
    Le plan de contrôle ayant fait l'objet d'une montée en charge dispose dorénavant de 3 nœuds.
    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
    

Monter en charge des nœuds worker

Vous pouvez faire monter en charge un cluster TKG 2.0 en augmentant le nombre de nœuds worker.

  1. Connectez-vous à Superviseur.
    kubectl vsphere login --server=SVC-IP-ADDRESS --vsphere-username USERNAME
  2. Faites basculer le contexte vers l'Espace de noms vSphere où le cluster TKG est en cours d'exécution.
    kubectl config use-context tkg-cluster-ns
  3. Répertoriez les clusters Kubernetes en cours d'exécution dans l'Espace de noms vSphere.
    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Par exemple :
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
  4. Obtenez le nombre de nœuds en cours d'exécution dans le cluster cible.
    kubectl get tanzukubernetescluster tkg-cluster-1
    Par exemple, le cluster suivant dispose de 3 nodes de plan de contrôle et de 3 nodes worker.
    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
    
  5. Chargez le manifeste du cluster afin de le modifier à l'aide de la commande kubectl edit.
    kubectl edit tanzukubernetescluster/tkg-cluster-1

    Le manifeste du cluster s'ouvre dans l'éditeur de texte défini par vos variables d'environnement KUBE_EDITOR ou EDITOR.

  6. Augmentez le nombre de nœuds worker en modifiant la valeur spec.topology.nodePools.NAME.replicas pour le pool de nœuds worker cible.
    Par exemple :
    ...
    spec:
      topology:
        ...
        nodePools:
        - name: worker-1
          replicas: 3
    ...
    ...
    spec:
      topology:
        ...
        nodePools:
        - name: worker-1
          replicas: 4
    ...
  7. Pour appliquer les modifications, enregistrez le fichier dans l'éditeur de texte. Pour annuler les modifications, fermez l'éditeur sans enregistrer.

    Lorsque vous enregistrez le fichier, kubectl applique les modifications au cluster. En arrière-plan, le Service de machine virtuelle du Superviseur provisionne le nouveau nœud worker.

  8. Vérifiez que le nouveau nœud travailleur est ajouté.
    kubectl get tanzukubernetescluster tkg-cluster-1
    Après la montée en charge, le cluster dispose de 4 nœuds worker.
    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
    

Réduire la charge des nœuds worker

Vous pouvez réduire la charge d'un cluster TKG 2.0 en réduisant le nombre de nœuds worker.

  1. Connectez-vous à Superviseur.
    kubectl vsphere login --server=SVC-IP-ADDRESS --vsphere-username USERNAME
  2. Faites basculer le contexte vers l'Espace de noms vSphere où le cluster TKG est en cours d'exécution.
    kubectl config use-context tkg-cluster-ns
  3. Répertoriez les clusters Kubernetes en cours d'exécution dans l'Espace de noms vSphere.
    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Par exemple :
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
  4. Obtenez le nombre de nœuds en cours d'exécution dans le cluster cible.
    kubectl get tanzukubernetescluster tkg-cluster-1
    Par exemple, le cluster suivant dispose de 3 nodes de plan de contrôle et de 4 nodes travailleurs.
    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
    
  5. Chargez le manifeste du cluster afin de le modifier à l'aide de la commande kubectl edit.
    kubectl edit tanzukubernetescluster/tkg-cluster-1

    Le manifeste du cluster s'ouvre dans l'éditeur de texte défini par vos variables d'environnement KUBE_EDITOR ou EDITOR.

  6. Réduisez le nombre de nœuds worker en modifiant la valeur spec.topology.nodePools.NAME.replicas pour le pool de nœuds worker cible.
    Par exemple :
    ...
    spec:
      topology:
        ...
        nodePools:
        - name: worker-1
          replicas: 4
    ...
    ...
    spec:
      topology:
        ...
        nodePools:
        - name: worker-1
          replicas: 3
    ...
  7. Pour appliquer les modifications, enregistrez le fichier dans l'éditeur de texte. Pour annuler les modifications, fermez l'éditeur sans enregistrer.

    Lorsque vous enregistrez le fichier, kubectl applique les modifications au cluster. En arrière-plan, le Service de machine virtuelle du Superviseur provisionne le nouveau nœud worker.

  8. Vérifiez que les nœuds worker ont été supprimés.
    kubectl get tanzukubernetescluster tkg-cluster-1
    Après la réduction de la taille, le cluster dispose de 3 clusters worker.
    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
    

Mettre à l'échelle un cluster verticalement

TKG 2.0 sur le Superviseur prend en charge la mise à l'échelle verticale pour le plan de contrôle du cluster et les nœuds worker. Vous mettez à l'échelle un cluster TKG verticalement en modifiant la classe de machine virtuelle utilisée pour les nœuds de cluster. La classe de machine virtuelle que vous utilisez doit être liée à l'Espace de noms vSphere dans lequel le cluster TKG est provisionné.

TKG 2.0 sur le Superviseur prend en charge la mise à l'échelle verticale via le mécanisme de mise à jour continue intégré au système. Lorsque vous modifiez la définition de VirtualMachineClass, le système déploie de nouveaux nœuds avec cette nouvelle classe et désactive les anciens nœuds. Reportez-vous à la section Maintenance des clusters TKG sur le Superviseur.

  1. Connectez-vous à Superviseur.
    kubectl vsphere login --server=SVC-IP-ADDRESS --vsphere-username USERNAME
  2. Faites basculer le contexte vers l'Espace de noms vSphere où le cluster TKG est en cours d'exécution.
    kubectl config use-context tkg-cluster-ns
  3. Répertoriez les clusters Kubernetes en cours d'exécution dans l'Espace de noms vSphere.
    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Par exemple :
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
  4. Décrivez le cluster TKG cible et vérifiez la classe de machine virtuelle.
    kubectl describe tanzukubernetescluster tkg-cluster-1

    Par exemple, le cluster suivant utilise la classe de machine virtuelle best-effort-medium.

    spec:
      topology:
        controlPlane:
          replicas: 3
          vmClass: guaranteed-medium
          ...
        nodePools:
        - name: worker-nodepool-a1
          replicas: 3
          vmClass: guaranteed-medium
          ...
    
  5. Répertoriez et décrivez les classes de machines virtuelles disponibles.
    kubectl get virtualmachineclassbinding
    kubectl describe virtualmachineclassbinding
    Note : La classe de machine virtuelle doit être liée à l' Espace de noms vSphere. Reportez-vous à la section Utilisation de classes de machines virtuelles avec des clusters TKG sur le Superviseur.
  6. Ouvrez pour modifier le manifeste du cluster cible.
    kubectl edit tanzukubernetescluster/tkg-cluster-1

    Le manifeste du cluster s'ouvre dans l'éditeur de texte défini par vos variables d'environnement KUBE_EDITOR ou EDITOR.

  7. Modifiez le manifeste en changeant la classe de machine virtuelle.
    Par exemple, le cluster utilise la classe de machine virtuelle best-effort-xsmall pour le plan de contrôle et les nœuds worker.
    spec:
      topology:
        controlPlane:
          replicas: 3
          vmClass: best-effort-xsmall
          ...
        nodePools:
        - name: worker-nodepool-a1
          replicas: 3
          vmClass: best-effort-xsmall
          ...
    
    Modifiez la classe de machine virtuelle pour le plan de contrôle en guaranteed-large et la classe de machine virtuelle pour les nœuds worker en guaranteed-2xlarge.
    spec:
      topology:
        controlPlane:
          replicas: 3
          vmClass: guaranteed-large
          ...
        nodePools:
        - name: worker-nodepool-a1
          replicas: 3
          vmClass: guaranteed-2xlarge
          ...
    
  8. Pour appliquer les modifications, enregistrez le fichier dans l'éditeur de texte. Pour annuler les modifications, fermez l'éditeur sans enregistrer.

    Lorsque vous enregistrez le fichier, kubectl applique les modifications au cluster. En arrière-plan, TKG sur le Superviseur effectue une mise à jour continue du cluster TKG.

  9. Vérifiez que le cluster TKG est mis à jour avec la nouvelle classe de machine virtuelle.
    kubectl describe tanzukubernetescluster tkg-cluster-1

Mettre à l'échelle les volumes de nœuds de cluster TKG

Dans la spécification de cluster TKG pour les nœuds vous pouvez éventuellement déclarer un ou plusieurs volumes persistants pour le nœud. La déclaration d'un volume de nœuds est utile pour les composants à taux de variation élevée, tels que la base de données ectd sur le plan de contrôle, et l'exécution du conteneur et kubelet sur les nœuds worker.

Si vous souhaitez ajouter ou modifier un ou plusieurs volumes de nœuds après la création du cluster, gardez à l'esprit les considérations suivantes :
Nœud de volume Description

Les modifications du volume de nœuds worker sont autorisées

Après le provisionnement d'un cluster TKG, vous pouvez ajouter ou mettre à jour des volumes de nœuds worker. Lorsque vous lancez une mise à jour continue, le cluster est mis à jour avec le nouveau volume ou le volume modifié.

Avertissement : Si vous mettez à l'échelle le nœud worker avec un nouveau volume ou un volume modifié, les données du volume actuel sont supprimées lors de la mise à jour continue. Reportez-vous à l'explication qui suit.

Un volume déclaré pour un nœud de cluster TKG est traité comme étant éphémère. Un cluster TKG utilise une réclamation de volume persistant (PVC) dans l'espace de noms vSphere afin que la capacité du volume soit comptabilisée par rapport au quota de stockage du cluster TKG. Si vous augmentez la capacité d'un volume TKC, l'API de cluster Kubernetes (CAPI) déploiera de nouveaux workers avec une nouvelle PVC. TKG n'effectue aucune migration des données dans ce cas, mais Kubernetes planifie/replanifie les espaces de charge de travail en conséquence.

Les modifications du volume du nœud de plan de contrôle ne sont pas autorisées.

Après le provisionnement d'un cluster TKG, vous ne pouvez pas ajouter ou mettre à jour un volume de nœud de plan de contrôle. L'API du cluster Kubernetes (CAPI) interdit les modifications post-création de spec.toplogy.controlPlane.volumes.

Si vous tentez d'ajouter ou de modifier un volume de plans de contrôle après la création du cluster, la demande est refusée et vous recevez le message d'erreur « Les mises à jour de champs immuables ne sont pas autorisées ».

Une spécification de cluster extraite avec des volumes de nœuds déclarés est fournie pour le contexte. Reportez-vous à l'exemple de cluster TKG complet d'où cet extrait est pris si nécessaire : Exemple v1alpha3 : TKC avec stockage par défaut et volumes de nœuds.
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:
     ...