Missing Upgrade Option for Workload Clusters in TMC SM

Products

• VMware Tanzu Mission Control - SM

Issue/Introduction

• After upgrading TMC SM to version 1.4.x, the option to upgrade workload clusters to a newer Kubernetes version is missing in the TMC GUI for specific clusters.
  
  
• In the TMC UI Clusters view, the affected clusters show a Health status of 'Healthy' and a Status of 'Ready' (e.g., running 'v1.32.10+vmware.1-fips'), but they lack the upgrade option next to their version.
  
  
• Other clusters running the exact same Kubernetes version in the same environment successfully display the upgrade option.
  
  
  
  
• Connect to the vSphere Supervisor via CLI and list the clusters:
  
  

  kubectl get cluster -A

  
  
  Observation: The output shows a discrepancy in the 'CLUSTERCLASS' column. The affected clusters are using an older topology class (e.g., 'builtin-generic-v3.3.0'), while the clusters showing the upgrade option are on a newer class (e.g., 'builtin-generic-v3.4.0').
  
  
• Within the same supervisor CLI session, check the specific cluster conditions:
  
  

  kubectl get cluster <name-of-the-cluster> -n <namespace> -o yaml | grep -iA 5 "conditions"

  Observation: The output displays 'type: Ready' and 'status: "True"', confirming the issue is not caused by an underlying infrastructure error or a stuck reconciliation state.

 

Cause

While the Kubernetes versions are identical, the underlying infrastructure blueprints differ. The clusters missing the upgrade option are running on an older, deprecated topology class (e.g., builtin-generic-v3.3.0). TMC SM performs a pre-flight compatibility check against the cluster's topology blueprint. Because older ClusterClasses do not support target Kubernetes releases like v1.33+, TMC SM intentionally suppresses the upgrade indicator to prevent users from initiating an unsupported upgrade path.

Resolution

Update the workload cluster's underlying ClusterClass to a compatible version (e.g., builtin-generic-v3.4.0) via the Supervisor cluster CLI:

1. Log into the vSphere Supervisor where the affected workload cluster is managed.

2. Identify the exact name and namespace of the affected workload cluster by listing all clusters in the environment:
   

   kubectl get cluster -A

3. Edit the cluster configuration using the kubectl CLI:

   kubectl edit cluster <name-of-the-cluster> -n <namespace>
   

4. Verify there are no blocking annotations under the metadata.annotations section.
   Note: Ensure kubernetes.vmware.com/skip-auto-cc-rebase: "true" is not present. If this annotation is present, it must be removed to allow the upgrade without triggering webhook denial errors.

5. Scroll down to the spec.topology.class field.

6. Change the value from the older class to the v3.4.0 class:

   • Example:- Change from: builtin-generic-v3.3.0 (or older)

   • Example:- Change to: builtin-generic-v3.4.0

7. Save your changes and exit the editor.

8. Monitor the cluster as the new topology is rolled out across the nodes:

   kubectl get cluster <name-of-the-cluster> -n <namespace> -w
   

9. Once the cluster finishes its rolling update and the conditions return to Ready: True, refresh your TMC SM GUI.

10. Log back into the TMC SM GUI and verify the upgrade option is now available next to the Kubernetes version of the workload cluster.

Additional Information

• VKS v3.4 Requirements: Existing clusters must rebase to builtin-generic-v3.4.0 before or during any Kubernetes v1.33+ upgrade.

• For resolving admission webhook errors if the rebase annotation is present, reference Broadcom KB 414721.

• For the architectural explanation of TMC hiding upgrade paths, reference Broadcom KB 430209.