vSphere with Tanzu - Upgrade, Support and Kubernetes Versions

June 01, 2022


vSphere with Tanzu enables vSphere administrators to provision enterprise-grade Kubernetes to run natively on vSphere. You can use vSphere with Tanzu to transform vSphere into a platform for running Kubernetes workloads natively on the hypervisor layer. Tanzu Kubernetes Cluster is a full distribution of the open-source Kubernetes container orchestration platform built, signed, and supported by VMware. You can provision and operate Tanzu Kubernetes clusters on the Supervisor Cluster by using the Tanzu Kubernetes Grid Service. vSphere with Tanzu and Tanzu Kubernetes Clusters run on two independent Kubernetes distributions and have different support policies. 

vSphere with Tanzu uses the upstream Kubernetes software distribution provided by VMware Tanzu Kubernetes releases (TKr), signed and supported by VMware. This Kubernetes software distribution is not a fork of the upstream Kubernetes. It is a distribution of Kubernetes that has been tested, signed, and supported by VMware. Therefore the support policy for vSphere with Tanzu closely follows the upstream Kubernetes support policy. 

This page is intended for vSphere Administrators, DevOps, and Developers working with vSphere with Tanzu to be used as a reference for the Kubernetes Policy of vSphere with Tanzu. You can find the release cadence, support, upgrade path, and other details. 

Release Cadence

Since vSphere with Tanzu consumes upstream Kubernetes versions as provided by TKr, the upstream Kubernetes policies have an impact on the release cadence and the support policies for Kubernetes supported by vSphere with Tanzu. The following are some key policies of upstream Kubernetes-

  • Upstream Kubernetes will follow three releases per year cadence. 

  • Upstream Kubernetes project maintains release branches for the most recent three minor releases 

  • Kubernetes project policies require sequential upgrades, skipping minor versions is not supported. 


Source:  Kubernetes Version Skew Policy, Kubernetes Release Cadence


Kubernetes Versions in Supervisor

Every vCenter release (major, update, or patch releases) will have three versions of Kubernetes in Supervisor. Newer version of Kubernetes may be released in any release of the vCenter (Major, Update or patch release). Availability of the new versions of Kubernetes in vSphere with Tanzu follows the release of upstream Kubernetes version and the timeline of release depends on the quantum on changes in the upstream Kubernetes release. Whenever Supervisor adds a newer Kubernetes version, the oldest version goes out of support. For example, here is a sample of vCenter releases. 


vCenter Release

Kubernetes Versions in Supervisor


7.0 U1d

1.18, 1.17, 1.16


7.0 U2

1.19,  1.18, 1.17, 1.16

Support for 1.16 was dropped and 1.19 added

7.0 U2a

1.19 , 1.18, 1.17

No new version added, or dropped

7.0 U2b

1.19, 1.18, 1.17

No new version added, or dropped

7.0 U2c

1.20, 1.19, 1.18, 1.17

Support for 1.17 was dropped and 1.20 added


Supported versions of upstream Kubernetes in vCenter
You can find the full list of Kubernetes versions supported in vCenter below. 


Release Timeline

vCenter Version

Supported Kubernetes Version in the Release


VC 7.0.0



7.0.0 A

1.16, 1.17


7.0.0 B

1.16, 1.17


7.0.0 C

1.16, 1.17, 1.18


7.0 U1

1.16, 1.17, 1.18


7.0. U1 C

1.16, 1.17, 1.18


7.0 U1 d

1.16, 1.17, 1.18


7.0 U2

1.16, 1.17, 1.18, 1.19


7.0 U2 a

1.17, 1.18,1.19


7.0 U2 b

1.17, 1.18, 1.19


7.0 U2 c

1.17, 1.18, 1.19, 1.20


7.0 U2 d

1.18, 1.19, 1.20


7.0 U3 c

1.18, 1.19, 1.20, 1.21


7.0 U3 d

1.19, 1.20, 1.21


Sequential Upgrade Requirement

