CanUpdateMachine is not being called for v1beta1 api

[kotyara85]

What steps did you take and what happened?

Hey there,
We're running a deprecated apis v1beta1 with v1.12.2
The extension is registered correctly, but cp controller fails to connect to capi-core -

I only see CanUpdateMachineSet, but not CanUpdateMachine and UpdateMachine

Here's the extension -

apiVersion: v1
items:
- apiVersion: runtime.cluster.x-k8s.io/v1beta2
  kind: ExtensionConfig
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"runtime.cluster.x-k8s.io/v1beta2","kind":"ExtensionConfig","metadata":{"annotations":{"runtime.cluster.x-k8s.io/inject-ca-from-secret":"capi-system/default"},"name":"capi-runtime-extension"},"spec":{"clientConfig":{"service":{"name":"capi-runtime-extension","namespace":"capi-system","port":9443}},"namespaceSelector":{"matchExpressions":[{"key":"kubernetes.io/metadata.name","operator":"In","values":["cluster-local-stage-demo"]}]}}}
      runtime.cluster.x-k8s.io/inject-ca-from-secret: capi-system/default
    creationTimestamp: "2026-01-22T04:01:38Z"
    generation: 2
    name: capi-runtime-extension
    resourceVersion: "2005994"
    uid: 591d4b4f-f7a7-4bff-add3-733fb50e272e
  spec:
    clientConfig:
      caBundle: <REDACTED>
      service:
        name: capi-runtime-extension
        namespace: capi-system
        port: 9443
    namespaceSelector:
      matchExpressions:
      - key: kubernetes.io/metadata.name
        operator: In
        values:
        - cluster-local-stage-demo
  status:
    conditions:
    - lastTransitionTime: "2026-01-22T04:01:38Z"
      message: ""
      observedGeneration: 2
      reason: Discovered
      status: "True"
      type: Discovered
    - lastTransitionTime: "2026-01-22T04:01:38Z"
      message: ""
      observedGeneration: 2
      reason: NotPaused
      status: "False"
      type: Paused
    deprecated:
      v1beta1:
        conditions:
        - lastTransitionTime: "2026-01-22T04:01:38Z"
          status: "True"
          type: Discovered
    handlers:
    - failurePolicy: Fail
      name: can-update-machine.capi-runtime-extension
      requestHook:
        apiVersion: hooks.runtime.cluster.x-k8s.io/v1alpha1
        hook: CanUpdateMachine
      timeoutSeconds: 10
    - failurePolicy: Fail
      name: can-update-machineset.capi-runtime-extension
      requestHook:
        apiVersion: hooks.runtime.cluster.x-k8s.io/v1alpha1
        hook: CanUpdateMachineSet
      timeoutSeconds: 10
    - failurePolicy: Fail
      name: update-machine.capi-runtime-extension
      requestHook:
        apiVersion: hooks.runtime.cluster.x-k8s.io/v1alpha1
        hook: UpdateMachine
      timeoutSeconds: 10
    - failurePolicy: Fail
      name: before-cluster-upgrade.capi-runtime-extension
      requestHook:
        apiVersion: hooks.runtime.cluster.x-k8s.io/v1alpha1
        hook: BeforeClusterUpgrade
      timeoutSeconds: 10
kind: List
metadata:
  resourceVersion: ""

What did you expect to happen?

Call to webhook work

Cluster API version

v1.12.2

Kubernetes version

1.34.4

Anything else you would like to add?

No response

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.

Details

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]

I don't think the apiVersion should be relevant. Do you get a different result when you use v1beta2?

[kotyara85]

I don't think the apiVersion should be relevant. Do you get a different result when you use v1beta2?

I didn't try v1beta2 yet.
CanUpdateMachine should be triggered after CanUpdateMachineSet, right?

[sbueringer]

No. CanUpdateMachine is called by the KCP controller for single machines. CanUpdateMachineSet is called by the MachineDeployment controller for MachineSets.

If the result of these calls is that Machines can be updated in-place UpdateMachine should be called afterwards by the Machine controller.

See https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20240807-in-place-updates.md#deciding-the-update-strategy for more details

[kotyara85]

No. CanUpdateMachine is called by the KCP controller for single machines. CanUpdateMachineSet is called by the MachineDeployment controller for MachineSets.

If the result of these calls is that Machines can be updated in-place UpdateMachine should be called afterwards by the Machine controller.

See https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20240807-in-place-updates.md#deciding-the-update-strategy for more details

I don't see any logs relevant to the webhook executed from cp controllers -

kubectl get deployments.apps -n capi-kubeadm-control-plane-system capi-kubeadm-control-plane-controller-manager  -o yaml | grep args -A 5
      - args:
        - --leader-elect
        - --diagnostics-address=:8443
        - --insecure-diagnostics=false
        - --feature-gates=MachinePool=true,ClusterTopology=false,KubeadmBootstrapFormatIgnition=false,PriorityQueue=false,ReconcilerRateLimiting=false,InPlaceUpdates=true
        - --v=5

Anywhere else I can look up?

This webhook basically never executed

[sbueringer]

How does your KCP object look like? (replicas, maxSurge, ..)