|
| 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