Upstream Kubernetes requires upgrades to be sequential, (i.e upgrade to the next minor version only). Since vSphere with Tanzu packages three Kubernetes versions, vSphere administrator will not have to upgrade to the immediate next version of vSphere with Tanzu, but will have a choice of upgrade paths, depending on the current version of vCenter. See Upgrade Path Rules here


Support Policy

Although vSphere with Tanzu is part of vCenter, since it packages a distribution of upstream Kubernetes, the support policy of vSphere with Tanzu is similar to that of the upstream Kubernetes. 

Support for up to 3 most recent upstream Kubernetes release 

The latest update to the Kubernetes release cadence has been published in the official Kubernetes blog. As per this, Kubernetes will follow a three releases per year cadence. Each released version is supported for a period of 12 months and a maintenance release of another 2 months. Kubernetes released with vSphere with Tanzu will also have the same support period as the corresponding upstream version. 

In addition to the latest Kubernetes version, the 2 previous releases which are in support are also packaged along with the release of vSphere with Tanzu.  Security Vulnerability and Bug fixes to upstream Kubernetes are made available in subsequent vCenter Patch Release as per the severity of the CVSS Score at the discretion of VMware. 


In the past, vSphere Administrators were required to upgrade to the latest vCenter releases very infrequently. They only had to consume the patch releases to keep the vCenter secure from Security Vulnerabilities and critical bugs. However, because of the speed of the upstream Kubernetes development, vSphere Administrators will now have to update their vCenter at least once every 9 - 12 months (approximately), in order to remain on the supported Kubernetes version. vSphere Administrators have to only update the vCenter (and not the ESXi hosts separately) in order to upgrade to the latest Kubernetes. vSphere with Tanzu is packaged with vCenter and the bits required to update the hosts are also packaged as part of this. The ESXi hosts need not be separately upgraded every time Supervisor is upgraded (provided the host ESXi versions are compatible with the upgraded vCenter version). The Supervisor upgrade process will update the bits in the ESXi hosts. The cluster updates does not require reboot of the ESXi hosts. 


Deployments fallen out of support

vSphere with Tanzu will be able to provide support for those clusters which are on the supported versions of Kubernetes. If for any reason a specific deployment is on an unsupported version of Kubernetes, the first and foremost action required would be to move to a supported version, before VMware can provide any support. 

Upgrade Path Rules

vSphere with Tanzu is packaged as part of vCenter releases. Because, upstream Kubernetes requires Sequential upgrade, the upgrade path for vCenter is dependent on the included Kubernetes versions. If vCenter does not have any cluster with Supervisor enabled, then the limitation is not applicable. This section explains how customers can determine the choice of upgrade paths available to them. 

Determining the Upgrade Path for vSphere with Tanzu

The following rules helps determine the possible upgrade paths available for vSphere with Tanzu upgrades.

Upgrade Path Rules

  • Source and Target vCenter Releases have at least 1 overlapping version of Kubernetes packed in them (example 1)


  • The target version should contain the immediate next version of Kubernetes present in source vCenter Release (see example 2 below)

If either of these rules is not satisfied the vSphere administrator cannot upgrade to the Target release version.



Consider the below example - assume vSphere administrator is intending to upgrade from vC Release X to one of the available releases.

vCenter Release

Supported Kubernetes Versions

vC Release X

1.14.x, 1.15.x, 1.16.x

vC X.0.1 U1

1.16.x, 1.17.x, 1.18.x

vC X.0.2 MP4

1.17.x, 1.18.x, 1.19.x

vC X.0.2 MP6

1.18.x, 1.19.x, 1.20.x


vSphere with Kubernetes versions


Auto Upgrade

In example 2, while the upgrade is possible , vSphere with Tanzu performs an auto upgrade, upgrading any version on version 1.16 (unsupported versions) to the immediate supported version. 


Frequently Asked Questions







Will I have to upgrade ESXi hosts, every-time vSphere with Tanzu is upgraded?

No, vSphere with Tanzu is packaged with vCenter and the bits required to update the hosts are also packaged as part of this and the ESXi hosts need not be separately upgraded every time Supervisor is upgraded. The Supervisor upgrade process will update the bits in the ESXi hosts






Filter Tags

Modern Applications vSphere with Tanzu Kubernetes Overview