PodResources: Introducing isExclusive field in ContainerResources #28488
Conversation
A pod with same non-integral CPU request and limit belongs to Guaranteed QoS class but obtains CPUs from the shared pool. Currently, in podresource API there is no way to distinguish such pods from the pods which have been exclusively allocated CPUs. One of the primary goals of recent enhancements of PodResource API is to allow it to enable node monitoring agents to know the allocatable compute resources on a node, in order to calculate the node compute resource utilization. However, not being able to determine if a pod has been exclusively allocated CPUs or CPUs belong to the shared pool means that the goal cannot be realized. We need to enhance the podresource API to give it the ability to determine if a pod belongs to the shared pool or exclusive pool to be able to do proper accounting in the node monitoring agents. Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/XS
k8s-ci-robot
added
language/en
|
✔️ Deploy Preview for kubernetes-io-main-staging ready! 🔨 Explore the source changes: 43b0fba 🔍 Inspect the deploy log: https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/60cd3979624fea9be7716d40 😎 Browse the preview: https://deploy-preview-28488--kubernetes-io-main-staging.netlify.app |
|
@PI-Victor FYI - this looks like a change targeting a future release |
|
/hold |
k8s-ci-robot
added
the
do-not-merge/hold
|
@PI-Victor Yes, this is a bug fix. |
|
is this going to target 1.22 only or will it be back ported to 1.21? |
|
@PI-Victor Since the podresource API enhancements to enable accounting of resources were proposed in Kubernetes 1.21 and failed to meet the goal, I would say it should be fixed in 1.22 and backported to 1.21 as well. |
|
@swatisehgal: PR needs rebase. 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. |
k8s-ci-robot
added
the
needs-rebase
|
this PR should not merge until kubernetes/kubernetes#102989 is merged |
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
based on the comments in implementation PR, i assume this PR is no longer valid. If you disagree or i got that wrong, please feel free to reopen this. /close |
|
@PI-Victor: Closed this PR. In response to this:
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. |
A pod with same non-integral CPU request and limit belongs to Guaranteed
QoS class but obtains CPUs from the shared pool. Currently, in podresource API
there is no way to distinguish such pods from the pods which have been exclusively
allocated CPUs.
One of the primary goals of recent enhancements of PodResource API is to allow it to
enable node monitoring agents to know the allocatable compute resources on a node,
in order to calculate the node compute resource utilization. However, not being
able to determine if a pod has been exclusively allocated CPUs or CPUs belong to
the shared pool means that the goal cannot be realized.
We need to enhance the podresource API to give it the ability to determine if a pod
belongs to the shared pool or exclusive pool to be able to do proper accounting in
the node monitoring agents.
Implementation PR: kubernetes/kubernetes#102989