Sie können einen TKG-Dienstcluster durch Änderung der Knotenanzahl horizontal und durch Änderung der VM-Klasse zum Hosten der Knoten vertikal skalieren. Sie können auch Volumes skalieren, die an Clusterknoten angehängt sind.

Unterstützte manuelle Skalierungsvorgänge

In der Tabelle sind die unterstützten Skalierungsvorgänge für TKG-Cluster aufgeführt.
Tabelle 1. Unterstützte Skalierungsvorgänge für TKGS-Cluster
Knoten Horizontales Hochskalieren Horizontales Herunterskalieren Vertikale Skalierung Skalierung des Volumes
Steuerungsebene Ja Nein Ja Ja*
Worker Ja Ja Ja Ja
Berücksichtigen Sie die folgenden Aspekte:
  • Die Anzahl der Steuerungsebenen-Knoten muss ungerade sein, entweder 1 oder 3. Die horizontale Skalierung der Steuerungsebene wird unterstützt, aber das vertikale Skalieren der Steuerungsebene wird nicht unterstützt. Weitere Informationen finden Sie unter Horizontales Hochskalieren der Steuerungsebene.
  • Bei der vertikalen Skalierung eines Clusterknotens kann es vorkommen, dass Arbeitslasten mangels verfügbarer Ressourcen nicht mehr auf dem Knoten ausgeführt werden können. Aus diesem Grund wird horizontale Skalierung in der Regel bevorzugt. Weitere Informationen finden Sie unter Horizontales Hochskalieren der Worker-Knoten.
  • VM-Klassen sind nicht unveränderlich. Wenn Sie einen TKG-Cluster nach der Bearbeitung einer von diesem Cluster verwendeten VM-Klasse skalieren, verwenden neue Clusterknoten die aktualisierte Klassendefinition, aber vorhandene Clusterknoten verwenden weiterhin die anfängliche Klassendefinition, was zu einer Nichtübereinstimmung führt. Weitere Informationen finden Sie unter Informationen zu VM-Klassen.
  • Worker-Knoten-Volumes können nach der Bereitstellung geändert werden. Ebenso können Steuerungsebenenknoten geändert werden, sofern Sie vSphere 8 U3 oder höher und eine kompatible TKr verwenden. Weitere Informationen finden Sie unter Skalieren von Cluster-Knoten-Volumes.

Skalierungsvoraussetzungen: Konfigurieren der Kubectl-Bearbeitung

Um einen TKG-Cluster zu skalieren, aktualisieren Sie das Cluster-Manifest mit dem Befehl kubectl edit CLUSTER-KIND/CLUSTER-NAME. Wenn Sie die Manifest-Änderungen speichern, wird der Cluster mit den Änderungen aktualisiert. Weitere Informationen finden Sie unter Konfigurieren eines Texteditors für Kubectl.

Beispiel: 
kubectl edit tanzukubernetescluster/tkg-cluster-1
tanzukubernetescluster.run.tanzu.vmware.com/tkg-cluster-1 edited
Um Änderungen zu verwerfen, schließen Sie den Editor, ohne zu speichern. 
kubectl edit tanzukubernetescluster/tkg-cluster-1
Edit cancelled, no changes made.

Horizontales Hochskalieren der Steuerungsebene

