Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

The committers listed above are authorized under a signed CLA.

• ✅ login: chao-liang / name: colg (e51432e, 9d1d05b)

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.

Welcome @chao-liang!

It looks like this is your first PR to kubernetes/kubernetes 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kubernetes has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

Hi @chao-liang. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

/ok-to-test

/test all

/lgtm

LGTM label has been added.

/assign @deads2k

/test pull-kubernetes-node-kubelet-serial-containerd-alpha-features

/test pull-kubernetes-node-kubelet-serial-podresources

/hold

While I concede that the current behavior is unexpected, we cannot simply change this here because in a downgrade case, you end up in a state where a flow like this is possible

1. create pod/A with v1.44 which contains this change and matches the test case.
2. downgrade to v1.43.
3. Attempt to update the pod (set an annotate or resize).
4. Fail because v1.43 validation does not allow the container resources.

This could be ratcheted in via options. See how we create PodValidationOptions in the strategy by inspecting the state of the old object. In one release we could add tolerance for this state if it already exists and in a future release we could allow it during create. It will also require some tests at that level to ensure we get the downgrade case correct.

since this validation is only exercised when the field is populated, and it is an alpha field which cannot be populated by default yet, I think this is still fair game to tighten without worrying about ratcheting (once it reaches beta+, I agree we'd have to ratchet validation)

New changes are detected. LGTM label has been removed.

since this validation is only exercised when the field is populated, and it is an alpha field which cannot be populated by default yet, I think this is still fair game to tighten without worrying about ratcheting (once it reaches beta+, I agree we'd have to ratchet validation)

+1 Agree with this. I understand how this can affect downgrade scenario, but since it is an alpha feature/field ratcheting might not be needed.

Thanks for reviewing. I've synced with dixita offline, and pushed another commit to align with the current way of limit check.
Whether the resource is supported at pod level is already done in a prior function call validatePodResourceRequirements. This function and change would only focus on comparing the request/limit values between pod and containers.

Thanks for reviewing. I've synced with dixita offline, and pushed another commit to align with the current way of limit check. Whether the resource is supported at pod level is already done in a prior function call validatePodResourceRequirements. This function and change would only focus on comparing the request/limit values between pod and containers.

Could you please squash both commits

/label tide/merge-method-squash

/retest

I missed the alpha status. I agree we don't need to worry about downgrade on alpha. Thanks for the update to cover the case where not all eligible resources are specified.

/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chao-liang, deads2k

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

The pull request process is described here

/remove-kind cleanup
/kind bug
/lgtm

Since this is a user-facing change, I think it would be good to include a release note. Something like this:

Fixed an bug where, when using the Pod Level Resources feature, specifying resource requirements at the container level for a resource not supported at the pod level would cause the API server to implicitly interpret the pod-level value as 0, resulting in a validation error.

And also, as noted in the PR template, could you add a link to the KEP in the following section?

#### Which issue(s) this PR is related to:

Fixes #132449  
KEP: https://github.com/kubernetes/enhancements/issues/2837

@toVersus: changing LGTM is restricted to collaborators