📖 document ClusterClass rotation behavior for MachinePool objects#13280
📖 document ClusterClass rotation behavior for MachinePool objects#13280bnallapeta wants to merge 1 commit intokubernetes-sigs:mainfrom
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. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/cc @AndiDog @richardcase |
docs/book/src/developer/providers/contracts/bootstrap-config.md
Outdated
Show resolved
Hide resolved
docs/book/src/developer/providers/contracts/bootstrap-config.md
Outdated
Show resolved
Hide resolved
docs/book/src/developer/providers/contracts/bootstrap-config.md
Outdated
Show resolved
Hide resolved
docs/book/src/developer/providers/contracts/bootstrap-config.md
Outdated
Show resolved
Hide resolved
docs/book/src/developer/providers/contracts/infra-machinepool.md
Outdated
Show resolved
Hide resolved
Signed-off-by: Bharath Nallapeta <nr.bharath97@gmail.com>
2c33545 to
2ee5e91
Compare
|
@AndiDog PTAL. Thanks. |
| As of today the Node initialization consists of syncing labels from Machines to Nodes. Once the labels have been | ||
| initially synced the taint is removed from the Node. | ||
|
|
||
| ### Infrastructure provider watching for bootstrap changes |
There was a problem hiding this comment.
This page here is a description of the contract for bootstrap providers. I think we should not specify the infrastructure provider contract on this page
There was a problem hiding this comment.
@bnallapeta I agree here. Maybe we should move all diffs from this file to infra-machinepool.md instead, since that is where it's relevant. And we can link to that file if we see it as an important hint for this bootstrap provider contract.
| When the topology controller detects that the InfraMachinePoolTemplate has changed (e.g., from template updates in ClusterClass), it performs | ||
| a **rotation**: | ||
|
|
||
| 1. Creates a new InfraMachinePool object with a new name |
There was a problem hiding this comment.
@AndiDog @mboersma @richardcase Do we have consensus across InfraMachinePool providers that rotation is the right thing to do here?
I would have expected that just in-place updating the InfraMachinePool is much easier to implement for infra providers
There was a problem hiding this comment.
For InfraMachinePool, I agree that in-place updates should work. @bnallapeta is there a technical reason why it could be problematic?
There was a problem hiding this comment.
Changes in BootstrapConfig are important to be rotated, as the issue describes. Could the topology controller ensure a suffix of their name? (I'm not well-versed in how cluster class treats such problems.)
The problem with BootstrapConfig, see here: KubeadmConfig contains the latest join token which is needed for machine pools to start new instances. Since the token isn't separate from the actual bootstrapping configuration, CAPA and other infra providers wouldn't easily be able to check if something relevant has changed that should lead to start instances with the newer config, or if only the token has changed (which shouldn't roll existing nodes). My solution back then for CAPA was to check for a changed BootstrapConfig name (PR).
I'd like input from ClusterClass experts here, so we define the right expectations here. What we definitely want is for infra providers to observe a changed reference, but do we technically require that a ClusterClass-based InfraMachinePoolTemplate change leads to complete rotation? That might be hard in infra providers to implement since it will be an InfraMachinePool object with a different name, thereby probably destroying the old pool?!
There was a problem hiding this comment.
I'm entirely fine with rotating the BootstrapConfig (we already rotate the BootstrapConfigTemplate for MachineDeployments, there's no reason why we can't rotate a BootstrapConfig for MachinePools).
My comment was only about that rotating InfraMachinePools as well seems very though to implement for providers.
There was a problem hiding this comment.
I agree with @AndiDog and @sbueringer . In-place updating the inframachinepool is preferable.
I'm entirely fine with rotating the BootstrapConfig (we already rotate the BootstrapConfigTemplate for MachineDeployments, there's no reason why we can't rotate a BootstrapConfig for MachinePools).
I like this as it's consistent then with MD.
Since the token isn't separate from the actual bootstrapping configuration, CAPA and other infra providers wouldn't easily be able to check if something relevant has changed that should lead to start instances with the newer config
At some point we could explore some mechanism to separate these.
What this PR does / why we need it:
Addresses the concern raised in #13110
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Part of #10496
Additional info:
Post discussions with the MachinePool Working Group, proposals mentioned in this doc is created to unblock #13110
Area example:
/area machinepool
/area clusterclass