📖 Documentation for the chained upgrade feature #13086
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
size/XL
fabriziopandini
force-pushed
the
documentation-for-chained-upgrades
branch
from
01249a9 to
03df0a3
Compare
|
/cherry-pick release-1.12 |
|
@fabriziopandini: once the present PR merges, I will cherry-pick it on top of In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
fabriziopandini
force-pushed
the
documentation-for-chained-upgrades
branch
from
03df0a3 to
afd0d8a
Compare
docs/book/src/reference/glossary.md
Outdated
|
|
||
| ### Chained upgrade | ||
| An upgrade sequence that goes from one Kubernetes version to another by passing through a set of intermediate versions. | ||
| e.g., Upgrading from v1.31.0 (current state) to v1.34.0 (target version) requires |
There was a problem hiding this comment.
| e.g., Upgrading from v1.31.0 (current state) to v1.34.0 (target version) requires | |
| E.g. upgrading from v1.31.0 (current state) to v1.34.0 (target version) requires |
docs/book/src/reference/glossary.md
Outdated
| ### Chained upgrade | ||
| An upgrade sequence that goes from one Kubernetes version to another by passing through a set of intermediate versions. | ||
| e.g., Upgrading from v1.31.0 (current state) to v1.34.0 (target version) requires | ||
| a chained upgrade with the following steps: v1.32.0 (first intermediate version)-> v1.33.0 (second intermediate version) -> v1.34.0 (target version). |
There was a problem hiding this comment.
| a chained upgrade with the following steps: v1.32.0 (first intermediate version)-> v1.33.0 (second intermediate version) -> v1.34.0 (target version). | |
| a chained upgrade with the following steps: v1.32.0 (first intermediate version) -> v1.33.0 (second intermediate version) -> v1.34.0 (target version). |
| With this regard, the recommendation is to keep the upgrade workflow a simple as fast as possible, e.g. | ||
| should avoid to combine application upgrades and Kubernetes version upgrade in a single workflow to risks under control. |
There was a problem hiding this comment.
| With this regard, the recommendation is to keep the upgrade workflow a simple as fast as possible, e.g. | |
| should avoid to combine application upgrades and Kubernetes version upgrade in a single workflow to risks under control. | |
| With this regard, the recommendation is to keep the upgrade workflow as simple and as fast as possible, e.g. combining application upgrades and Kubernetes version upgrade in a single workflow should be avoided. |
| - If instead for any reason a custom upgrade plan for workers is required, `workersUpgrades` should be set and | ||
| the following rules apply to each version in the list. More specifically, each version must be: | ||
| - equal to `FromControlPlaneKubernetesVersion` or to one of the versions in the control plane upgrade plan. | ||
| - greater than `FromWorkersKubernetesVersion` (or with a different build number) |
There was a problem hiding this comment.
I see some places we are using serialised name and few places the name as is , For example
fromControlPlaneKubernetesVersion vs FromControlPlaneKubernetesVersion, Should we stick to one format?
fabriziopandini
added
the
tide/merge-method-squash
5 participants
What this PR does / why we need it:
/area documentation