Skalieren Sie einen TKG-Cluster horizontal, indem Sie die Anzahl der Steuerungsebenenknoten von 1 auf 3 erhöhen.
Hinweis: Produktionscluster benötigen 3 Knoten der Steuerungsebene.
  1. Melden Sie sich bei Supervisor an. 
    kubectl vsphere login --server=SUPERVISOR-IP-ADDRESS --vsphere-username USERNAME
  2. Wechseln Sie den Kontext zum vSphere-Namespace, in dem der TKG-Cluster ausgeführt wird.
    kubectl config use-context tkg-cluster-ns
  3. Listet die Kubernetes-Cluster auf, die im vSphere-Namespace ausgeführt werden.

    Verwenden Sie die folgende Syntax:

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Beispielsweise für einen v1alpha3-API-Cluster: 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Beispielsweise für einen v1beta1-API-Cluster: 
    kubectl get cluster -n tkg-cluster-ns
  4. Rufen Sie die Anzahl der im Zielcluster ausgeführten Knoten ab.

    Für einen v1alpha3-API-Cluster: 

    kubectl get tanzukubernetescluster tkg-cluster-1
    Der TKG-Cluster verfügt über 1 Steuerungsebenenknoten und 3 Worker-Knoten. 
    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

    Für einen v1beta1-API-Cluster: 

    kubectl get cluster tkg-cluster-1
  5. Führen Sie zum Laden des Cluster-Manifests zur Bearbeitung den Befehl kubectl edit aus.
    Für einen v1alpha3-API-Cluster: 
    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Für einen v1beta1-API-Cluster: 
    kubectl edit cluster/tkg-cluster-1

    Das Cluster-Manifest wird in dem Texteditor geöffnet, der von den Umgebungsvariablen KUBE_EDITOR oder EDITOR definiert wird.

  6. Erhöhen Sie die Anzahl der Steuerungsebenenknoten im Abschnitt spec.topology.controlPlane.replicas des Manifests von 1 auf 3.
    Für einen v1alpha3-API-Cluster: 
    ...
spec:
  topology:
    controlPlane:
      replicas: 1
...

    ...
spec:
  topology:
    controlPlane:
      replicas: 3
...
    Für einen v1beta1-API-Cluster: 
    ...
spec:
  ...
  topology:
    class: tanzukubernetescluster
    controlPlane:
      metadata: {}
      replicas: 1
    variables:
...

    ...
spec:
  ...
  topology:
    class: tanzukubernetescluster
    controlPlane:
      metadata: {}
      replicas: 3
    variables:
...
  7. Speichern Sie die Datei im Texteditor, um die Änderungen zu übernehmen. (Schließen Sie zum Abbrechen den Editor ohne Speichern.)

    Wenn Sie die Manifest-Änderungen speichern, wendet kubectl die Änderungen auf den Cluster an. Im Hintergrund stellt der VM-Dienst auf Supervisor den neuen Steuerungsebenenknoten bereit.

  8. Vergewissern Sie sich, dass die neuen Knoten hinzugefügt wurden.

    Für einen v1alpha3-API-Cluster:

    kubectl get tanzukubernetescluster tkg-cluster-1
    Die horizontal hochskalierte Steuerungsebene verfügt jetzt über 3 Knoten. 
    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

    Für einen v1beta1-API-Cluster: 

    kubectl get cluster tkg-cluster-1

Horizontales Hochskalieren der Worker-Knoten

Sie können einen TKG-Cluster horizontal skalieren, indem Sie die Zahl der Worker-Knoten erhöhen.

  1. Melden Sie sich bei Supervisor an. 
    kubectl vsphere login --server=SVC-IP-ADDRESS --vsphere-username USERNAME
  2. Wechseln Sie den Kontext zum vSphere-Namespace, in dem der TKG-Cluster ausgeführt wird.
    kubectl config use-context tkg-cluster-ns
  3. Listet die Kubernetes-Cluster auf, die im vSphere-Namespace ausgeführt werden.

    Verwenden Sie die folgende Syntax:

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Beispielsweise für einen v1alph3-API-Cluster: 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Beispielsweise für einen v1beta1-API-Cluster: 
    kubectl get cluster -n tkg-cluster-ns
  4. Rufen Sie die Anzahl der im Zielcluster ausgeführten Knoten ab.

    Für einen v1alpha3-API-Cluster:

    kubectl get tanzukubernetescluster tkg-cluster-1
    Der folgende Cluster hat z. B. 3 Steuerungsebenenknoten und 3 Worker-Knoten. 
    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
    Für einen v1beta1-API-Cluster: 
    kubectl get cluster tkg-cluster-1
  5. Führen Sie zum Laden des Cluster-Manifests zur Bearbeitung den Befehl kubectl edit aus.

    Für einen v1alpha3-API-Cluster:

    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Für einen v1beta1-API-Cluster: 
    kubectl edit cluster/tkg-cluster-1

    Das Cluster-Manifest wird in dem Texteditor geöffnet, der von den Umgebungsvariablen KUBE_EDITOR oder EDITOR definiert wird.

  6. Erhöhen Sie die Anzahl der Worker-Knoten, indem Sie den Wert spec.topology.nodePools.NAME.replicas für den Ziel-Worker-Knotenpool bearbeiten.
    Für einen v1alpha3-API-Cluster: 
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 3
...
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 4
...
    Für einen v1beta1-API-Cluster: 
    ...
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. Um die Änderungen anzuwenden, speichern Sie die Datei im Texteditor. Um die Änderungen zu verwerfen, schließen Sie den Editor ohne zu speichern.

    Wenn Sie die Datei speichern, wendet kubectl die Änderungen auf den Cluster an. Der VM-Dienst im Supervisor stellt im Hintergrund den neuen Worker-Knoten bereit.

  8. Vergewissern Sie sich, dass die neuen Knoten hinzugefügt wurden.

    Für einen v1alpha3-API-Cluster:

    kubectl get tanzukubernetescluster tkg-cluster-1
    Durch das horizontale Hochskalieren ergeben sich 4 Worker-Knoten für den Cluster. 
    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

    Für einen v1beta1-API-Cluster: 

    kubectl get cluster tkg-cluster-1

