fix(clusterapi): use kind-aware version discovery for infra references by LiangquanLi930 · Pull Request #9458 · kubernetes/autoscaler

LiangquanLi930 · 2026-04-06T17:59:40Z

What type of PR is this?

/kind bug

What this PR does / why we need it:

Add getKindPreferredVersion to resolve the API version that actually serves a given infrastructure Kind, replacing the group-level getAPIGroupPreferredVersion. This fixes incorrect GVK construction when multiple versions exist in a CAPI infra provider group but not all versions serve every Kind (e.g. Nutanix vs AWS machine templates).

Includes unit tests for getKindPreferredVersion and a test framework fix to populate Kind in the fake discovery client.

Which issue(s) this PR fixes:

Fixes #9439

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Fixed CAPI provider failing to initialize when using CAPI v1.11+ with infrastructure providers that only serve v1beta1 APIs (e.g. Azure CAPZ).

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

NONE

LiangquanLi930 · 2026-04-06T18:25:11Z

@enxebre @elmiko When you have time, PTAL, Thanks!

yashrajshuklaaa · 2026-04-06T18:48:40Z

Thanks for putting this together! The approach of resolving at the Kind level rather than just the API group makes sense
a group can serve multiple versions and not every version exposes every Kind, so group-level resolution was always going to be fragile here

A few thoughts while reading through:

On getKindPreferredVersion would it be worth adding a short comment above the function explaining the v1beta2 context? Something like:

in v1beta2, infrastructureRef only carries apiGroup and kind, not a full apiVersion so we need to resolve the version by looking up which server resource actually serves this Kind.

Future readers won't have issue #9439 in their head.

On the test fix for the fake discovery client (good catch)
Without Kind populated in the fake, this whole class of bug would stay invisible in unit tests going forward

On the original reporter's case the Nutanix error was:
infrastructure.cluster.x-k8s.io/v1beta2, Resource=nutanixmachinetemplates
which is exactly what this fixes. The Kind-aware lookup will correctly land on v1beta1 since that's what CAPN actually serves. Also try to confirm this in a test environment

LiangquanLi930 · 2026-04-07T03:52:49Z

/retest

Add getKindPreferredVersion to resolve the API version that actually serves a given infrastructure Kind, replacing the group-level getAPIGroupPreferredVersion. This fixes incorrect GVK construction when multiple versions exist in a CAPI infra provider group but not all versions serve every Kind (e.g. Nutanix vs AWS machine templates). Includes unit tests for getKindPreferredVersion and a test framework fix to populate Kind in the fake discovery client. Signed-off-by: Liangquan Li <[email protected]>

LiangquanLi930 · 2026-04-07T05:08:04Z

On getKindPreferredVersion would it be worth adding a short comment above the function explaining the v1beta2 context? Something like:

in v1beta2, infrastructureRef only carries apiGroup and kind, not a full apiVersion so we need to resolve the version by looking up which server resource actually serves this Kind.

updated

On the original reporter's case the Nutanix error was:
infrastructure.cluster.x-k8s.io/v1beta2, Resource=nutanixmachinetemplates
which is exactly what this fixes. The Kind-aware lookup will correctly land on v1beta1 since that's what CAPN actually serves. Also try to confirm this in a test environment

@yashrajshuklaaa The unit test TestGetKindPreferredVersion directly simulates this exact scenario — group preferred version is v1beta2 but the Kind only exists in v1beta1. Happy to test in a real environment if you'd like, but I think the unit coverage is sufficient here.

enxebre · 2026-04-07T09:49:16Z

/lgtm

clebs · 2026-04-07T10:51:34Z

/lgtm

elmiko

thanks @LiangquanLi930 , i just have a quick question.

also, could you update the description to add Fixes #9439

elmiko · 2026-04-07T12:31:18Z

