Importing k8s.io/api/core/v1.ResourceRequirements into a CRD makes it invalid when upgrading to v1.26.0

[saschagrunert]

What happened?

I'm upgrading Kubernetes v1.25 to v1.26 in the Security Profiles Operator, where the upgrade to v1.26 adds the Claims []ResourceClaim to the type ResourceRequirements:

kubernetes/staging/src/k8s.io/api/core/v1/types.go

Lines 2316 to 2328 in 4802d7b

	// Claims lists the names of resources, defined in spec.resourceClaims,
	// that are used by this container.
	//
	// This is an alpha field and requires enabling the
	// DynamicResourceAllocation feature gate.
	//
	// This field is immutable.
	//
	// +listType=map
	// +listMapKey=name
	// +featureGate=DynamicResourceAllocation
	// +optional
	Claims []ResourceClaim `json:"claims,omitempty" protobuf:"bytes,3,opt,name=claims"`

We use the ResourceRequirements in our own CRD to be able to configure the values:
https://github.com/kubernetes-sigs/security-profiles-operator/blob/33fd12312002985e08dca4166e304a02ba8fe2d9/api/spod/v1alpha1/spod_types.go#L312-L315

After the upgrade, the SPOD CRD got invalid with the following error:

The CustomResourceDefinition "securityprofilesoperatordaemons.security-profiles-operator.x-k8s.io" is invalid:
spec.validation.openAPIV3Schema.properties[spec].properties[daemonResourceRequirements].properties[claims].items.x-kubernetes-map-type: Invalid value: "null": must be atomic as item of a list with x-kubernetes-list-type=set

What did you expect to happen?

The upgrade does not make the CRD invalid.

How can we reproduce it (as minimally and precisely as possible)?

Try to deploy the operator from the PR: https://github.com/kubernetes-sigs/security-profiles-operator/blob/caff76aeff452d367ba07fc5448eb11a13097d1e/deploy/operator.yaml

Anything else we need to know?

No response

Kubernetes version

Tested on:

• v1.25.3
• v1.26.0

Cloud provider

None

OS version

None

Install tools

None

Container runtime (CRI) and version (if applicable)

CRI-O v1.26.0

Related plugins (CNI, CSI, ...) and versions (if applicable)

[k8s-ci-robot]

@saschagrunert: There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:

• /sig <group-name>
• /wg <group-name>
• /committee <group-name>

Please see the group list for a listing of the SIGs, working groups, and committees available.

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/test-infra repository.

[k8s-ci-robot]

@saschagrunert: This issue is currently awaiting triage.

If a SIG or subproject 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/test-infra repository.

[saschagrunert]

Ah this seems to be fixed by #114585