Horizontales Herunterskalieren der Worker-Knoten

Sie können einen TKG-Cluster vertikal skalieren, indem Sie die Zahl der Worker-Knoten verringern.

  1. Melden Sie sich bei Supervisor an. 
    kubectl vsphere login --server=SVC-IP-ADDRESS --vsphere-username USERNAME
  2. Wechseln Sie den Kontext zum vSphere-Namespace, in dem der TKG-Cluster ausgeführt wird.
    kubectl config use-context tkg-cluster-ns
  3. Listet die Kubernetes-Cluster auf, die im vSphere-Namespace ausgeführt werden.

    Verwenden Sie die folgende Syntax:

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Beispielsweise für einen v1alph3-API-Cluster: 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Beispielsweise für einen v1beta1-API-Cluster: 
    kubectl get cluster -n tkg-cluster-ns
  4. Rufen Sie die Anzahl der im Zielcluster ausgeführten Knoten ab.
    kubectl get tanzukubernetescluster tkg-cluster-1
  5. Rufen Sie die Anzahl der im Zielcluster ausgeführten Knoten ab.

    Für einen v1alpha3-API-Cluster:

    kubectl get tanzukubernetescluster tkg-cluster-1
    Der folgende Cluster hat z. B. 3 Steuerungsebenenknoten und 4 Worker-Knoten. 
    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
    Für einen v1beta1-API-Cluster: 
    kubectl get cluster tkg-cluster-1
  6. Führen Sie zum Laden des Cluster-Manifests zur Bearbeitung den Befehl kubectl edit aus.

    Für einen v1alpha3-API-Cluster:

    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Für einen v1beta1-API-Cluster: 
    kubectl edit cluster/tkg-cluster-1

    Das Cluster-Manifest wird in dem Texteditor geöffnet, der von den Umgebungsvariablen KUBE_EDITOR oder EDITOR definiert wird.

  7. Verringern Sie die Anzahl der Worker-Knoten, indem Sie den Wert spec.topology.nodePools.NAME.replicas für den Ziel-Worker-Knotenpool bearbeiten.
    Für einen v1alpha3-API-Cluster: 
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 4
...
    ...
spec:
  topology:
    ...
    nodePools:
    - name: worker-1
      replicas: 3
...
    Für einen v1beta1-API-Cluster: 
    ...
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. Um die Änderungen anzuwenden, speichern Sie die Datei im Texteditor. Um die Änderungen zu verwerfen, schließen Sie den Editor ohne zu speichern.

    Wenn Sie die Datei speichern, wendet kubectl die Änderungen auf den Cluster an. Der VM-Dienst im Supervisor stellt im Hintergrund den neuen Worker-Knoten bereit.

  9. Vergewissern Sie sich, dass die Worker-Knoten entfernt wurden.

    Für einen v1alpha3-API-Cluster:

    kubectl get tanzukubernetescluster tkg-cluster-1
    Durch das horizontale Herunterskalieren ergeben sich 3 Worker-Knoten für den Cluster. 
    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

    Für einen v1beta1-API-Cluster: 

    kubectl get cluster tkg-cluster-1

