clusterctl upgrade

The clusterctl upgrade command can be used to upgrade the version of the Cluster API providers (CRDs, controllers) installed into a management cluster.

upgrade plan

The clusterctl upgrade plan command can be used to identify possible targets for upgrades.

clusterctl upgrade plan

Produces an output similar to this:

Checking cert-manager version...
Cert-Manager will be upgraded from "v1.5.0" to "v1.5.3"

Checking new release availability...

Management group: capi-system/cluster-api, latest release available for the v1beta1 API Version of Cluster API (contract):

NAME                    NAMESPACE                           TYPE                     CURRENT VERSION   NEXT VERSION
bootstrap-kubeadm       capi-kubeadm-bootstrap-system       BootstrapProvider        v0.4.0           v1.0.0
control-plane-kubeadm   capi-kubeadm-control-plane-system   ControlPlaneProvider     v0.4.0           v1.0.0
cluster-api             capi-system                         CoreProvider             v0.4.0           v1.0.0
infrastructure-docker   capd-system                         InfrastructureProvider   v0.4.0           v1.0.0

You can now apply the upgrade by executing the following command:

   clusterctl upgrade apply --contract v1beta1

The output contains the latest release available for each API Version of Cluster API (contract) available at the moment.

upgrade apply

After choosing the desired option for the upgrade, you can run the following command to upgrade all the providers in the management cluster. This upgrades all the providers to the latest stable releases.

clusterctl upgrade apply --contract v1beta1

The upgrade process is composed by three steps:

Check the cert-manager version, and if necessary, upgrade it.
Delete the current version of the provider components, while preserving the namespace where the provider components are hosted and the provider’s CRDs.
Install the new version of the provider components.

Please note that clusterctl does not upgrade Cluster API objects (Clusters, MachineDeployments, Machine etc.); upgrading such objects are the responsibility of the provider’s controllers.

It is also possible to explicitly upgrade one or more components to specific versions.

clusterctl upgrade apply \
    --core cluster-api:v1.2.4 \
    --infrastructure docker:v1.2.4

Clusterctl upgrade test coverage

Cluster API only tests a subset of possible clusterctl upgrade paths as otherwise the test matrix would be overwhelming. Untested upgrade paths are not blocked by clusterctl and should work in general, they are just not tested. Users intending to use an upgrade path not tested by us should do their own validation to ensure the operation works correctly.

The following is an example of the tested upgrade paths for v1.7:

From	To	Note
v1.0	v1.7	v1.0 is the first release with the v1beta1 contract.
v1.5	v1.7	v1.5 is v1.7 - 2.
v1.6	v1.7	v1.6 is v1.7 - 1.

The idea is to always test upgrade from v1.0 and the previous two minor releases.

Upgrading to pre-release provider versions

In order to upgrade to a provider’s pre-release version, we can do the following:

clusterctl upgrade apply \
    --core cluster-api:v1.0.0 \
    --bootstrap kubeadm:v1.0.0 \
    --control-plane kubeadm:v1.0.0 \
    --infrastructure docker:v1.0.0-rc.0

In this case, all the provider’s versions must be explicitly stated.

Upgrading to Cluster API core components pre-release versions

Use clusterctl CLI options to target the desired version.

The following shows an example of upgrading bootrap, kubeadm and core components to version v1.6.0-rc.1:

TARGET_VERSION=v1.6.0-rc.1

clusterctl upgrade apply \
    --bootstrap=kubeadm:${TARGET_VERSION} \
    --control-plane=kubeadm:${TARGET_VERSION} \
    --core=cluster-api:${TARGET_VERSION}

The Cluster API Book