Vous pouvez mettre à l'échelle un cluster TKG 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 attachés à des nœuds de cluster.

Opérations de mise à l'échelle manuelles 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 TKGS
Nœud Montée en charge horizontale Réduction de charge horizontale Échelle verticale Échelle volumétrique
Plan de contrôle Oui Non Oui Yes*
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. Reportez-vous à la section Monter en charge le plan de contrôle.
  • 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. Ainsi, la mise à l'échelle horizontale est généralement l'approche préférée. Reportez-vous à la section Monter en charge des nœuds worker.
  • 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. Reportez-vous à la section À propos des classes de machines virtuelles.
  • Les volumes de nœuds worker peuvent être modifiés après le provisionnement. Les nœuds de plan de contrôle likewise peuvent être modifiés à condition que vous utilisiez vSphere 8 U3 ou version ultérieure et une TKR compatible. Reportez-vous à la section Mettre à l'échelle les volumes de nœuds de cluster.

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 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.

    Utilisez la syntaxe suivante :

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Par exemple, pour un cluster d'API v1alpha3 : 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Par exemple, pour un cluster d'API v1beta1 : 
    kubectl get cluster -n tkg-cluster-ns
  4. Obtenez le nombre de nœuds en cours d'exécution dans le cluster cible.

    Pour un cluster d'API v1alpha3 : 

    kubectl get tanzukubernetescluster tkg-cluster-1
    Par exemple, le cluster TKG dispose d'un nœud de plan de contrôle et de trois 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

    Pour un cluster d'API v1beta1 : 

    kubectl get cluster tkg-cluster-1
  5. Chargez le manifeste du cluster afin de le modifier à l'aide de la commande kubectl edit.
    Pour un cluster d'API v1alpha3 : 
    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Pour un cluster d'API v1beta1 : 
    kubectl edit cluster/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.
    Pour un cluster d'API v1alpha3 : 
    ...
spec:
  topology:
    controlPlane:
      replicas: 1
...

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

    ...
spec:
  ...
  topology:
    class: tanzukubernetescluster
    controlPlane:
      metadata: {}
      replicas: 3
    variables:
...
  7. Enregistrez le fichier dans l'éditeur de texte pour appliquer les modifications. (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 du plan de contrôle.

  8. Vérifiez que les nouveaux nodes sont ajoutés.

    Pour un cluster d'API v1alpha3 :

    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

    Pour un cluster d'API v1beta1 : 

    kubectl get cluster tkg-cluster-1

Monter en charge des nœuds worker

Vous pouvez effectuer une montée en charge d'un cluster TKG 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.

    Utilisez la syntaxe suivante :

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Par exemple, pour un cluster d'API v1alph3 : 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Par exemple, pour un cluster d'API v1beta1 : 
    kubectl get cluster -n tkg-cluster-ns
  4. Obtenez le nombre de nœuds en cours d'exécution dans le cluster cible.

    Pour un cluster d'API v1alpha3 :

    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
    Pour un cluster d'API v1beta1 : 
    kubectl get cluster tkg-cluster-1
  5. Chargez le manifeste du cluster afin de le modifier à l'aide de la commande kubectl edit.

    Pour un cluster d'API v1alpha3 :

    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Pour un cluster d'API v1beta1 : 
    kubectl edit cluster/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.
    Pour un cluster d'API v1alpha3 : 
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 3
...
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 4
...
    Pour un cluster d'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. 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 nouveaux nodes sont ajoutés.

    Pour un cluster d'API v1alpha3 :

    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

    Pour un cluster d'API v1beta1 : 

    kubectl get cluster tkg-cluster-1

Réduire la charge des nœuds worker