+		if group.Name != apiGroup {
+			continue
+		}
+		for _, v := range group.Versions {


do we know what order these versions will be returned in?

i'm just curious if there is a case where we get an older version or something.

group.Versions follows CRD .spec.versions definition order, not PreferredVersion. But for the Kinds we're fixing (e.g. AzureMachineTemplate), they only exist in v1beta1, so the order doesn't affect correctness here.

Should we also update the logic to try group.PreferredVersion first before iterating?

ack, thanks.

Should we also update the logic to try group.PreferredVersion first before iterating?

good question, i don't think we need to but i'm trying to think through scenarios where this might fail.

i'm having trouble thinking of a case where we would need it. let's move forward and see what breaks XD

LiangquanLi930 · 2026-04-07T13:03:23Z

could you update the description to add Fixes #9439

updated, Thanks!

elmiko · 2026-04-07T14:52:44Z

/approve

k8s-ci-robot · 2026-04-07T14:52:56Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: elmiko, LiangquanLi930

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~cluster-autoscaler/cloudprovider/clusterapi/OWNERS~~ [elmiko]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

elmiko · 2026-06-05T12:54:57Z

/cherry-pick cluster-autoscaler-release-1.35

k8s-infra-cherrypick-robot · 2026-06-05T12:55:35Z

@elmiko: new pull request created: #9755

Details

In response to this:

/cherry-pick cluster-autoscaler-release-1.35

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.

The tenant cluster-autoscaler reads the newest Cluster API version the management cluster serves unless CAPI_VERSION names one. With Cluster API v1.13 that is v1beta2, and the 1.32 build shipped here predates the autoscaler fixes for reading v1beta2: scale from zero (kubernetes/autoscaler#8410, in 1.34) and infrastructure reference lookup (kubernetes/autoscaler#9458, in 1.36). The pools here carry capacity annotations for scale from zero, so that path is in use. Pinning v1beta1 keeps the autoscaler on the API it was built against. Cluster API serves v1beta1 until v1.16, which leaves time to move the image to a release with both fixes and drop the pin. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <[email protected]>

k8s-ci-robot requested review from elmiko and enxebre April 6, 2026 18:00

k8s-ci-robot added area/provider/cluster-api Issues or PRs related to Cluster API provider and removed do-not-merge/needs-area Indicates that a PR should not merge because it lacks an area label. labels Apr 6, 2026

LiangquanLi930 mentioned this pull request Apr 6, 2026

Incorrect version for infrastructureRef assumed based on apiGroup #9439

Closed

k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Apr 6, 2026

LiangquanLi930 force-pushed the fix/capi-infra-version-discovery branch from e4d6e47 to 4b1a5ec Compare April 7, 2026 05:07

k8s-ci-robot assigned enxebre Apr 7, 2026

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 7, 2026

k8s-ci-robot assigned clebs Apr 7, 2026

elmiko reviewed Apr 7, 2026

View reviewed changes

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 7, 2026

k8s-ci-robot merged commit c2f39f1 into kubernetes:master Apr 7, 2026
10 checks passed

k8s-infra-cherrypick-robot mentioned this pull request Jun 5, 2026

[cluster-autoscaler-release-1.35] fix(clusterapi): use kind-aware version discovery for infra references #9755

Merged

Conversation

LiangquanLi930 commented Apr 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What type of PR is this?

What this PR does / why we need it:

Which issue(s) this PR fixes:

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

Uh oh!

LiangquanLi930 commented Apr 6, 2026

Uh oh!

yashrajshuklaaa commented Apr 6, 2026

Uh oh!

LiangquanLi930 commented Apr 7, 2026

Uh oh!

LiangquanLi930 commented Apr 7, 2026

Uh oh!

enxebre commented Apr 7, 2026

Uh oh!

clebs commented Apr 7, 2026

Uh oh!

elmiko left a comment

Choose a reason for hiding this comment

Uh oh!

elmiko Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

LiangquanLi930 Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

elmiko Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

elmiko Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

LiangquanLi930 commented Apr 7, 2026

Uh oh!

elmiko commented Apr 7, 2026

Uh oh!

k8s-ci-robot commented Apr 7, 2026

Uh oh!

Uh oh!

elmiko commented Jun 5, 2026

Uh oh!

k8s-infra-cherrypick-robot commented Jun 5, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

LiangquanLi930 commented Apr 6, 2026 •

edited

Loading