This version is under construction, please use an official release version

Upgrading Clusters

Scope of The Upgrade Process

KubeOne takes care of upgrading kubeadm and kubelet binaries, running kubeadm upgrade on all control plane nodes, upgrading components and addons deploy by KubeOne, and optionally upgrading all MachineDeployments objects to the desired Kubernetes version. Upgrades are done in-place, i.e. KubeOne connects to nodes over SSH and runs commands needed to upgrade the node.

Worker nodes managed by Kubermatic machine-controller are upgraded using the rolling-upgrade strategy, i.e. the old nodes are replaced with the new ones. KubeOne Static Workers are upgraded in-place, similar to the control plane nodes.

Prerequisites

KubeOne is doing a set of preflight checks to ensure all prerequisites are satisfied. The following checks are done by KubeOne:

  • Docker, Kubelet and Kubeadm are installed,
  • information about nodes from the Kubernetes API matches what we have in the KubeOne configuration (and Terraform state file),
  • all nodes are healthy,
  • the Kubernetes version skew policy is satisfied.

Once the upgrade process starts for a node, KubeOne applies the kubeone.io/upgrade-in-progress label on the Node object. This label is used as a lock mechanism, so if upgrade fails or it’s already in progress, you can’t start it again.

It’s recommended to backup your cluster before running the upgrade process, which can be done using the Backups Addons.

Before running upgrade, please ensure that your KubeOne version supports upgrading to the desired Kubernetes version. Check the Compatibility page for more details on supported Kubernetes versions for each KubeOne release. You can check what KubeOne version you’re running using the kubeone version command.

Upgrading The Cluster

You need to update the KubeOne configuration manifest to use the desired Kubernetes version by changing the versions.Kubernetes field. It is possible to upgrade only to the next minor release, or to any patch release as long as the minor version is same or the next one.

After modifying the configuration manifest, you can use the apply command to run upgrade. The kubeone.yaml file is the configuration manifest and the tf.json file is the Terraform state file (can be omitted if the Terraform Integration is not used).

kubeone apply --manifest kubeone.yaml -t tf.json --upgrade-machine-deployments

By default KubeOne does not update the MachineDeployment objects. If you want to update them run the apply command with the --upgrade-machine-deployments flag. This updates all MachineDeployment in the cluster regardless of what’s specified in the KubeOne configuration manifest or Terraform state file.

If you encounter any issue with the apply command or you want to force the upgrade process, you can run the upgrade command manually: kubeone upgrade --manifest kubeone.yaml -t tf.json. It’s recommended to use the apply command whenever it’s possible.

The apply command analyzes the given instances, verifies that there is Kubernetes running on those instances, runs the preflight checks, and offers you to upgrade the cluster if needed. You’ll be asked to confirm your intention to upgrade the cluster by typing yes.

INFO[13:59:27 CEST] Determine hostname…
INFO[13:59:31 CEST] Determine operating system…
INFO[13:59:32 CEST] Running host probes…
INFO[13:59:33 CEST] Electing cluster leader…
INFO[13:59:33 CEST] Elected leader "ip-172-31-220-51.eu-west-3.compute.internal"…
INFO[13:59:36 CEST] Building Kubernetes clientset…
INFO[13:59:36 CEST] Running cluster probes…
The following actions will be taken:
Run with --verbose flag for more information.

	~ upgrade control plane node "ip-172-31-220-51.eu-west-3.compute.internal" (172.31.220.51): 1.18.5 -> 1.18.6
	~ upgrade control plane node "ip-172-31-221-177.eu-west-3.compute.internal" (172.31.221.177): 1.18.5 -> 1.18.6
	~ upgrade control plane node "ip-172-31-222-48.eu-west-3.compute.internal" (172.31.222.48): 1.18.5 -> 1.18.6
	~ ensure nodelocaldns
	~ ensure CNI
	~ ensure credential
	~ ensure machine-controller
	~ upgrade MachineDeployments

Do you want to proceed (yes/no):

After confirming your intention to upgrade the cluster, the process will start. It usually takes 5-10 minutes for cluster to be upgraded. At the end, you should see output such as the following one:

