kubernetes-sigs/cluster-api

ClusterClass MachinePool implementation is probably not able to rollout BootstrapConfig changes.

Open

#10,496 opened on Apr 23, 2024

View on GitHub
 (18 comments) (1 reaction) (1 assignee)Go (1,532 forks)auto 404
area/machinepoolhelp wantedkind/bugpriority/backlogtriage/accepted

Repository metrics

Stars
 (4,267 stars)
PR merge metrics
 (PR metrics pending)

Description

Quoting from a different issue:

Can you please summarize what a user would have to do to rollout a change to a KubeadmConfig with a reguar cluster (not using ClusterClass). Is it as simple as modifying the KubeadmConfig object that is linked in a MachinePool directly?

Change MachinePool.spec.template.spec.bootstrap.configRef.name and the KubeadmConfig.spec changes will be reconciled. In practice, that means a user's KubeadmConfig.metadata.name should be suffixed with a hash (or increasing number) when making changes, and the reference in the MachinePool object gets changed to this new KubeadmConfig name. https://github.com/kubernetes-sigs/cluster-api/issues/8858#issuecomment-2051049208

The ClusterClass MachinePool implementation today uses one single BootstrapConfig / KubeadmConfig object for a MachinePool and just continuously patches it in-place to rollout changes.

Based on #8858 this is not enough, it seems to be required to rotate the BootstrapConfig object (create a new one + update the ref in MachinePool).

Someone would need to confirm if my observation is correct.

Furthermore I don't know if there is a documented contract as of today for MachinePools how BootstrapConfigs are supposed to be rolled out. I also don't know if MachinePools behave the same across providers today.

So my tl;dr:

  • ClusterClass can probably not rollout BootstrapConfig changes for MachinePools today
  • We need a documented contract on how BootstrapConfig rollouts are supposed to work with MachinePools

Contributor guide