[PodLevelResources] Update Downward API defaulting for resource limits#132605
Conversation
|
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 Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
|
/cc @ndixita |
|
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
|
/triage accepted |
adcfa0d to
bedd1ef
Compare
|
/assign @tallclair |
64bb683 to
98c19a8
Compare
|
/test pull-kubernetes-node-kubelet-serial-podresources |
|
@kubernetes/sig-node-pr-reviews - can someone PTAL |
|
I did a quick review on the PR and looks good to me. @ndixita I am approving this, but leave you to give the last lgtm for merge. /approve |
Currently, when container-level resource limits were not specified and the Downward API was used to set environment variables referencing them, the node's allocatable resources were used as the fallback. With the introduction of the Pod Level Resources feature, this behavior is updated: if container-level resource limits are not specified, the Downward API now uses the pod-level resource limits instead. If neither container-level nor pod-level resource limits are specified, the behavior remains unchanged. It falls back to the node's allocatable resources. Signed-off-by: Tsubasa Nagasawa <[email protected]>
98c19a8 to
a82187c
Compare
|
/test pull-kubernetes-node-kubelet-serial-podresources |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dchen1107, msau42, toVersus The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
|
LGTM label has been added. DetailsGit tree hash: 7a3a2a912510d0d204c38143ee01d9deedd8c902 |
|
|
||
| }) | ||
|
|
||
| var _ = SIGDescribe("Downward API", feature.PodLevelResources, func() { |
There was a problem hiding this comment.
It appears that we did not properly execute this test case in this PR.
PodLevelResources is a feature gate in the alpha stage. We should follow Option 1 mentioned in this email (https://groups.google.com/a/kubernetes.io/g/dev/c/uVga86nJDuI/m/gVujvOCnDwAJ) to correctly add the label for the test case, or manually trigger the dedicated e2e test job for the PodLevelResources feature (if we have already added one). Otherwise, it will be skipped during e2e test execution, Additionally, if some test job matches all features, it will execute this test case erroneously.
This e2e test case currently fails, and a related issue has been opened:
#133232
There was a problem hiding this comment.
Please disregard this comment - it has already been discussed in PR #133220.
What type of PR is this?
/kind bug
What this PR does / why we need it:
Using the Downward API's resourceFieldRef, you can inject values specified in
resources.limits, such as CPU, memory, or ephemeral storage into environment variables. Currently, when container-level resource limits were not specified and the Downward API was used to set environment variables referencing them, the node's allocatable resources were used as the fallback. With the introduction of the Pod Level Resources feature, this behavior should be updated.Which issue(s) this PR is related to:
Fixes: #132603
KEP: kubernetes/enhancements#2837
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: