ClusterClass: controlplane MHC setting bad selector labels

[swarren83]

What steps did you take and what happened?

Specifying a machineHealthCheck in spec.controlPlane sets the following selector labels up on the MHC resource:

  selector:
    matchLabels:
      cluster.x-k8s.io/control-plane: ''
      topology.cluster.x-k8s.io/owned: ''

While the control plane machines are getting the following labels set:

  labels:
    cluster.x-k8s.io/cluster-name: my-awesome-cluster
    cluster.x-k8s.io/control-plane: ''

Example mhc configuration

spec:
  controlPlane:
    machineHealthCheck:
      maxUnhealthy: 33%
      nodeStartupTimeout: 10m0s
      unhealthyConditions:
        - status: Unknown
          timeout: 5m0s
          type: Ready
        - status: 'False'
          timeout: 5m0s
          type: Ready

What did you expect to happen?

The MHC resource spec.selector.matchLabels should be such that they match labels applied to the control plane Machine.

Cluster API version

v1.8.4

Kubernetes version

v1.27.14

Anything else you would like to add?

CAPI is running on a Rancher cluster, v2.7.9

Label(s) to be applied

/kind bug
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[sbueringer]

@swarren83 Are you sure about the labels on the CP Machines?

Example from e2e tests: (MD also for completeness) (https://gcsweb.k8s.io/gcs/kubernetes-ci-logs/logs/periodic-cluster-api-e2e-main/1872618404024684544/artifacts/clusters/bootstrap/resources/clusterclass-rollout-a5v7q9/)

CP: MHC + Machine

# CP MHC
  clusterName: clusterclass-rollout-rpjw07
  selector:
    matchLabels:
      cluster.x-k8s.io/control-plane: ""
      topology.cluster.x-k8s.io/owned: ""
# CP Machine
  labels:
    cluster.x-k8s.io/cluster-name: clusterclass-rollout-rpjw07
    cluster.x-k8s.io/control-plane: ""
    cluster.x-k8s.io/control-plane-name: clusterclass-rollout-rpjw07-5wm7c
    topology.cluster.x-k8s.io/owned: ""

MD: MHC + Machine

# MD MHC
  clusterName: clusterclass-rollout-rpjw07
  selector:
    matchLabels:
      topology.cluster.x-k8s.io/deployment-name: md-0
      topology.cluster.x-k8s.io/owned: ""
# MD Machine
  labels:
    cluster.x-k8s.io/cluster-name: clusterclass-rollout-rpjw07
    cluster.x-k8s.io/deployment-name: clusterclass-rollout-rpjw07-md-0-w5v9l
    cluster.x-k8s.io/set-name: clusterclass-rollout-rpjw07-md-0-w5v9l-nqqkj
    machine-template-hash: 1319028294-nqqkj
    topology.cluster.x-k8s.io/deployment-name: md-0
    topology.cluster.x-k8s.io/owned: ""

That being said. These are the labels that KCP sets. Makes me wonder what control plane provider Rancher is using

[sbueringer]

cc @alexander-demicev

[swarren83]

Is spec.controlplane.metadata required in order to apply the topology.cluster.x-k8s.io/ labels and annotations?

    metadata:
      annotations:
        ClusterClass.controlPlane.annotation: ClusterClass.controlPlane.annotationValue
      labels:
        ClusterClass.controlPlane.label: ClusterClass.controlPlane.labelValue

[swarren83]

I also opened rancher/cluster-api-provider-rke2#517 on the rke2 provider. CAPI appears to be working as expected, based on your e2e output, but rke2 might be the culprit. If you could address my labels/annotations question above, I would be happy to close this.

[sbueringer]

Is spec.controlplane.metadata required in order to apply the topology.cluster.x-k8s.io/ labels and annotations?

    metadata:
      annotations:
        ClusterClass.controlPlane.annotation: ClusterClass.controlPlane.annotationValue
      labels:
        ClusterClass.controlPlane.label: ClusterClass.controlPlane.labelValue

No, it's not required.

The following happens

• The cluster topology controller sets CP.spec.machineTemplate.metadata.labels (including topology.cluster.x-k8s.io/owned: "")
  • https://storage.googleapis.com/kubernetes-ci-logs/logs/periodic-cluster-api-e2e-main/1872618404024684544/artifacts/clusters/bootstrap/resources/clusterclass-rollout-a5v7q9/KubeadmControlPlane/clusterclass-rollout-rpjw07-5wm7c.yaml
• The CP (in our case KCP) is propagating these labels to the Machines
  • https://cluster-api.sigs.k8s.io/reference/api/metadata-propagation