Error: "Missing compatible KR/OSImage" when provisioning TKG Clusters due to deactivated Kubernetes Release due to override-k8s-semver-version

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

TKG cluster provisioning, scaling, or upgrades fail with the following error message: Could not resolve KR/OSImage Missing compatible KR/OSImage for the cluster Control Plane, filters: {k8sVersionPrefix: <version>, osImageSelector: content-library=<id>,os-name=<os>,os-version=<version>}

When checking the Kubernetes Release (KR) status via kubectl get kr <version> --show-labels, the READY state is False, and the deactivated= label is present.

You had ruled out the KBs below where there are no missing annotations and the resolve-os-image is pointing to os-name instaed of the vmi name:

https://knowledge.broadcom.com/external/article/414444/deployment-of-ubuntu-osbased-nodes-on-gu.html
https://knowledge.broadcom.com/external/article/424336/guest-cluster-upgrade-fails-with-tkr-res.html

Note:  deactivated= label being present with above ruled out is where this condition applies to this KB.

Environment

vSphere with Tanzu (Supervisor) Tanzu Kubernetes Grid (TKG) Service

Cause

The requested Kubernetes Release has been explicitly superseded by a newer ClusterVirtualMachineImage (CVMI) or OVF template synced to the Subscribed Content Library. The newer template contains the property vmware-system.kr.override-k8s-semver-version, which forces the Supervisor controller to apply the deactivated label to the older KR globally across the Supervisor.

As documented in Understanding VKR Status, this override mechanism is triggered "only if a critical bug is identified in an existing patch." The system automatically deactivates the older KR to prevent the deployment of clusters with known severe regressions.

Resolution

The recommended resolution is to upgrade the affected workload cluster (or update its deployment manifest) to target a higher, active Kubernetes version that does not contain the known regressions. Once the cluster specification points to an active, non-superseded Kubernetes Release, provisioning and lifecycle operations will succeed safely.

Important: If the newer, superseding OVF/CVMI is actively in use by other clusters on the same Supervisor, it cannot be deleted from the Content Library to temporarily force the reactivation of the older release. Deleting the active OVF will break lifecycle management (such as auto-scaling and node repair) for all newer clusters relying on it.

Additional Information

For more details on KR/VKR lifecycle and deactivation conditions, refer to the official documentation: Administering Kubernetes Releases for TKG Service Clusters