About Enterprise PKS Upgrades
Page last updated:
Warning: VMware Enterprise PKS v1.7 is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy. To stay up to date with the latest software and security updates, upgrade to a supported version.
This topic provides conceptual information about Enterprise PKS upgrades, including upgrading the PKS control plane and PKS-provisioned Kubernetes clusters.
For step-by-step instructions on upgrading Enterprise PKS and PKS-provisioned Kubernetes clusters, see:
- Upgrading Enterprise PKS (Flannel Networking)
- Upgrading Enterprise PKS (NSX-T Networking)
- Upgrading Clusters
An Enterprise PKS upgrade modifies the version of Enterprise PKS, for example, from v1.6.x to v1.7.0 or from v1.7.0 to v1.7.1.
By default, Enterprise PKS is set to perform a full upgrade, which upgrades both the PKS control plane and all PKS-provisioned Kubernetes clusters.
However, you can choose to upgrade Enterprise PKS in two phases by upgrading the PKS control plane first and then upgrading your PKS-provisioned Kubernetes clusters later.
Both the full upgrade and the PKS control plane upgrade are performed through the Enterprise PKS tile only. When upgrading PKS-provisioned Kubernetes clusters, you can use either the Enterprise PKS tile or the PKS CLI. See the table below.
|Upgrade type||Upgrade method|
|PKS Tile||PKS CLI|
|Full PKS upgrade||✔||✖|
|PKS control plane only||✔||✖|
|Kubernetes clusters only||✔||✔|
Typically, if you choose to upgrade PKS-provisioned Kubernetes clusters only, you will upgrade them through the PKS CLI.
When deciding whether to perform the default full upgrade or to upgrade the PKS control plane and PKS-provisioned Kubernetes clusters separately, consider your organization needs.
For example, if your organization runs PKS-provisioned Kubernetes clusters in both development and production environments and you want to upgrade only one environment first, you can achieve your goal by upgrading the PKS control plane and PKS-provisioned Kubernetes separately instead of performing a full upgrade.
Examples of other advantages of upgrading Enterprise PKS in two phases include:
Faster Enterprise PKS tile upgrades. If you have a large number of clusters in your Enterprise PKS deployment, performing a full upgrade can significantly increase the amount of time required to upgrade the Enterprise PKS tile.
More granular control over cluster upgrades. In addition to enabling you to upgrade subsets of clusters, the PKS CLI supports upgrading each cluster individually.
Not a monolithic upgrade. This helps isolate the root cause of an error when troubleshooting upgrades. For example, when a cluster-related upgrade error occurs during a full upgrade, the entire Enterprise PKS tile upgrade may fail.
Warning: If you disable the default full upgrade and upgrade only the PKS control plane, you must upgrade all your PKS-provisioned Kubernetes clusters before the next Enterprise PKS tile upgrade. Disabling the default full upgrade and upgrading only the PKS control plane cause the PKS version tagged in your Kubernetes clusters to fall behind the Enterprise PKS tile version. If your PKS-provisioned Kubernetes clusters fall more than one version behind the tile, Enterprise PKS cannot upgrade the clusters.
You can perform full PKS upgrades and PKS control plane upgrades only through the Enterprise PKS tile.
After you add a new Enterprise PKS tile version to your staging area on the Ops Manager Installation Dashboard, Ops Manager automatically migrates your configuration settings into the new tile version.
For more information, see:
During a full PKS upgrade, the Enterprise PKS tile does the following:
(Only in v1.7) Creates the PKS Database VM. When you first upgrade from Enterprise PKS v1.6 to v1.7, the upgrade process creates the PKS Database VM, a new dedicated MySQL VM.
- This MySQL VM resides alongside the PKS API VM on the PKS control plane.
- The upgrade process then migrates the PKS v1.6 MySQL data from the PKS API VM to the new dedicated MySQL VM.
- Subsequent Enterprise PKS upgrades, from earlier to later patch versions of PKS v1.7, do not include this step.
Upgrades the PKS control plane, which hosts the PKS API and UAA servers. This control plane upgrade causes temporary outages as described in Control Plane Outages below.
Upgrades PKS-provisioned Kubernetes clusters.
- Upgrading PKS-provisioned Kubernetes clusters is controlled by the Upgrade all clusters errand in the Enterprise PKS tile.
- The cluster upgrade process recreates all clusters, which may cause cluster outages. For more information, see What Happens During Cluster Upgrades below.
When upgrading the PKS control plane only, the Enterprise PKS tile follows the process described in Full PKS Upgrades above, step 1 and 2. It does not upgrade PKS-provisioned Kubernetes clusters, step 3.
Upgrading the Enterprise PKS control plane temporarily interrupts the following:
- Logging in to the PKS CLI and using all
- Using the PKS API to retrieve information about clusters
- Using the PKS API to create and delete clusters
- Using the PKS API to resize clusters
These outages do not affect the Kubernetes clusters themselves.
During a PKS control plane upgrade, you can still interact with clusters and their workloads using the Kubernetes Command Line Interface,
For more information about the PKS control plane, see PKS Control Plane Overview in Enterprise PKS Architecture.
The Enterprise PKS tile is a BOSH deployment.
BOSH-deployed products can set a number of canary instances to upgrade first, before the rest of the deployment VMs. BOSH continues the upgrade only if the canary instance upgrade succeeds. If the canary instance encounters an error, the upgrade stops running and other VMs are not affected.
The Enterprise PKS tile uses one canary instance when deploying or upgrading Enterprise PKS.
Upgrading PKS-provisioned Kubernetes clusters updates their Kubernetes version to the version included with the Enterprise PKS tile. It also updates the PKS version tagged in your clusters to the Enterprise PKS tile version.
You can upgrade PKS-provisioned Kubernetes clusters either through the Enterprise PKS tile or the PKS CLI. See the table below.
|The Upgrade all clusters errand in
the Enterprise PKS tile > Errands
|All clusters. Clusters are upgraded serially.|
||Multiple clusters. Clusters are upgraded serially or in parallel.|
During an upgrade of PKS-provisioned clusters, Enterprise PKS recreates your clusters. This includes the following stages for each cluster you upgrade:
- Master nodes are recreated.
- Worker nodes are recreated.
When Enterprise PKS upgrades a single-master cluster,
you cannot interact with your cluster, use
kubectl, or push new workloads.
To avoid this loss of functionality, VMware recommends using multi-master clusters.
When Enterprise PKS upgrades a worker node, the node stops running containers. If your workloads run on a single node, they will experience downtime.
To avoid downtime for stateless workloads, VMware recommends using at least one worker node per availability zone (AZ). For stateful workloads, VMware recommends using a minimum of two worker nodes per AZ.
Note: When the Upgrade all clusters errand is enabled in the Enterprise PKS tile, updating the tile with a new Linux or Windows stemcell rolls every Linux or Windows VM in each Kubernetes cluster. This automatic rolling ensures that all your VMs are patched. To avoid workload downtime, use the resource configuration recommended in Master Nodes Outage and Worker Nodes Outage above and in Maintaining Workload Uptime.
Please send any feedback you have to firstname.lastname@example.org.