Vous pouvez réduire la charge d'un cluster TKG 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.

    Utilisez la syntaxe suivante :

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Par exemple, pour un cluster d'API v1alph3 : 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Par exemple, pour un cluster d'API v1beta1 : 
    kubectl get cluster -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
  5. Obtenez le nombre de nœuds en cours d'exécution dans le cluster cible.

    Pour un cluster d'API v1alpha3 :

    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
    Pour un cluster d'API v1beta1 : 
    kubectl get cluster tkg-cluster-1
  6. Chargez le manifeste du cluster afin de le modifier à l'aide de la commande kubectl edit.

    Pour un cluster d'API v1alpha3 :

    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Pour un cluster d'API v1beta1 : 
    kubectl edit cluster/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. 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.
    Pour un cluster d'API v1alpha3 : 
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 4
...
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 3
...
    Pour un cluster d'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. 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.

  9. Vérifiez que les nœuds worker ont été supprimés.

    Pour un cluster d'API v1alpha3 :

    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

    Pour un cluster d'API v1beta1 : 

    kubectl get cluster tkg-cluster-1

Mettre à l'échelle un cluster verticalement

TKG 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 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 Mise à jour des clusters de services TKG.

  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.

    Utilisez la syntaxe suivante :

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Par exemple, pour un cluster d'API v1alph3 : 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Par exemple, pour un cluster d'API v1beta1 : 
    kubectl get cluster -n tkg-cluster-ns
  4. Décrivez le cluster TKG cible et vérifiez la classe de machine virtuelle.

    Pour un cluster d'API v1alpha3 :

    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: best-effort-medium
      ...
    nodePools:
    - name: worker-nodepool-a1
      replicas: 3
      vmClass: best-effort-medium
      ...

    Pour un cluster d'API v1beta1 :

    kubectl describe cluster tkg-cluster-1

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

    ...
Topology:
      ...
    Variables:
      ...
      Name:   vmClass
      Value:  best-effort-medium
    ...
    Note : Pour les clusters d'API v1beta1, par défaut, la vmClass est définie globalement en tant que variable unique. Vous pouvez remplacer ce paramètre et utiliser une classe de machine virtuelle différente pour le plan de contrôle et les nœuds worker. Reportez-vous à la section vmClass dans la référence de l'API.
  5. Répertoriez et décrivez les classes de machines virtuelles disponibles.
    kubectl get virtualmachineclass
    kubectl describe virtualmachineclass
    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 de Service TKG.
  6. Ouvrez pour modifier le manifeste du cluster cible.

    Pour un cluster d'API v1alpha3 :

    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Pour un cluster d'API v1beta1 : 
    kubectl edit cluster/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.
    Pour un cluster d'API v1alpha3, modifiez la classe de machine virtuelle pour le plan de contrôle en guaranteed-medium et la classe de machine virtuelle pour les nœuds worker en guaranteed-large. 
    spec:
  topology:
    controlPlane:
      replicas: 3
      vmClass: guaranteed-medium
      ...
    nodePools:
    - name: worker-nodepool-a1
      replicas: 3
      vmClass: guaranteed-large
      ...
    Pour un cluster d'API v1beta, remplacez la classe de machine virtuelle par guaranteed-large. 
    ...
Topology:
      ...
    Variables:
      ...
      Name:   vmClass
      Value:  guaranteed-large
    ...
  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.

    Pour un cluster d'API v1alpha3 :

    kubectl describe tanzukubernetescluster tkg-cluster-1

    Pour un cluster d'API v1beta1 :

    kubectl describe cluster tkg-cluster-1

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

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 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 du plan de contrôle sont autorisées si vous utilisez vSphere 8 U3 ou version ultérieure

Si vous utilisez vSphere 8 U3 ou version ultérieure et une version de Tanzu Kubernetes compatible, vous pouvez ajouter ou mettre à jour un volume de nœud de plan de contrôle après le provisionnement d'un cluster de services TKG.

Si vous n'utilisez pas vSphere 8 U3 ou version ultérieure, l'API de cluster Kubernetes (CAPI) interdit les modifications post-création pour 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 ».

La spécification de cluster suivante extraite est basée sur l'API v1alpha3 avec les volumes de nœuds déclarés. 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. Pour obtenir un exemple de cluster d'API v1beta1, reportez-vous à la section Exemple v1beta1 : cluster par défaut basé sur la ClusterClass par défaut.

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:
     ...