INFO[13:59:55 CEST] Determine hostname…
INFO[13:59:55 CEST] Determine operating system…
INFO[13:59:55 CEST] Generating kubeadm config file…
INFO[13:59:56 CEST] Uploading config files…                       node=172.31.222.48
INFO[13:59:56 CEST] Uploading config files…                       node=172.31.220.51
INFO[13:59:56 CEST] Uploading config files…                       node=172.31.221.177
INFO[13:59:57 CEST] Building Kubernetes clientset…
INFO[13:59:58 CEST] Running preflight checks…
INFO[13:59:58 CEST] Verifying that Docker, Kubelet and Kubeadm are installed…
INFO[13:59:58 CEST] Verifying that nodes in the cluster match nodes defined in the manifest…
INFO[13:59:58 CEST] Verifying that all nodes in the cluster are ready…
INFO[13:59:58 CEST] Verifying that there is no upgrade in the progress…
INFO[13:59:58 CEST] Verifying is it possible to upgrade to the desired version…
INFO[13:59:58 CEST] Labeling leader control plane…                node=172.31.220.51
INFO[13:59:58 CEST] Draining leader control plane…                node=172.31.220.51
INFO[14:00:07 CEST] Upgrading kubeadm binary on the leader control plane…  node=172.31.220.51
INFO[14:00:21 CEST] Running 'kubeadm upgrade' on leader control plane node…  node=172.31.220.51
INFO[14:00:44 CEST] Upgrading kubernetes system binaries on the leader control plane…  node=172.31.220.51
INFO[14:00:59 CEST] Uncordoning leader control plane…             node=172.31.220.51
INFO[14:01:00 CEST] Waiting 30s to ensure all components are up…  node=172.31.220.51
INFO[14:01:30 CEST] Unlabeling leader control plane…              node=172.31.220.51
INFO[14:01:30 CEST] Labeling follower control plane…              node=172.31.221.177
INFO[14:01:30 CEST] Draining follower control plane…              node=172.31.221.177
INFO[14:01:30 CEST] Upgrading Kubernetes binaries on follower control plane…  node=172.31.221.177
INFO[14:01:44 CEST] Running 'kubeadm upgrade' on the follower control plane node…  node=172.31.221.177
INFO[14:01:55 CEST] Upgrading kubernetes system binaries on the follower control plane…  node=172.31.221.177
INFO[14:02:14 CEST] Uncordoning follower control plane…           node=172.31.221.177
INFO[14:02:14 CEST] Waiting 30s to ensure all components are up…  node=172.31.221.177
INFO[14:02:44 CEST] Unlabeling follower control plane…            node=172.31.221.177
INFO[14:02:44 CEST] Labeling follower control plane…              node=172.31.222.48
INFO[14:02:44 CEST] Draining follower control plane…              node=172.31.222.48
INFO[14:02:53 CEST] Upgrading Kubernetes binaries on follower control plane…  node=172.31.222.48
INFO[14:03:10 CEST] Running 'kubeadm upgrade' on the follower control plane node…  node=172.31.222.48
INFO[14:03:24 CEST] Upgrading kubernetes system binaries on the follower control plane…  node=172.31.222.48
INFO[14:03:48 CEST] Uncordoning follower control plane…           node=172.31.222.48
INFO[14:03:48 CEST] Waiting 30s to ensure all components are up…  node=172.31.222.48
INFO[14:04:18 CEST] Unlabeling follower control plane…            node=172.31.222.48
INFO[14:04:18 CEST] Downloading PKI…
INFO[14:04:19 CEST] Downloading PKI files…                        node=172.31.220.51
INFO[14:04:20 CEST] Creating local backup…                        node=172.31.220.51
INFO[14:04:20 CEST] Ensure node local DNS cache…
INFO[14:04:21 CEST] Activating additional features…
INFO[14:04:22 CEST] Applying canal CNI plugin…
INFO[14:04:34 CEST] Creating credentials secret…
INFO[14:04:34 CEST] Installing machine-controller…
INFO[14:04:37 CEST] Installing machine-controller webhooks…
INFO[14:04:37 CEST] Waiting for machine-controller to come up…
INFO[14:05:03 CEST] Upgrade MachineDeployments…

If the upgrade process fails, it’s recommended to continue manually and resolve errors. In this case the kubeone.io/upgrade-in-progress label will prevent you from running KubeOne again but you can ignore it using the --force flag.

Changing Cluster Properties Using kubeone upgrade

In case you want to change some of the cluster properties (e.g. enable a new feature), you can use the upgrade command to reconcile the changes. Modify your manifest to include the desired changes, but don’t change the Kubernetes version (unless you want to upgrade the cluster), and then run the upgrade command with the --force flag:

kubeone upgrade --manifest kubeone.yaml -t tf.json --force

Alternatively, the kubeone apply command can be used as well:

kubeone apply --manifest kubeone.yaml -t tf.json --force-upgrade

The --force flag instructs KubeOne to ignore the preflight errors, including the error saying that you’re trying to upgrade to the already running version. At the upgrade time, KubeOne ensures that the actual cluster configuration matches the expected configuration, and therefore the upgrade command can be used to modify cluster properties.