Update a TKG 2.0 Cluster by Changing the VM Class Using Kubectl

You can update a workload cluster by changing the virtual machine class used to host the cluster nodes.

You can initiate a rolling update of a TKG 2.0 cluster by changing the VirtualMachineClass definition. New nodes based on the changed class will be rolled out and the old nodes are spun down.

Prerequisites

This task requires the use of the kubectl edit command. This command opens the cluster manifest in the text editor defined by your KUBE_EDITOR or EDITOR environment variable. When you save the file, the cluster is updated with the changes. To configure an editor for kubectl, see Configure a Text Editor for Kubectl.

Procedure

Authenticate with the Supervisor.

kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

Switch context to the vSphere Namespace where the target TKG cluster is provisioned.
```
kubectl config use-context SUPERVISOR-NAMESPACE
```

Describe the target TKG cluster and check the VM class.

v1alpha3 cluster:

kubectl describe tanzukubernetescluster CLUSTER-NAME

v1beta1 cluster:

kubectl describe cluster CLUSTER-NAME

List and describe the available VM classes in the namespace.
```
kubectl get virtualmachineclassbindings
```
Note: The VirtualMachineClass must be bound to the vSphere Namespace where the TKG cluster is provisioned.
Run the following command to edit the cluster manifest.
v1alpha3 cluster:
```
kubectl edit tanzukubernetescluster/CLUSTER-NAME
```
v1beta1 cluster:
```
kubectl edit cluster/CLUSTER-NAME
```

Edit the manifest by changing the VM class string.

For example, if you are using a v1alpah3 cluster, change the cluster manifest from using the guaranteed-medium VM class for worker nodes:

 topology:
    controlPlane:
      replicas: 3
      storageClass: vwk-storage-policy
      tkr:
        reference:
          name: v1.22.9---vmware.1-tkg.1.cc71bc8
      vmClass: guaranteed-medium
    nodePools:
    - name: worker-nodepool-a1
      replicas: 3
      storageClass: vwk-storage-policy
      tkr:
        reference:
          name: v1.22.9---vmware.1-tkg.1.cc71bc8
      vmClass: guaranteed-medium

To using the guaranteed-large VM class for worker nodes:

 topology:
    controlPlane:
      replicas: 3
      storageClass: vwk-storage-policy
      tkr:
        reference:
          name: v1.22.9---vmware.1-tkg.1.cc71bc8
      vmClass: guaranteed-medium
    nodePools:
    - name: worker-nodepool-a1
      replicas: 3
      storageClass: vwk-storage-policy
      tkr:
        reference:
          name: v1.22.9---vmware.1-tkg.1.cc71bc8
      vmClass: guaranteed-large

Similarly, if you have provisioned a v1beta1 cluster, update the value of variables.vmclass to the target VM class.

Save the changes you made to the manifest file.
When you save the file, kubectl applies the changes to the cluster. In the background, TKG controller provisions the new node VMs and spins down the old ones.
Verify that kubectl reports that the manifest edits were successfully recorded.
```
kubectl edit tanzukubernetescluster/tkgs-cluster-1
tanzukubernetescluster.run.tanzu.vmware.com/tkgs-cluster-1 edited
```
Note: If you receive an error, or kubectl does not report that the cluster manifest was successfully edited, make sure you have properly configured your default text editor using the KUBE_EDITOR environment variable. See Configure a Text Editor for Kubectl.
Verify that the cluster is updated.
v1alpha3 cluster:
```
kubectl get tanzukubernetescluster
```
v1beta1 cluster:
```
kubectl get cluster
```