Overview

Enterprise PKS 1.6 has recently been released which has some interesting additions when it comes to managing PKS clusters, the most exiting being the Tanzu Mission Control integration which is currently in BETA. In this article I am going to document the process of moving from PKS 1.5 to 1.6 so that I can start looking at the additional functionality on offer.

Make sure you check out the release notes here for full details. Also check the dependencies as you may encounter upgrade failures (e.g. in my environment my Harbor Registry needs to be upgraded before PKS as my current version does not support Ops Manager 2.7.x).

Ops Manager

Before I can do anything with PKS I need to perform an upgrade of my Ops Manager installation. This is a requirement that is specified in the prerequisites for PKS 1.6 which states a minimum version of 2.7.3. My current build is 2.7.2 so lets start here.

Ops Manager installs are not so much upgraded, rather they are migrated using a data export from the old install which is ingested into a new install. However, as you need to use the same hostname, IP address etc you obviously cannot have the old version active at the same time as the new version. This is a service effecting upgrade procedure for Ops Manager.

My first step is to generate a configuration export from the existing install via the “Settings” menu. This produces a ZIP file which you need to save for use later on.

Next I have powered down the existing Ops Manager install and renamed it within the vCenter inventory so I know what’s new and what’s old. Once that is done I can deploy a new install from the latest OVA downloaded from network.pivotal.io using the same hostname, IP address, public SSH key etc.

With the new install powered up and OVA settings applied during boot up I can go straight to the “Import Existing Installation” option.

Now I’m prompted for the decrypt passphrase from the old Ops Manager install and to upload the export ZIP file.

Once these are entered the install should load up and allow me to login using the same credentials I was using with the previous installation. For me that was using LDAP.

The BOSH director tile is automatically updated as part of the Ops Manager upgrade and should show the new build version. PKS (tile and control VM) will not have changed at this point.

PKS

Now that Ops Manager and BOSH Director are running at the latest build version I can concentrate on the PKS tile and and control VM. I’m not uninstalling or deleting what is already there. I am simply going to upload the latest tile version to Ops Manager which will replace the current tile version.

The PKS tile file is several GB in size so the upload and processing can take several minutes before the interface returns back to you.

If your Ops Manager has the required stemcell already loaded for PKS then everything should be good to go for the next part. If it doesn’t the PKS tile will be orange and you will need to download the appropriate stemcell and attach it to PKS (the same process as if you were installing PKS from scratch).

At this point I can run through all the PKS tile configuration and make any adjustments that are required. The settings are inherited from the previous tile version. Here you can see the Tanzu Mission Control integration. At this point I am not enabling this but we will look at it in a future article!

I’m leaving the cluster upgrade errand enabled here so that the PKS control VM and all PKS clusters are upgraded at the same time. You can opt to disable the cluster upgrade and run it at a later time after the PKS control VM has been upgraded if you wish. Also note that I am not running smoke tests in my environment to save time however this should be enabled for production environments to guarantee the new installation will work.

Once any changes have been made they need to be saved, reviewed and applied. This process will upgrade the PKS control VM and the PKS clusters themselves (as I have the upgrade errand enabled).

This completes the server upgrade process. As you can see it’s not long or complicated but you need to pay special attention to the prerequisites.

CLI Tools

The majority of the upgrade work has now been completed however to interact with the upgraded PKS control VM and clusters I need to make sure my client machines have the necessary binaries. PKS and Kubectl binaries can both be downloaded from network.pivotal.io and copied to any client machine that requires them.

Once I’ve upgraded the client binaries I can use them to verify functionality by doing some simple operations like checking build versions. By listing the clusters using “pks clusters” I can see the PKS version has been uplifted to 1.6.0 on my single cluster as well as the Kubernetes version to 1.15.5.

This completes my upgrade.