Area(s)
area:k8s
What's missing?
As per KEP 1287, container resources can be resized in place (Feature doc also available at https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/)
However, this now means that there are two different values for container limits/requests, which are the desired value and the actual value. It is possible for the actual value to not be equal to the desired value if k8s is not able to honor the desired state after a change of the desired value.
As of now, semantic conventions only cover k8s.container.cpu.limit and k8s.container.memory.limit whose implementation seems to align with the desired state, but do not cover the actual value.
Describe the solution you'd like
The proposal would be to introduce new values to the semantic conventions to cover the new use case as such:
k8s.container.cpu.limit.desired that represents the spec.containers[*].resources
k8s.container.cpu.limit.actual that represents the status.containerStatuses[*].resources
k8s.container.cpu.limit.utilization that emits usage / k8s.container.cpu.limit.actual -> Proposal is to use actual since that will reflects performance against the imposed limits, instead of what is actually intended.
For memory the same change would be applied.
Existing k8s.container.cpu.limit and k8s.container.cpu.limit_utilization could be deprecated as they would be superseded by k8s.container.cpu.limit.desired and k8s.container.cpu.limit.utilization respectively.
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
Area(s)
area:k8s
What's missing?
As per KEP 1287, container resources can be resized in place (Feature doc also available at https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/)
However, this now means that there are two different values for container limits/requests, which are the desired value and the actual value. It is possible for the actual value to not be equal to the desired value if k8s is not able to honor the desired state after a change of the desired value.
As of now, semantic conventions only cover
k8s.container.cpu.limitandk8s.container.memory.limitwhose implementation seems to align with the desired state, but do not cover the actual value.Describe the solution you'd like
The proposal would be to introduce new values to the semantic conventions to cover the new use case as such:
k8s.container.cpu.limit.desiredthat represents thespec.containers[*].resourcesk8s.container.cpu.limit.actualthat represents thestatus.containerStatuses[*].resourcesk8s.container.cpu.limit.utilizationthat emitsusage / k8s.container.cpu.limit.actual-> Proposal is to use actual since that will reflects performance against the imposed limits, instead of what is actually intended.For memory the same change would be applied.
Existing
k8s.container.cpu.limitandk8s.container.cpu.limit_utilizationcould be deprecated as they would be superseded byk8s.container.cpu.limit.desiredandk8s.container.cpu.limit.utilizationrespectively.Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it. Learn more here.