New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return only isolated cpus in podresources interface #97415
Return only isolated cpus in podresources interface #97415
Conversation
So this is related to KEP: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2043-pod-resource-concrete-assigments Tracked by: kubernetes/enhancements#2043 |
Is there a reason this commit isn't included in: #95734 which touches the same file for the same enhancement? |
I submitted a new KEP modification kubernetes/enhancements#2201, special for this change, since PR #95734 is already a big enough. Initially we decided to split implementation of the KEP 2043 into several PR to simplify merge each PR. |
/triage accepted |
e3b9df5
to
eb9f1b5
Compare
/test pull-kubernetes-bazel-test |
/test pull-kubernetes-e2e-kind |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: AlexeyPerevalov, klueska 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:
Approvers can indicate their approval by writing |
Co-Authored-by: Swati Sehgal <swsehgal@redhat.com> Signed-off-by: Alexey Perevalov <alexey.perevalov@huawei.com>
This patch changes cpuCount to cpuRequest in order to cater to cases where guaranteed pods make non-integral CPU Requests. Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
f228b57
to
5043b43
Compare
/test pull-kubernetes-integration
unrelated |
@AlexeyPerevalov: The following tests failed, say
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/test-infra repository. I understand the commands that are listed here. |
/test pull-kubernetes-integration |
@fromanirh @klueska The |
looks like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
LGTM lost because a trivial rebase, restoring
Based on the discussion here: kubernetes/kubernetes#97415 (comment) we explictly state that the GetCpuIds returned for a ContainerResource in the ListPodResourcesResponse represent only exclusively allocated CPUs. In order to evaluate the CPUs corresponding to the shared pool, List endpoint should be used in conjunction with GetAllocatableResources endpoint. We highlight the steps that the client needs to take evaluate this. Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
Based on the discussion here: kubernetes/kubernetes#97415 (comment) we explictly state that the GetCpuIds returned for a ContainerResource in the ListPodResourcesResponse represent only exclusively allocated CPUs. In order to evaluate the CPUs corresponding to the shared pool, List endpoint should be used in conjunction with GetAllocatableResources endpoint. We highlight the steps that the client needs to take evaluate this. Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
Based on the discussion here: kubernetes/kubernetes#97415 (comment) we explictly state that the GetCpuIds returned for a ContainerResource in the ListPodResourcesResponse represent only exclusively allocated CPUs. In order to evaluate the CPUs corresponding to the shared pool, List endpoint should be used in conjunction with GetAllocatableResources endpoint. We highlight the steps that the client needs to take evaluate this. Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
Based on the discussion here: kubernetes/kubernetes#97415 (comment) we explictly state that the GetCpuIds returned for a ContainerResource in the ListPodResourcesResponse represent only exclusively allocated CPUs. In order to evaluate the CPUs corresponding to the shared pool, List endpoint should be used in conjunction with GetAllocatableResources endpoint. We highlight the steps that the client needs to take evaluate this. Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
/kind bug
This change clarifies how which cpu ids are returned by podresourcess interface.
This clarification and change is necessary to avoid requesting pod spec in external daemon to check QoS of the pod, since before this change we were able to distinguish cpus from shared pools and exclusively isolated pool only by QoS Guaranteed.