[PodLevelResources] Propagate Pod level hugepage cgroup to containers

[KevinTMtz]

What type of PR is this?

What this PR does / why we need it:

Follow up of [PodLevelResources] Pod Level Hugepage Resources.

This PR propagates Pod level hugepage cgroup to containers with the following changes:

1. Pod level hugepage cgroup when unset in container
2. Unit test propagate pod level hugepages to containers

Additionally adds:

1. Validation logic for pod level hugepages
2. Unit test pod level hugepage default and validation logic
3. E2E tests for container hugepage resources immutability

Which issue(s) this PR fixes:

Fixes #132543

Special notes for your reviewer:

Does this PR introduce a user-facing change?

- Changes underlying logic to propagate Pod level hugepage cgroup to containers when they do not specify hugepage resources.
- Adds validation to enforce the hugepage aggregated container limits to be smaller or equal to pod-level limits. This was already enforced with the defaulted requests from the specified limits, however it did not make it clear about both hugepage requests and limits.

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

- [Other doc]: https://docs.google.com/document/d/1JaqE2eRmFAPlRayv8vsAWE4SmQCVXQLr9rFPhEaPlvQ/edit?usp=sharing

[k8s-ci-robot]

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

[KevinTMtz]

/assign @ndixita

[liggitt]

Ok, this looks good, make sure we have the following test scenarios covered:

1. PodSpec in a Deployment with container hugepages limit and no request

   • I think this doesn't get defaulted (e.g. in a Deployment), and passes validation by skipping the limit && request equality check on podspec
   • the eventual pod would default container hugepages request, and still pass validation
   • make sure pod-level resources also avoids defaulting hugepages, and validation is happy with this scenario both for podspec and pod

2. Pod with a pod-level hugepages request and no limit errors as expected

3. Pod with a pod-level hugepages request and limit works as expected

[liggitt]

Defaulting change looks good, this is on a field that was alpha-gated in 1.33. The change makes it clearer that someone explicitly setting pod-level hugepages requests must set the corresponding pod-level limit themselves.

Marked as API approved, will tag once the test coverage is verified and the clarification at #131089 (comment) is updated

[KevinTMtz]

Ok, this looks good, make sure we have the following test scenarios covered:

1. PodSpec in a Deployment with container hugepages limit and no request
   • I think this doesn't get defaulted (e.g. in a Deployment), and passes validation by skipping the limit && request equality check on podspec
   • the eventual pod would default container hugepages request, and still pass validation
   • make sure pod-level resources also avoids defaulting hugepages, and validation is happy with this scenario both for podspec and pod

Currently there are no E2E tests that focus the PodSpec, current E2E tests focus on pods. Would it be possible to add those in a follow up PR? Deployments undergo the same resource validation as pod, so we would actually be testing the same cases, however only the ones that are valid without the defaulting.

In regards to unit test, the newly added pkg/api/testing/validate_pod_level_defaults_test.go covers those cases.

2. Pod with a pod-level hugepages request and no limit errors as expected

Unit and E2E tests added in #130577 together with the new tests added in this PR cover this functionality.

3. Pod with a pod-level hugepages request and limit works as expected

Unit and E2E tests added in #130577 together with the new tests added in this PR cover this functionality.

[liggitt]

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 6922a6382899bc3073cb388b5738aeef21eb5eec

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: KevinTMtz, liggitt, tallclair

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

The pull request process is described here

Needs approval from an approver in each of these files:

• api/OWNERS [liggitt]
• pkg/api/OWNERS [liggitt]
• pkg/apis/OWNERS [liggitt]
• pkg/generated/openapi/OWNERS [liggitt]
• pkg/kubelet/OWNERS [liggitt,tallclair]
• staging/src/k8s.io/api/OWNERS [liggitt]
• test/e2e_node/OWNERS [liggitt,tallclair]

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

[KevinTMtz]

/retest

[KevinTMtz]

/retest

[KevinTMtz]

/retest

[pacoxu]

/test pull-kubernetes-e2e-gce

[k8s-ci-robot]

@KevinTMtz: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kubernetes-e2e-gce	1bc995c	link	unknown	/test pull-kubernetes-e2e-gce
pull-kubernetes-integration	1bc995c	link	unknown	/test pull-kubernetes-integration

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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. I understand the commands that are listed here.

[KevinTMtz]

/retest