[PodLevelResources] Add validation for Windows OS

[toVersus]

What type of PR is this?

/kind bug

What this PR does / why we need it:

This PR is taking over from #132627.

Adds the following checks based on the KEP description:

• API server to reject Pod with PodLevelResources if Pod targets Windows OS.
• kubelet to reject Pod with PodLevelResources on nodes other than Linux OS at admission phase.

Which issue(s) this PR is related to:

Fixes: #132582

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Added validation to reject Pods using the `PodLevelResources` feature on Windows OS due to lack of support. The API server rejects Pods with Pod-level resources and a `Pod.spec.os.name` targeting Windows. Kubelet on nodes running Windows also rejects Pods with Pod-level resources at admission phase.

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

[KEP]: https://github.com/kubernetes/enhancements/issues/2837

[k8s-ci-robot]

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-sigs/prow repository.

[k8s-ci-robot]

Hi @toVersus. 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.

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.

[toVersus]

/assign @tallclair @ndixita

[HirazawaUi]

I noticed that validatePodResources currently doesn't have a dedicated unit test. Given that it's complex enough, would you be willing to add one?

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: toVersus
Once this PR has been reviewed and has the lgtm label, please ask for approval from tallclair and additionally assign msau42 for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• pkg/apis/OWNERS
• pkg/kubelet/OWNERS

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

[toVersus]

I noticed that validatePodResources currently doesn't have a dedicated unit test. Given that it's complex enough, would you be willing to add one?

Thanks for the suggestion! I've added a new unit test specifically for validatePodResources. Since unit tests for the functions called within validatePodResources already exist, I focused on adding basic test cases and ones focused on validatePodResources.

[HirazawaUi]

/ok-to-test

[tallclair]

I'd like to take a slightly different approach to this:

1. Create a new generic handler for checking feature compatibility, maybe something like PodFeaturesAdmitHandler.
2. Create a features_{linux,windows,unsupported}.go in the lifecycle directory, similar to what was in https://github.com/kubernetes/kubernetes/pull/132627/files#diff-00fbb8cb4fcf4ea260d7497ed65513ff4ac77278797330b0ec6383e474c9b579 (don't reuse the one in allocation_manager though)
3. The generic admission handler should check if pod-level resources are set, and if so call the features helper to see whether they're supported.

Does that make sense?

[toVersus]

Thanks! I tried making the changes. Is this along the lines of what you were expecting? If so, I'll add unit tests if needed.

[HirazawaUi]

Do you also need to update the comment for the podSpec.Resources field in the API file to indicate that it is not supported on Windows OS?

[toVersus]

@thockin
Should the limitation that this field cannot be set on Windows pods be documented in the API docs? Windows support may be relaxed in the future, and there are other functional limitations as well. So I'm wondering how much detail we should include.
Personally, I feel that it would be sufficient to document it under Limitations section in the official documentation, like what's done for InPlacePodVerticalScaling. InPlacePodVerticalScaling also rejects Windows pods that specify the resizePolicy field through validation, but the API docs do not mention that Windows is unsupported.