It’s not news that Kubernetes has a massive rate of development and new releases bringing to the market fixes and new features, which imposes a challenge to every enterprise trying to keep up with the new releases.
Luckily VMware has streamlined the update process on vSphere with Tanzu as I intent to show here.
It worth’s mention that VMware keeps a n-1 release cycle model, meaning that we provide the version which has the major bugs already fixes, for instances as the time of this post Kubernetes upstream version is 1.20, so we are working with version 1.19.
The new release will the Kubernetes software versions and the infrastructure and services supporting the Kubernetes clusters, such as virtual machine configurations and resources, vSphere services and namespaces, and custom resources
Once the new release is available, usually following a vCenter update, the new release will be available inside the Workload Management
Just go to Updates tab and you can see your actual version and the version available for an update.
To start the update process, just select the cluster, desired release and click on Apply Update.
You must
update incrementally. Do not skip updates, such as from 1.17 to 1.19. The path
should be 1.17, 1.18 and then 1.19
vSphere with Tanzu supports rolling updates ensuring there’s a minimal downtime for the workloads, of course if sometime goes wrong rollback is also in place to bring your services back.
The new control plane will be deployed, once a new node is available it will be joined to the cluster and an older out-of-date node is removed, the objects are also migrated from the old to the new one.
This process repeats one-by-one until all control plane nodes are updated then the older nodes are deleted from vSphere inventory
Once all the Control Planes were deployed the old ones will be removed (you might realize based on the Control Plane numbers.
Once the control plane is updated (you might realize by the new control plane numbers), the worker nodes (ESXi hosts) are updated in a similar rolling update fashion, and each spherelet process on each ESXi host is updated one-by-one.
Starting with vSphere with Tanzu Update 2 there’s a new auto update policy model of n-2, which means that if you have a Supervisor Cluster that falls behind the rule it will be automatically updated, this is done to prevent the customers to run in a non-supported environment.
So, if your vCenter has been updated to include version 1.19, already provisioned clusters with version 1.18 and 1.17 will be fine, but if any of your cluster is 1.16 it will be automatically updated.
There’s a lot of information about the update process that I really encourage all of you to read here.
Now check how to update your upstream Kubernetes Cluster !!!
