Closed MaxFedotov closed 1 year ago
/area topology @vincepri another possible improvement for cluster.spec.topolgy and/or ClusterClass
Is there any other use cases we can think of for labels/annotations? e.g Syncing from class to Nodes.
For autoscaling in particular I'd expect this to be baked in MachineDeploymentClass API eventually e.g .autoscaling {min: , max: }
Syncing from classes to a node can happen for free if we use existing metadata fields, otherwise, if we add a new field for node labels it should be surfaced in CC as well
/triage accepted
As discussed in the Aug 5th issue triage meeting we should evaluate options:
Propagate existing metadata both to MD/KCP and Machines (to be verified if this as undesirable side effects)
One side effect would be that any update of labels\annotations (e.g. for autoscaler) will cause Machine rollout
Related discussion about node annotations not propagating via Machine update: https://github.com/kubernetes-sigs/cluster-api/pull/6255
After the discussion during Cluster API meeting it was proposed to separate this into two different issues:
ClusterClass
and Cluster.spec.topology
not only to Machines
, but also to MD
and KCP
Machine
rollout when labels or annotations in MachineDeployment.spec.template.metadata
or KubeadmControlPlane.spec.machineTemplate.metadata
are updated (can be done as a part of #5880 or #6255)Just to provide an update. We included this in this proposal: https://github.com/kubernetes-sigs/cluster-api/pull/7331
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
@sbueringer @ykakarap should this issue be closed due to https://github.com/kubernetes-sigs/cluster-api/pull/7917 being merged?
I think yes.
also be able to update them without triggering rollout for corresponding Machines
That's not solved yet, but we have another issue for it (https://github.com/kubernetes-sigs/cluster-api/issues/7731)
/close as per comments above
@fabriziopandini: Closing this issue.
User Story
As a user I would like to specify labels and annotations for
MachineDeployment
andKubeadmControlPlane
created by topology controller to be used used bycluster-autoscaler
or for filtering.Detailed Description
It is possible to specify
labels
andannotations
in cluster topology spec, but they are propagated only tomachines
created byMachineDeployment
andKubeadmControlPlane
.As documented in
cluster-autoscaler
readme, in order to use it with Managed Topology, users had to skipspec.topology.workers.machineDeployments[].replicas
field, which cause topology controller to always createMachineDeployment
with only one replica. Users can later add specificcluster-autoscaler
annotations in order to increase number of replicas. And as this annotations cannot be added toMachineDeployment
during provisioning, it is impossible to create them with any other number of replicas other then one.It will be nice to have a way to pass labels and annotation from
Cluster
topology spec toMachineDeployment
andKubeadmControlPlane
and also be able to update them without triggering rollout for correspondingMachines
/kind feature