Deep Dive of the Day Planning a VKS 3.8 upgrade: chained cluster upgrades and the checks that gate them
VKS 3.8.0+v1.37 has been out since 22 October, and with Broadcom's launch post yesterday plenty of Supervisor owners will be planning the move. The headline feature for operators is the chained workload cluster upgrade: per the release notes, a VKS cluster can now move across up to three Kubernetes minor versions (N+3) in one operation. The blog adds the practical win: workers are cordoned and drained once for the whole journey, rather than at every intermediate version.
Before any of that, the service itself has to get there. The release notes say the Supervisor must already run VKS 3.5.0 or later to upgrade to 3.8, and VKS 3.8 needs a Supervisor Kubernetes version of at least 1.33. On Supervisor 9.1 with a Software Depot configured, use the vsphere-kubernetes-service-3.8.0+v1.37.yaml service definition; the legacy YAML shouldn't be used there and can't be used beyond October 2027.
The chained upgrade is gated rather than blind. Before it runs, pre-checks validate that the target version is available, that the upgrade path, ClusterClass and add-ons are compatible, and the cluster's UpdatesAvailable condition lists every target it considers viable. Upgrades are blocked while SystemChecksSucceeded is False, and changes that need a node rollout, such as a new vmClass or storageClass, are blocked too, so don't bundle a VM class change into the same window as a version jump.
ClusterClass is where most surprises live. VKS 3.8 removes builtin-generic-v3.1.0, v3.2.0 and v3.3.0, so any custom ClusterClass built on them needs migrating first. Separately, the notes ask that every cluster is on ClusterClass 3.6.0 or later before you upgrade the Supervisor to 9.1, or you may see system-initiated rolling updates. There's also a new inPlaceUpdateStrategy variable whose default, MinimizeSpareNodes, avoids creating a crowd of spare nodes at once.
Kubernetes 1.37 brings its own changes. Core add-ons move to the VKS Addons Framework, so custom parameters belong in AddonConfig resources; legacy objects such as ClusterBootstrap are ignored for 1.37 and creating new ones is blocked. The immutable Photon OS option restricts direct SSH to nodes, so move any SSH-based tooling first, and the vcf package CLI plugin is deprecated in favour of vcf addon. Among the known issues, a rollout can stall if a bootstrapping failure leaves a machine without a nodeRef, and the workaround there is Broadcom Support.
Edouard Topin's day-2 write-up is a good counterweight to the feature list: record the Supervisor, VKS service and cluster versions separately before planning, read PodDisruptionBudgets before maintenance rather than deleting them to unblock a drain, and allow spare capacity, IPs and storage for rolling node replacement. In a nested lab, that spare capacity is usually the thing you run out of first, so a single small cluster with one worker is the gentlest way to rehearse a chained upgrade before you try it on anything that matters.
Based on VKS 3.8 release notes (Broadcom TechDocs) Official VMware vSphere Kubernetes Service 3.8 (VMware VCF blog) Official Day-2 ops on VKS: lifecycle, upgrades, observability (Edouard Topin)
