Merge pull request #17418 from rook/mergify/bp/release-1.20/pr-17417
docs: update upgrade docs for v1.20 (backport #17417)
This commit is contained in:
1 file changed
+24
-44
@@ -14,7 +14,7 @@ We welcome feedback and opening issues!
|
||||
|
||||
## Supported Versions
|
||||
|
||||
This guide is for upgrading from **Rook v1.18.x to Rook v1.19.x**.
|
||||
This guide is for upgrading from **Rook v1.19.x to Rook v1.20.x**.
|
||||
|
||||
Please refer to the upgrade guides from previous releases for supported upgrade paths.
|
||||
Rook upgrades are only supported between official releases.
|
||||
@@ -22,6 +22,7 @@ Rook upgrades are only supported between official releases.
|
||||
For a guide to upgrade previous versions of Rook, please refer to the version of documentation for
|
||||
those releases.
|
||||
|
||||
* [Upgrade 1.18 to 1.19](https://rook.io/docs/rook/v1.19/Upgrade/rook-upgrade/)
|
||||
* [Upgrade 1.17 to 1.18](https://rook.io/docs/rook/v1.18/Upgrade/rook-upgrade/)
|
||||
* [Upgrade 1.16 to 1.17](https://rook.io/docs/rook/v1.17/Upgrade/rook-upgrade/)
|
||||
* [Upgrade 1.15 to 1.16](https://rook.io/docs/rook/v1.16/Upgrade/rook-upgrade/)
|
||||
@@ -53,30 +54,9 @@ those releases.
|
||||
official releases. Builds from the master branch can have functionality changed or removed at any
|
||||
time without compatibility support and without prior notice.
|
||||
|
||||
## Breaking changes in v1.19
|
||||
## Breaking changes in v1.20
|
||||
|
||||
* The minimum supported Kubernetes version is v1.30.
|
||||
|
||||
* The minimum supported Ceph version is v19.2.0. Rook v1.18 clusters running Ceph v18 must upgrade
|
||||
to Ceph v19.2.0 or higher before upgrading Rook.
|
||||
|
||||
* The behavior of the `activeStandby` property in the `CephFilesystem` CRD has changed.
|
||||
When set to `false`, the standby MDS daemon deployment will be scaled down and removed,
|
||||
rather than only disabling the standby cache while the daemon remains running.
|
||||
|
||||
* Helm: The rook-ceph-cluster chart has changed where the Ceph image is defined, to allow separate
|
||||
settings for the repository and tag. If you deploy with a custom values.yaml:
|
||||
1. Remove the [cephVersion](https://github.com/rook/rook/blob/release-1.19/deploy/charts/rook-ceph-cluster/values.yaml#L102-L114)
|
||||
section from the `cephClusterSpec`, to avoid a conflict with the new settings.
|
||||
2. If desired to override the Ceph image repository or tag, apply the new
|
||||
[cephImage](https://github.com/rook/rook/blob/master/deploy/charts/rook-ceph-cluster/values.yaml#L88-L102)
|
||||
settings such as:
|
||||
|
||||
```yaml
|
||||
cephImage:
|
||||
repository: quay.io/ceph/ceph
|
||||
tag: v19.2.3
|
||||
```
|
||||
* The minimum supported Kubernetes version is v1.31.
|
||||
|
||||
## Considerations
|
||||
|
||||
@@ -92,11 +72,11 @@ With this upgrade guide, there are a few notes to consider:
|
||||
|
||||
Unless otherwise noted due to extenuating requirements, upgrades from one patch release of Rook to
|
||||
another are as simple as updating the common resources and the image of the Rook operator. For
|
||||
example, when Rook v1.19.1 is released, the process of updating from v1.19.0 is as simple as running
|
||||
example, when Rook v1.20.1 is released, the process of updating from v1.20.0 is as simple as running
|
||||
the following:
|
||||
|
||||
```console
|
||||
git clone --single-branch --depth=1 --branch v1.19.1 https://github.com/rook/rook.git
|
||||
git clone --single-branch --depth=1 --branch v1.20.1 https://github.com/rook/rook.git
|
||||
cd rook/deploy/examples
|
||||
```
|
||||
|
||||
@@ -104,11 +84,11 @@ If the Rook Operator or CephCluster are deployed into a different namespace than
|
||||
`rook-ceph`, see the [Update common resources and CRDs](#1-update-common-resources-and-crds)
|
||||
section for instructions on how to change the default namespaces in `common.yaml`.
|
||||
|
||||
Then, apply the latest changes from v1.19, and update the Rook Operator image.
|
||||
Then, apply the latest changes from v1.20, and update the Rook Operator image.
|
||||
|
||||
```console
|
||||
kubectl apply -f common.yaml -f crds.yaml -f csi-operator.yaml
|
||||
kubectl -n rook-ceph set image deploy/rook-ceph-operator rook-ceph-operator=rook/ceph:v1.19.1
|
||||
kubectl -n rook-ceph set image deploy/rook-ceph-operator rook-ceph-operator=rook/ceph:v1.20.1
|
||||
```
|
||||
|
||||
As exemplified above, it is a good practice to update Rook common resources from the example
|
||||
@@ -142,9 +122,9 @@ In order to successfully upgrade a Rook cluster, the following prerequisites mus
|
||||
|
||||
## Rook Operator Upgrade
|
||||
|
||||
The examples given in this guide upgrade a live Rook cluster running `v1.18.8` to
|
||||
the version `v1.20-beta.0`. This upgrade should work from any official patch release of Rook v1.18 to any
|
||||
official patch release of v1.19.
|
||||
The examples given in this guide upgrade a live Rook cluster running `v1.19.4` to
|
||||
the version `v1.20.0`. This upgrade should work from any official patch release of Rook v1.19 to any
|
||||
official patch release of v1.20.
|
||||
|
||||
Let's get started!
|
||||
|
||||
@@ -208,7 +188,7 @@ kubectl apply -f deploy/examples/monitoring/rbac.yaml
|
||||
!!! hint
|
||||
The operator is automatically updated when using Helm charts.
|
||||
|
||||
The largest portion of the upgrade is triggered when the operator's image is updated to `v1.19.x`.
|
||||
The largest portion of the upgrade is triggered when the operator's image is updated to `v1.20.x`.
|
||||
When the operator is updated, it will proceed to update all of the Ceph daemons.
|
||||
|
||||
```console
|
||||
@@ -236,18 +216,18 @@ watch --exec kubectl -n $ROOK_CLUSTER_NAMESPACE get deployments -l rook_cluster=
|
||||
```
|
||||
|
||||
As an example, this cluster is midway through updating the OSDs. When all deployments report `1/1/1`
|
||||
availability and `rook-version=v1.20-beta.0`, the Ceph cluster's core components are fully updated.
|
||||
availability and `rook-version=v1.20.0`, the Ceph cluster's core components are fully updated.
|
||||
|
||||
```console
|
||||
Every 2.0s: kubectl -n rook-ceph get deployment -o j...
|
||||
|
||||
rook-ceph-mgr-a req/upd/avl: 1/1/1 rook-version=v1.20-beta.0
|
||||
rook-ceph-mon-a req/upd/avl: 1/1/1 rook-version=v1.20-beta.0
|
||||
rook-ceph-mon-b req/upd/avl: 1/1/1 rook-version=v1.20-beta.0
|
||||
rook-ceph-mon-c req/upd/avl: 1/1/1 rook-version=v1.20-beta.0
|
||||
rook-ceph-osd-0 req/upd/avl: 1// rook-version=v1.20-beta.0
|
||||
rook-ceph-osd-1 req/upd/avl: 1/1/1 rook-version=v1.18.8
|
||||
rook-ceph-osd-2 req/upd/avl: 1/1/1 rook-version=v1.18.8
|
||||
rook-ceph-mgr-a req/upd/avl: 1/1/1 rook-version=v1.20.0
|
||||
rook-ceph-mon-a req/upd/avl: 1/1/1 rook-version=v1.20.0
|
||||
rook-ceph-mon-b req/upd/avl: 1/1/1 rook-version=v1.20.0
|
||||
rook-ceph-mon-c req/upd/avl: 1/1/1 rook-version=v1.20.0
|
||||
rook-ceph-osd-0 req/upd/avl: 1// rook-version=v1.20.0
|
||||
rook-ceph-osd-1 req/upd/avl: 1/1/1 rook-version=v1.19.4
|
||||
rook-ceph-osd-2 req/upd/avl: 1/1/1 rook-version=v1.19.4
|
||||
```
|
||||
|
||||
An easy check to see if the upgrade is totally finished is to check that there is only one
|
||||
@@ -256,14 +236,14 @@ An easy check to see if the upgrade is totally finished is to check that there i
|
||||
```console
|
||||
# kubectl -n $ROOK_CLUSTER_NAMESPACE get deployment -l rook_cluster=$ROOK_CLUSTER_NAMESPACE -o jsonpath='{range .items[*]}{"rook-version="}{.metadata.labels.rook-version}{"\n"}{end}' | sort | uniq
|
||||
This cluster is not yet finished:
|
||||
rook-version=v1.18.8
|
||||
rook-version=v1.20-beta.0
|
||||
rook-version=v1.19.4
|
||||
rook-version=v1.20.0
|
||||
This cluster is finished:
|
||||
rook-version=v1.20-beta.0
|
||||
rook-version=v1.20.0
|
||||
```
|
||||
|
||||
### **5. Verify the updated cluster**
|
||||
|
||||
At this point, the Rook operator should be running version `rook/ceph:v1.20-beta.0`.
|
||||
At this point, the Rook operator should be running version `rook/ceph:v1.20.0`.
|
||||
|
||||
Verify the CephCluster health using the [health verification doc](health-verification.md).
|
||||
Reference in new issue
Block a user