This step-by-step guide explains the basic scenario of upgrading Kubernetes cluster from one to other minor version of Kubernetes. The article does not cover any use cases related to upgrading a third party’s application installed on top of a Kublr cluster. This use case will be described in the next article.
Ensure that all your applications are up and running and the status of Kublr cluster is “Running”. The basic scenario is a rolling upgrade of each Kubernetes node one by one. It means that at some time period one of the nodes will be temporary unavailable. Ensure that you have enough nodes and application replicas to prevent unavailability of business service. You can always add an additional instance group (additional nodes) in Kublr cluster using Kublr UI and additional replicas for your applications using the standard Kubernetes tools (kubectl or Dashboard).
The upgrades start from masters. If you have only one master,Kuberenetes API will be unavailable for some time period during the upgrade. For multi master configuration Kubernetes API will be available at all times.
We always recommend you have at least one staging environment with the same configuration and perform the upgrade there, before you upgrading the production cluster.
Go to the cluster and click “Edit cluster”
Choose a version of Kubernetes
On each instance group you can choose additional options. We do not recommend you use “Max Unavailable Nodes” for more than one for masters, because this value shows how many nodes Kublr upgrades simultaneously.
Click save and wait until Kublr upgrades cluster. It will change status to “Updating”
Visit the “Events” tab to check the progress
After the upgrade is complete, the cluster should return to “Running” state
In case of failure, the cluster will enter the “Error” state. Attempt to rollback the cluster to the previous state, using the “Rollback cluster” option. It will be available only if the cluster enters the “Error” state. Please always test your upgrade in a staging environment.