Upgrading the Cluster Automatically

kops Upgrade#

We edited the cluster’s desired state before we started the rolling update process. While that worked well, we’re likely to always upgrade to the latest stable version. In those cases, we can execute the kops upgrade command.

Please note that this time we skipped the preview by setting the --yes argument. The output is as follows.

We can see that the current Kubernetes version is v1.9.2 and, in case we choose to proceed, it will be upgraded to the latest version.

Just as before, we can see from the last entry that changes may require instances to restart: kops rolling-update cluster.

The above command may take some time to execute.

Let’s proceed.

The output is the same as the previous time we upgraded the cluster. The only significant difference, from the process perspective, is that we did not edit cluster’s desired state by specifying the version we want, but initiated the process through the kops upgrade command. Everything else was the same in both cases.

If we are to create a test cluster and write a set of tests that verify the upgrade process, we could execute the upgrade process periodically.

We could, for example, create a job in Jenkins that would upgrade every month. If there isn’t new Kuberentes release, it would do nothing. If there is, it would create a new cluster with the same release as production, upgrade it, validate that everything works as expected, destroy the testing cluster, upgrade the production cluster, and run another round of test.

It takes time and experience to get to that point. Until then, manually executed upgrades are the way to go.

We are missing one more thing before we can deploy applications to our simulation of a production cluster.

In the next lesson, we will try to access the cluster.