There are some guidelines and considerations to keep in mind when updating your Bottlerocket nodes in-place. Some movements between versions are updates, some are not updates, and there are some caveats you may need to consider based on the history of the project.
Certain movements between releases of Bottlerocket are accessible through an in-place update path.
With the exception of moving between major versions and a caveat discussed below, it is possible to update in-place from one released version of a variant to another released version of the same variant. In particular, the following update paths work:
Furthermore, skipping minor or patch versions of the same variant is allowed.
Bottlerocket runs all update settings migrations between the initial and target versions in sequence if a version is skipped.
So, for the
1.12.0 example, the settings migrations from
1.11.1 are run as part of the update to
You may need to consider the following caveats when updating your Bottlerocket nodes.
There is a known issue where Bottlerocket boots into a “no space left on device” error when updating between versions that are “too far apart” (too many intermediate releases – minor or patch – between the initial and target).
For example, updating between versions
1.11.0 fails in this way.
The workaround is to update Bottlerocket only a couple releases at a time from your starting point, using version locking, until you reach the desired state.
This caveat is discussed in detail in issue 2589.
Specifically, there is an important note regarding updating to the latest versions of Bottlerocket.
There are some movements between releases of Bottlerocket that are not accessible through an update path. Such movements are described below.
It is not possible to update in-place from one major version to another. Major versions are considered breaking changes.
In order to move between major versions, node replacement with the desired release is necessary.
It is not possible to update in-place from one variant to another.
For example, moving from an
aws-k8s-1.22 variant to an
aws-k8s-1.23 variant is not an update path.
In order to move between Kubernetes versions (or any variant), you must replace the nodes in your cluster with new nodes running the desired variant.