• Kubernetes upgrades are often presented as straightforward, linear progressions: move from one version to the next, validate, and repeat. • This approach-commonly called the Sequential In-Place Upgrade-is proven, conservative, and widely adopted. • However, in modern enterprise platforms, upgrades span much more than just the Kubernetes version number. • They involve a complex interplay of: A management plane(Supervisor / platform services) Platform layers(VMware Kubernetes Service - VKS) Workload clusters Applicationswith varying levels of resilience and state Understanding both the technical requirements and the organizational realities is critical to helping teams choose the right upgrade model and avoid costly surprises. • Option 1: Sequential In-Place Upgrade The in-place model upgrades existing components layer by layer, modifying the running infrastructure. • Typical Flow Supervisor Cluster:1.29 → 1.30 VKS Service:Updated to support newer Kubernetes versions (e.g., v3.1 → v3.5) Workload Clusters:1.30 → 1.31 → 1.32 → 1.33 Why Teams Like It Reuses existing infrastructure:No need for massive spare capacity.

Article Summaries:

  • Kubernetes upgrades are often presented as straightforward, linear progressions: move from one version to the next, validate, and repeat. This approach-commonly called the Sequential In-Place Upgrade-is proven, conservative, and widely adopted. However, in modern enterprise platforms, upgrades span much more than just the Kubernetes version number. They involve a complex interplay of: - A management plane (Supervisor / platform services) - Platform layers (VMware Kubernetes Service - VKS) - Workload clusters - Applications with varying levels of resilience and state Understanding both the tech

Sources: