📖 Update in-place update implementation notes #13016
Conversation
Signed-off-by: Alexandr Demicev <[email protected]>
k8s-ci-robot
added
the
cncf-cla: yes
|
[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
the
size/L
|
/area documentation |
k8s-ci-robot
added
area/documentation
There was a problem hiding this comment.
thanks for the PR.
i've added some comments on grammar. note that this is not a implementation correctness pass.
Q: i know that the CAPI book has a lot of details, but this seems like it's going trough the controller source code and covering everything. is the average reader that interested in documentation verbosity ALA "i what to know exactly how this works"? for comparison, the k8s documentation doesn't do that.
|
|
||
| - In-place updates respect the existing control plane update strategy: | ||
| - KCP controller uses `rollingUpdate` strategy with `maxSurge` (0 or 1) | ||
| - When `maxSurge` is 0, no new machines are created during rollout - only in-place updates or scale down |
There was a problem hiding this comment.
best to clarify the part - only in-place updates or scale down a little, as is the sentence is a bit hard to put into context. e.g. it is only performed on...
| - KCP controller uses `rollingUpdate` strategy with `maxSurge` (0 or 1) | ||
| - When `maxSurge` is 0, no new machines are created during rollout - only in-place updates or scale down | ||
| - When `maxSurge` is 1: | ||
| - Controller first scales up by creating one new machine to maximize fault tolerance |
There was a problem hiding this comment.
| - Controller first scales up by creating one new machine to maximize fault tolerance | |
| - The controller first scales up by creating one new machine to maximize fault tolerance |
definite article for the action taker
| - When `maxSurge` is 0, no new machines are created during rollout - only in-place updates or scale down | ||
| - When `maxSurge` is 1: | ||
| - Controller first scales up by creating one new machine to maximize fault tolerance | ||
| - Once at `maxReplicas` (desiredReplicas + 1), evaluates whether to in-place update or scale down old machines |
There was a problem hiding this comment.
| - Once at `maxReplicas` (desiredReplicas + 1), evaluates whether to in-place update or scale down old machines | |
| - Once `maxReplicas` (desiredReplicas + 1) is reached, it evaluates whether to in-place update or scale down old machines |
| - When `maxSurge` is 1: | ||
| - Controller first scales up by creating one new machine to maximize fault tolerance | ||
| - Once at `maxReplicas` (desiredReplicas + 1), evaluates whether to in-place update or scale down old machines | ||
| - For each old machine needing rollout: if eligible for in-place update, performs in-place; otherwise scales down |
There was a problem hiding this comment.
Best to break this down into multiple sentences
e.g. for each machine it evaluates if it is eligible for in-place update. If so, it.... , otherwise ....
| - Controller first scales up by creating one new machine to maximize fault tolerance | ||
| - Once at `maxReplicas` (desiredReplicas + 1), evaluates whether to in-place update or scale down old machines | ||
| - For each old machine needing rollout: if eligible for in-place update, performs in-place; otherwise scales down | ||
| - This pattern repeats until all machines are up-to-date, then scales back to desired replica count |
There was a problem hiding this comment.
| - This pattern repeats until all machines are up-to-date, then scales back to desired replica count | |
| - This pattern repeats until all machines are up-to-date, it then scales back to the desired replica count |
| - Result: Final desired managedField structure is established | ||
|
|
||
| 3. **Ready for operations**: | ||
| - Continuous `syncMachines` calls update labels/annotations without affecting spec |
There was a problem hiding this comment.
| - Continuous `syncMachines` calls update labels/annotations without affecting spec | |
| - Continuous `syncMachines` calls update labels/annotations without affecting the spec of a Machine |
(i'm assuming it's a machine spec)
| When triggering in-place updates: | ||
|
|
||
| 1. Apply BootstrapConfig/InfraMachine with: | ||
| - Updated spec (owned by spec manager) |
There was a problem hiding this comment.
| - Updated spec (owned by spec manager) | |
| - Updated spec (owned by the spec manager) |
| 1. Apply BootstrapConfig/InfraMachine with: | ||
| - Updated spec (owned by spec manager) | ||
| - `update-in-progress` annotation (owned by spec manager) | ||
| - For InfraMachine: `cloned-from` annotations (owned by spec manager) |
There was a problem hiding this comment.
| - For InfraMachine: `cloned-from` annotations (owned by spec manager) | |
| - For InfraMachine: `cloned-from` annotations (owned by the spec manager) |
| - `update-in-progress` annotation (owned by spec manager) | ||
| - For InfraMachine: `cloned-from` annotations (owned by spec manager) | ||
|
|
||
| 2. Result after in-place update trigger: |
There was a problem hiding this comment.
| 2. Result after in-place update trigger: | |
| 2. Result after the in-place update trigger: |
| - labels + annotations => metadata manager | ||
| - spec => spec manager | ||
| - in-progress / cloned-from annotations => spec manager |
There was a problem hiding this comment.
best to replace the + and => with actual words (verbs).
3 participants
What this PR does / why we need it:
This PR adds notes about KCP implementation and managed field refactoring. @sbueringer @fabriziopandini could you please verify that I didn't miss anything and got it all right, also I wasn't sure if we should move these notes into the proposal or keep them separated.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #