Skip to content

Commit ee6cfc6

Browse files
📖 Add implementation notes to the in-place update proposal (#12880)
* Add implementation notes to the in-place update proposal * Address feedback * More feedback
1 parent 91c6f9e commit ee6cfc6

File tree

1 file changed

+88
-0
lines changed

1 file changed

+88
-0
lines changed
Lines changed: 88 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,88 @@
1+
# In-place updates in Cluster API - Implementations notes
2+
3+
This document is a collection of notes about implementation details for the in-place update proposal.
4+
5+
As soon as the implementation will be completed, some of the notes in this document will be moved back
6+
into the proposal or into the user-facing documentation for this feature.
7+
8+
## Notes about in-place update implementation for machine deployments
9+
10+
- In place is always considered as potentially disruptive
11+
- in place must respect maxUnavailable
12+
- if maxUnavailable is zero, a new machine must be created first, then as soon as there is “buffer” for in-place, in-place update can proceed
13+
- when in-place is possible, the system should try to in-place update as many machines as possible.
14+
- maxSurge is not fully used (it is used only for scale up by one if maxUnavailable =0)
15+
16+
- No in-place updates are performed when using rollout strategy on delete.
17+
18+
- The implementation respects the existing set of responsibilities of each controller:
19+
- MD controller manages MS:
20+
- MD controller enforces maxUnavailable, maxSurge
21+
- MD controller decides when to scale up newMS, when to scale down oldMS
22+
- When scaling down, the MD controller checks whether the operation can be performed in-place instead of delete/recreate. If in-place is possible:
23+
- Old MS is instructed to move machines to the newMS, and newMS is informed to receive machines from oldMS.
24+
- MS controller manages a subset of Machines
25+
- When scaling down the old MS, if required to move, MS controller is responsible for moving a Machine to newMS
26+
- When reconciling the new MachineSet, the MS controller takes ownership of the moved machine and begins the actual in-place upgrade.
27+
28+
- Orchestration of in-place upgrades between MD controller, MS controller, and Machine controller is implemented using annotations.
29+
Following schemas provide an overview of how new annotations are used.
30+
31+
Workflow #1: MD controller detects an in-place update is possible and it informs oldMS and newMS about how to perform this operation.
32+
33+
```mermaid
34+
sequenceDiagram
35+
autonumber
36+
participant MD Controller
37+
participant RX
38+
participant MS1 (OldMS)
39+
participant MS2 (NewMS)
40+
MD Controller-->>+RX: Can you update in-place from MS1 (OldMS) to MS2 (NewMS)?
41+
RX-->>-MD Controller: Yes!
42+
MD Controller->>MS1 (OldMS): Apply annotation ".../move-machines-to-machineset": "MS2"
43+
MD Controller->>MS2 (NewMS): Apply annotation ".../receive-machines-from-machinesets": "MS1"
44+
```
45+
46+
Workflow #2: MS controller, when reconciling oldMS, move machines to the newMS.
47+
48+
```mermaid
49+
sequenceDiagram
50+
autonumber
51+
participant MS Controller as MS Controller<br/>when reconciling<br/>MS1 (OldMS)
52+
participant MS1 (OldMS)
53+
participant MS2 (NewMS)
54+
participant M1 as M1<br/>controlled by<br/>MS1 (OldMS),<br/>selected to be moved to MS2 (NewMS)
55+
MS Controller-->>MS1 (OldMS): Are you scaling down?
56+
MS1 (OldMS)-->>MS Controller: Yes!
57+
MS Controller-->>MS1 (OldMS): Do you have the ".../move-machines-to-machineset" annotation?
58+
MS1 (OldMS)-->>MS Controller: Yes, I'm instructed to move machines to MS2!
59+
MS Controller-->>MS2 (NewMS): Do you have ".../receive-machines-from-machinesets" annotation?
60+
MS2 (NewMS)-->>MS Controller: Yes, I'm instructed to receive machines MS1!
61+
MS Controller->>M1: Move M1 to MS2 (NewMS)<br/>Apply annotation ".../pending-acknowledge-move": ""<br/>Apply annotation ".../update-in-progress": ""
62+
```
63+
64+
MD controller recognizes that a Machine has been moved to the new MachineSet and scales up the new MachineSet to acknowledge the operation.
65+
66+
```mermaid
67+
sequenceDiagram
68+
autonumber
69+
participant MD Controller
70+
participant MS2 (NewMS)
71+
participant M1 as M1<br/>now controlled by<br/>MS2 (NewMS)
72+
MD Controller-->>M1: Are you pending acknowledge?
73+
M1-->>MD Controller: Yes!
74+
MD Controller->>MS2 (NewMS): Scale up to acknowledge receipt of M1<br/>Apply annotation ".../acknowledged-move": "M1"
75+
```
76+
77+
Workflow #4: MS controller, when reconciling newMS, detects that a machine has been acknowledged; it cleans up annotations on the machine, allowing the in-place upgrade to begin.
78+
79+
```mermaid
80+
sequenceDiagram
81+
autonumber
82+
participant MS Controller as MS Controller<br/>when reconciling<br/>MS2 (NewMS)
83+
participant MS2 (NewMS)
84+
participant M1 as M1<br/>now controlled by<br/>MS2 (NewMS)
85+
MS Controller-->>MS2 (NewMS): Is there some newly acknowledged replicas?
86+
MS2 (NewMS)-->>MS Controller: Yes, M1!
87+
MS Controller->>M1: Remove annotation ".../pending-acknowledge-move": ""
88+
```

0 commit comments

Comments
 (0)