Vertikale Skalierung eines Clusters

TKG auf Supervisor unterstützt vertikale Skalierung für Steuerungsebenen- und Worker-Knoten des Clusters. Sie führen die vertikale Skalierung eines TKG-Clusters durch, indem Sie die für Clusterknoten verwendete Klasse der virtuellen Maschine ändern. Die von Ihnen verwendete VM-Klasse muss an den vSphere-Namespace gebunden werden, in dem der TKG-Cluster bereitgestellt wird.

TKG auf Supervisor unterstützt vertikale Skalierung über den im System integrierten Mechanismus für parallele Aktualisierungen. Wenn Sie die VirtualMachineClass-Definition ändern, führt das System neue Knoten mit dieser Klasse ein und fährt die alten Knoten herunter. Weitere Informationen hierzu finden Sie unter Aktualisieren von TKG-Dienstclustern.

  1. Melden Sie sich bei Supervisor an.
    kubectl vsphere login --server=SVC-IP-ADDRESS --vsphere-username USERNAME
  2. Wechseln Sie den Kontext zum vSphere-Namespace, in dem der TKG-Cluster ausgeführt wird.
    kubectl config use-context tkg-cluster-ns
  3. Listet die Kubernetes-Cluster auf, die im vSphere-Namespace ausgeführt werden.

    Verwenden Sie die folgende Syntax:

    kubectl get CLUSTER-KIND -n tkg-cluster-ns
    Beispielsweise für einen v1alph3-API-Cluster: 
    kubectl get tanzukubernetescluster -n tkg-cluster-ns
    Beispielsweise für einen v1beta1-API-Cluster: 
    kubectl get cluster -n tkg-cluster-ns
  4. Beschreiben Sie den TKG-Zielcluster und überprüfen Sie die VM-Klasse.

    Für einen v1alpha3-API-Cluster:

    kubectl describe tanzukubernetescluster tkg-cluster-1

    Der folgende Cluster verwendet z. B. die VM-Klasse „best-effort-medium“.

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

    Für einen v1beta1-API-Cluster:

    kubectl describe cluster tkg-cluster-1

    Der folgende Cluster verwendet z. B. die VM-Klasse „best-effort-medium“.

    ...
Topology:
      ...
    Variables:
      ...
      Name:   vmClass
      Value:  best-effort-medium
    ...
    Hinweis: Standardmäßig ist die VM-Klasse für v1beta1-API-Cluster global als einzelne Variable festgelegt. Sie können diese Einstellung überschreiben und eine andere VM-Klasse für Steuerungsebenen- und Worker-Knoten verwenden. Weitere Informationen finden Sie unter vmClass in der API-Referenz.
  5. Erstellen Sie eine Liste und eine Beschreibung der verfügbaren VM-Klassen.
    kubectl get virtualmachineclass
    kubectl describe virtualmachineclass
    Hinweis: Die VM-Klasse muss an den vSphere-Namespace gebunden werden. Weitere Informationen finden Sie unter Verwenden von VM-Klassen mit TKG-Dienstclustern.
  6. Öffnen Sie zum Bearbeiten des Manifests des Zielclusters.

    Für einen v1alpha3-API-Cluster:

    kubectl edit tanzukubernetescluster/tkg-cluster-1
    Für einen v1beta1-API-Cluster: 
    kubectl edit cluster/tkg-cluster-1

    Das Cluster-Manifest wird in dem Texteditor geöffnet, der von den Umgebungsvariablen KUBE_EDITOR oder EDITOR definiert wird.

  7. Bearbeiten Sie das Manifest, indem Sie die VM-Klasse ändern.
    Ändern Sie für einen v1alpha3-API-Cluster die VM-Klasse für die Steuerungsebene in guaranteed-medium und die VM-Klasse für Worker-Knoten in guaranteed-large. 
    spec:
  topology:
    controlPlane:
      replicas: 3
      vmClass: guaranteed-medium
      ...
    nodePools:
    - name: worker-nodepool-a1
      replicas: 3
      vmClass: guaranteed-large
      ...
    Ändern Sie für einen v1beta-API-Cluster die VM-Klasse in guaranteed-large. 
    ...
Topology:
      ...
    Variables:
      ...
      Name:   vmClass
      Value:  guaranteed-large
    ...
  8. Um die Änderungen anzuwenden, speichern Sie die Datei im Texteditor. Um die Änderungen zu verwerfen, schließen Sie den Editor ohne zu speichern.

    Wenn Sie die Datei speichern, wendet kubectl die Änderungen auf den Cluster an. Im Hintergrund führt TKG auf Supervisor ein paralleles Update des TKG-Clusters durch.

  9. Stellen Sie sicher, dass der TKG-Cluster mit der neuen VM-Klasse aktualisiert wurde.

    Für einen v1alpha3-API-Cluster:

    kubectl describe tanzukubernetescluster tkg-cluster-1

    Für einen v1beta1-API-Cluster:

    kubectl describe cluster tkg-cluster-1

Skalieren von Cluster-Knoten-Volumes

In der TKG-Clusterspezifikation für Knoten können Sie optional ein oder mehrere persistente Volumes für den Knoten deklarieren. Das Deklarieren eines Knoten-Volumes eignet sich für Komponenten mit hohen Änderungsraten, wie z. B. die Container-Laufzeit und kubelet auf Worker-Knoten.

Wenn Sie nach der Clustererstellung ein oder mehrere Knoten-Volumes hinzufügen oder ändern möchten, bedenken Sie Folgendes:
Volume-Knoten Beschreibung

Änderungen des Worker-Knoten-Volumes sind zulässig

Nach der Bereitstellung eines TKG-Clusters können Sie Worker-Knoten-Volumes hinzufügen oder aktualisieren. Wenn Sie ein paralleles Update initiieren, wird der Cluster mit dem neuen oder geänderten Volume aktualisiert.

Warnung: Wenn Sie den Worker-Knoten mit einem neuen oder geänderten Volume skalieren, werden die Daten im aktuellen Volume während des parallelen Updates gelöscht. Weitere Informationen finden Sie in der folgenden Erläuterung.

Ein für einen TKG-Clusterknoten deklariertes Volume wird als flüchtig behandelt. Ein TKG-Cluster verwendet eine Beanspruchung eines dauerhaften Volumes (Persistent Volume Claim, PVC) im vSphere Namespace, sodass die Volume-Kapazität dem Speicherkontingent des TKG-Clusters angerechnet wird. Wenn Sie die Kapazität eines TKC-Volumes erhöhen, stellt die Kubernetes-Cluster-API (CAPI) neue Worker mit einer neuen PVC bereit. TKG führt in diesem Fall keine Datenmigration durch. Kubernetes plant Arbeitslast-Pods entsprechend (neu).

Änderungen des Knoten-Volumes der Steuerungsebene sind zulässig, wenn Sie vSphere 8 U3 oder höher verwenden

Wenn Sie vSphere 8 U3 oder höher und ein kompatibles Tanzu Kubernetes Release verwenden, können Sie ein Knoten-Volume der Steuerungsebene nach der Bereitstellung eines TKG-Dienstclusters hinzufügen oder aktualisieren.

Wenn Sie vSphere 8 U3 oder höher nicht verwenden, lässt die Kubernetes-Cluster-API (CAPI) keine Änderungen an spec.toplogy.controlPlane.volumes nach der Erstellung zu.

Der Versuch, ein Steuerungsebenen-Volume nach der Clustererstellung hinzuzufügen oder zu ändern, wird zurückgewiesen, und Sie erhalten die Fehlermeldung „Aktualisierungen unveränderlicher Felder sind nicht zulässig“.

Bei Folgenden handelt es sich um einen Auszug aus einer Clusterspezifikation, die auf der v1alpha3-API mit deklarierten Knoten-Volumes basiert. Weitere Informationen finden Sie im vollständigen Beispiel eines TKG-Clusters, aus dem dieser Auszug nach Bedarf entnommen wird: v1alpha3-Beispiel: TKC mit Standardspeicher und Knoten-Volumes. Ein Beispiel für einen v1beta1-API-Cluster finden Sie unter v1beta1-Beispiel: Benutzerdefinierter Cluster basierend auf der standardmäßigen ClusterClass.

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