CAPI operator incorrectly finds the manager container if the number of containers is >1

[eromanova]

What steps did you take and what happened:
I've deployed the CAPI operator on the kind cluster and created ControlPlaneProvider object for the k0sproject-k0smotron provider with the following configuration:

apiVersion: operator.cluster.x-k8s.io/v1alpha2
kind: ControlPlaneProvider
metadata:
  name: k0sproject-k0smotron
  namespace: kcm-system
spec:
  manager:
    health: {}
    maxConcurrentReconciles: 5
    metrics: {}
    verbosity: 10
    webhook: {}
  version: v1.4.2

The k0sproject-k0smotron provider was deployed, but settings were not properly applied.

What did you expect to happen:

I expect these settings are applied for the manager container, but since the k0sproject-k0smotron provider has >1 container, these settings were applied to the first container, which is kube-proxy.

It looks like findManagerContainer function always gets the first container from the deployment: https://github.com/kubernetes-sigs/cluster-api-operator/blob/v0.18.1/internal/controller/component_customizer.go#L178

I think other providers with >1 containers may also be affected.

K0smotron control plane containers

      containers:
      - args:
        - --secure-listen-address=0.0.0.0:8443
        - --upstream=http://127.0.0.1:8080/
        - --logtostderr=true
        - --v=10
        - --max-concurrent-reconciles=5
        image: gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
        imagePullPolicy: IfNotPresent
        name: kube-rbac-proxy
        ports:
        - containerPort: 8443
          name: https
          protocol: TCP
        resources:
          limits:
            cpu: 500m
            memory: 128Mi
          requests:
            cpu: 5m
            memory: 64Mi
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      - args:
        - --enable-controller=control-plane
        - --health-probe-bind-address=:8081
        - --metrics-bind-address=127.0.0.1:8080
        - --leader-elect
        command:
        - /manager
        env:
        - name: SSH_KNOWN_HOSTS
        image: quay.io/k0sproject/k0smotron:v1.4.2
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
            port: 8081
            scheme: HTTP
          initialDelaySeconds: 15
          periodSeconds: 20
          successThreshold: 1
          timeoutSeconds: 1
        name: manager
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readyz
            port: 8081
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 500m
            memory: 128Mi
          requests:
            cpu: 10m
            memory: 64Mi
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File

Environment:

• Cluster-api-operator version: v0.18.1
• Cluster-api version: 1.9.6
• Minikube/KIND version: kind v0.26.0 go1.23.4 darwin/arm64
• Kubernetes version: (use kubectl version): v1.32.2
• OS (e.g. from /etc/os-release):

ProductName:		macOS
ProductVersion:		14.7.4
BuildVersion:		23H420

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

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI Operator contributors determines 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.

[eromanova]

I understand it may be challenging to reliably identify the manager container, for example, if the Cluster API Operator determines it by name (then all providers should consistently follow this naming convention).

If the current logic assumes the manager container is always the first in the list, this requirement should be explicitly documented (sorry, I couldn’t find any official documentation about it). This way, providers can ensure compatibility with the CAPI Operator by placing the manager container first.

[dmvolod]

Hey, @eromanova

Agree about container detection in deployment and this should be fixed.
Please also note, that gcr.io/kubebuilder/kube-rbac-proxy is deprecated and should be replaced with alternative approach.

[dmvolod]

/assign