If you are upgrading the version of Kubernetes for a cluster managed by Cluster API, check that the running version of Cluster API on the Management Cluster supports the target Kubernetes version.
You may need to upgrade the version of Cluster API in order to support the target Kubernetes version.
In addition, you must always upgrade between Kubernetes minor versions in sequence, e.g. if you need to upgrade from Kubernetes v1.17 to v1.19, you must first upgrade to v1.18.
For kubeadm based clusters, infrastructure providers require a “machine image” containing pre-installed, matching
kubelet, ensure that relevant infrastructure machine templates reference the appropriate
image for the Kubernetes version.
The high level steps to fully upgrading a cluster are to first upgrade the control plane and then upgrade the worker machines.
To upgrade the control plane machines underlying machine images, the
MachineTemplate resource referenced by the
KubeadmControlPlane must be changed. Since
MachineTemplate resources are immutable, the recommended approach is to
- Copy the existing
- Modify the values that need changing, such as instance type or image ID.
- Create the new
MachineTemplateon the management cluster.
- Modify the existing
KubeadmControlPlaneresource to reference the new
MachineTemplateresource in the
The next step will trigger a rolling update of the control plane using the new values found in the new
To upgrade the Kubernetes control plane version make a modification to the
Spec.Version field. This will trigger a rolling upgrade of the control plane and, depending on the provider, also upgrade the underlying machine image.
Some infrastructure providers, such as AWS, require
that if a specific machine image is specified, it has to match the Kubernetes version specified in the
KubeadmControlPlane spec. In order to only trigger a single upgrade, the new
MachineTemplate should be created first
and then both the
InfrastructureTemplate should be modified in a single transaction.
KubeadmControlPlane resource has a field
RolloutAfter that can be set to a timestamp
(RFC-3339) after which a rollout should be triggered regardless of whether there were any changes
KubeadmControlPlane.Spec or not. This would roll out replacement control plane nodes
which can be useful e.g. to perform certificate rotation, reflect changes to machine templates,
move to new machines, etc.
Note that this field can only be used for triggering a rollout, not for delaying one. Specifically,
a rollout can also happen before the time specified in
RolloutAfter if any changes are made to
the spec before that time.
The rollout can be triggered by running the following command:
clusterctl alpha rollout restart kubeadmcontrollplane/my-kcp
To do the same for machines managed by a
MachineDeployment it’s enough to make an arbitrary
change to its
Spec.Template, one common approach is to run:
clusterctl alpha rollout restart machinedeployment/my-md-0
This will modify the template by setting an
cluster.x-k8s.io/restartedAt annotation which will
trigger a rollout.
Upgrades are not limited to just the control plane. This section is not related to Kubeadm control plane specifically, but is the final step in fully upgrading a Cluster API managed cluster.
It is recommended to manage machines with one or more
Machines to allow for a seamless scaling experience. A modification to the
MachineDeployments spec will begin a rolling update of the machines. Follow
these instructions for changing the
template for an existing
MachineDeployments support different strategies for rolling out changes to
Changes are rolled out by honouring
Only values allowed are of type Int or Strings with an integer and percentage symbol e.g “5%”.
Changes are rolled out driven by the user or any entity deleting the old
Machines. Only when a
Machine is fully deleted a new one will come up.