You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// MachineSetReceiveMachinesFromMachineSetsAnnotation is an internal annotation added by the MD controller to the newMS
46
-
// when it should receive replicas from oldMSs as a first step of an in-place upgrade operation
46
+
// when it should receive replicas from oldMSs as a first step of an in-place update operation
47
47
// The annotation value is a comma separated list of oldMSs.
48
48
// Note: This annotation is used in pair with MachineSetMoveMachinesToMachineSetAnnotation to perform a two-ways check before moving a machine from oldMS to newMS:
| controlPlane.metadata | If labels/annotations are added, changed or deleted the ControlPlane objects are updated (inplace update).<br /><br /> In case of KCP, corresponding controlPlane Machines, KubeadmConfigs and InfrastructureMachines are updated in-place. |
151
-
| controlPlane.ref | Corresponding ControlPlane objects are updated (inplace update). <br /> If updating ControlPlane objects implies changes in the spec, the corresponding ControlPlane Machines are updated accordingly (rollout). |
152
-
| controlPlane.machineInfrastructure.ref | If the referenced template has changes only in metadata labels or annotations, the corresponding InfrastructureMachineTemplates are updated (inplace update). <br /> <br />If the referenced template has changes in the spec:<br /> - Corresponding InfrastructureMachineTemplate are rotated (create new, delete old)<br /> - Corresponding ControlPlane objects are updated with the reference to the newly created template (inplace update)<br /> - The corresponding controlPlane Machines are updated accordingly (rollout). |
| controlPlane.metadata | If labels/annotations are added, changed or deleted the ControlPlane objects are updated (in-place update).<br /><br /> In case of KCP, corresponding controlPlane Machines, KubeadmConfigs and InfrastructureMachines are updated in-place. |
151
+
| controlPlane.ref | Corresponding ControlPlane objects are updated (in-place update). <br /> If updating ControlPlane objects implies changes in the spec, the corresponding ControlPlane Machines are updated accordingly (rollout). |
152
+
| controlPlane.machineInfrastructure.ref | If the referenced template has changes only in metadata labels or annotations, the corresponding InfrastructureMachineTemplates are updated (in-place update). <br /> <br />If the referenced template has changes in the spec:<br /> - Corresponding InfrastructureMachineTemplate are rotated (create new, delete old)<br /> - Corresponding ControlPlane objects are updated with the reference to the newly created template (in-place update)<br /> - The corresponding controlPlane Machines are updated accordingly (rollout). |
153
153
| controlPlane.nodeDrainTimeout | If the value is changed the ControlPlane object is updated in-place.<br/> <br/> In case of KCP, the change is propagated in-place to control plane Machines. |
154
154
| controlPlane.nodeVolumeDetachTimeout | If the value is changed the ControlPlane object is updated in-place.<br/> <br/> In case of KCP, the change is propagated in-place to control plane Machines. |
155
155
| controlPlane.nodeDeletionTimeout | If the value is changed the ControlPlane object is updated in-place.<br/> <br/> In case of KCP, the change is propagated in-place to control plane Machines. |
156
156
| workers.machineDeployments | If a new MachineDeploymentClass is added, no changes are triggered to the Clusters. <br />If an existing MachineDeploymentClass is changed, effect depends on the type of change (see below). |
157
-
| workers.machineDeployments[].template.metadata | If labels/annotations are added, changed or deleted the MachineDeployment objects are updated (inplace update) and corresponding worker Machines are updated (in-place). |
158
-
| workers.machineDeployments[].template.bootstrap.ref | If the referenced template has changes only in metadata labels or annotations, the corresponding BootstrapTemplates are updated (inplace update).<br /> <br />If the referenced template has changes in the spec:<br /> - Corresponding BootstrapTemplate are rotated (create new, delete old). <br /> - Corresponding MachineDeployments objects are updated with the reference to the newly created template (inplace update). <br /> - The corresponding worker machines are updated accordingly (rollout) |
159
-
| workers.machineDeployments[].template.infrastructure.ref | If the referenced template has changes only in metadata labels or annotations, the corresponding InfrastructureMachineTemplates are updated (inplace update). <br /> <br />If the referenced template has changes in the spec:<br /> - Corresponding InfrastructureMachineTemplate are rotated (create new, delete old).<br /> - Corresponding MachineDeployments objects are updated with the reference to the newly created template (inplace update). <br /> - The corresponding worker Machines are updated accordingly (rollout) |
157
+
| workers.machineDeployments[].template.metadata | If labels/annotations are added, changed or deleted the MachineDeployment objects are updated (in-place update) and corresponding worker Machines are updated (in-place). |
158
+
| workers.machineDeployments[].template.bootstrap.ref | If the referenced template has changes only in metadata labels or annotations, the corresponding BootstrapTemplates are updated (in-place update).<br /> <br />If the referenced template has changes in the spec:<br /> - Corresponding BootstrapTemplate are rotated (create new, delete old). <br /> - Corresponding MachineDeployments objects are updated with the reference to the newly created template (in-place update). <br /> - The corresponding worker machines are updated accordingly (rollout) |
159
+
| workers.machineDeployments[].template.infrastructure.ref | If the referenced template has changes only in metadata labels or annotations, the corresponding InfrastructureMachineTemplates are updated (in-place update). <br /> <br />If the referenced template has changes in the spec:<br /> - Corresponding InfrastructureMachineTemplate are rotated (create new, delete old).<br /> - Corresponding MachineDeployments objects are updated with the reference to the newly created template (in-place update). <br /> - The corresponding worker Machines are updated accordingly (rollout) |
160
160
| workers.machineDeployments[].template.nodeDrainTimeout | If the value is changed the MachineDeployment is updated in-place.<br/> <br/> The change is propagated in-place to the MachineDeployment Machine. |
161
161
| workers.machineDeployments[].template.nodeVolumeDetachTimeout | If the value is changed the MachineDeployment is updated in-place.<br/> <br/> The change is propagated in-place to the MachineDeployment Machine. |
162
162
| workers.machineDeployments[].template.nodeDeletionTimeout | If the value is changed the MachineDeployment is updated in-place.<br/> <br/> The change is propagated in-place to the MachineDeployment Machine. |
Copy file name to clipboardExpand all lines: docs/book/src/user/concepts.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,7 +49,7 @@ A "Machine" is the declarative spec for an infrastructure component hosting a Ku
49
49
50
50
Common fields such as Kubernetes version are modeled as fields on the Machine's spec. Any information that is provider-specific is part of the `InfrastructureRef` and is not portable between different providers.
51
51
52
-
#### Machine Immutability (In-place Upgrade vs. Replace)
52
+
#### Machine Immutability (In-place Update vs. Replace)
53
53
54
54
From the perspective of Cluster API, all Machines are immutable: once they are created, they are never updated (except for labels, annotations and status), only deleted.
Copy file name to clipboardExpand all lines: docs/proposals/20240807-in-place-updates-implementation-notes.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,9 +23,9 @@ into the proposal or into the user-facing documentation for this feature.
23
23
- Old MS is instructed to move machines to the newMS, and newMS is informed to receive machines from oldMS.
24
24
- MS controller manages a subset of Machines
25
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.
26
+
- When reconciling the new MachineSet, the MS controller takes ownership of the moved machine and begins the actual in-place update.
27
27
28
-
- Orchestration of in-place upgrades between MD controller, MS controller, and Machine controller is implemented using annotations.
28
+
- Orchestration of in-place updates between MD controller, MS controller, and Machine controller is implemented using annotations.
29
29
Following schemas provide an overview of how new annotations are used.
30
30
31
31
Workflow #1: MD controller detects an in-place update is possible and it informs oldMS and newMS about how to perform this operation.
@@ -74,7 +74,7 @@ sequenceDiagram
74
74
MD Controller->>MS2 (NewMS): Scale up to acknowledge receipt of M1<br/>Apply annotation ".../acknowledged-move": "M1"
75
75
```
76
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.
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 update to begin.
__Update Extension__: Runtime Extension (Implementation) is a component responsible to perform inplace updates when the `External Update Lifecycle Hook` is invoked.
81
+
__Update Extension__: Runtime Extension (Implementation) is a component responsible to perform in-place updates when the `External Update Lifecycle Hook` is invoked.
82
82
83
83
## Summary
84
84
@@ -114,9 +114,9 @@ With the implementation of an Update extension, users can take ownership of the
114
114
115
115
### Divide and conquer
116
116
117
-
Considering the complexity of this topic, a phased approach is required to design and implement the solution for in-place upgrades.
117
+
Considering the complexity of this topic, a phased approach is required to design and implement the solution for in-place updates.
118
118
119
-
The main goal of the first iteration of this proposal is to make it possible for Cluster API users to start experimenting usage of in-place upgrades, so we can gather feedback and evolve to the next stage.
119
+
The main goal of the first iteration of this proposal is to make it possible for Cluster API users to start experimenting usage of in-place updates, so we can gather feedback and evolve to the next stage.
120
120
121
121
This iteration will focus on implementing the machinery required to interact with update extensions, while users facing changes in the API types are deferred to follow up iterations.
122
122
@@ -172,7 +172,7 @@ As a cluster operator, I want to perform in-place updates on my Kubernetes clust
172
172
173
173
#### Story 2
174
174
175
-
As a cluster operator, I want to seamlessly transition between rolling and in-place updates while maintaining a consistent user interface. I appreciate the option to extend the rollout process with in-place upgrade capabilities, ensuring that the update process aligns with my organization's unique needs.
175
+
As a cluster operator, I want to seamlessly transition between rolling and in-place updates while maintaining a consistent user interface. I appreciate the option to extend the rollout process with in-place update capabilities, ensuring that the update process aligns with my organization's unique needs.
176
176
177
177
#### Story 3
178
178
As a cluster operator for resource constrained environments, I want to utilize CAPI pluggable external update mechanism to implement in-place updates without requiring additional compute capacity in a single node cluster.
0 commit comments