Update cpu resource metrics to handle resize

[jmmcorreia]

Related to #3558

Changes

Modifies the k8s container limit and request metrics to align with resize of CPU metrics as documented in https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/

It fixes the CPU part related to issue #3558. Memory metrics can be fixed in a follow-up PR based on the comments provided for the CPU section

For more details check issue

Merge requirement checklist #3558

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[ChrsMark]

Thank's for digging into this @jmmcorreia! I left some comments but overall I think it goes to right direction!

@open-telemetry/semconv-k8s-approvers PTAL

[dashpole]

I have a few hesitations with this:

• As a user, it isn't nearly as obvious what I should be comparing my CPU and memory usage to. The desired or the actual requests/limits? (answer: actual)
• Desired requests/limits are largely going to be a niche metric to diagnose in-place update issues. We could even consider making it opt-in, IMO.

Did we consider something more like k8s.container.cpu.limit vs k8s.container.cpu.desired_limit?

[jmmcorreia]

I have a few hesitations with this:

• As a user, it isn't nearly as obvious what I should be comparing my CPU and memory usage to. The desired or the actual requests/limits? (answer: actual)

Agreed. The utilization metrics does attempt to make that easier on users by making comparison on the collector side and providing the presentation metric to them.

• Desired requests/limits are largely going to be a niche metric to diagnose in-place update issues. We could even consider making it opt-in, IMO.

That is a valid point, I think it makes sense. Probably a lot of users might not attempt to patch the container resources whilst it is running.

Did we consider something more like k8s.container.cpu.limit vs k8s.container.cpu.desired_limit?

Before raising the PR I was stuck on deciding between the implemented approach (i.e. limit.actual and limit.desired) or going with what you proposed. Had a short discussion with @ChrsMark, and going with limit.actual and limit.desired seemed to fit more the semantic conventions approach of creating a namespace for values that fall under a sort of similar category (i.e. going with . instead of _). What I link from your proposal is that I believe it makes things somewhat simpler for users. We give a clear definition on limit and then only the desired limit (that we are making opt-in anyway) uses the _ separator in the name. However, the current approach was picked as it seems to containerize values a little better as it also includes utilization under the limit. Most likely there will be no need to add more values related to the limit, but if it were, the current approach also make that more flexible. IMO both could work, I think I slightly prefer the current approach given the better containerization of the values and I believe this should help prevent any changes to the metrics in the future in case any new ones have to be added (even if not that likely).

@dashpole But happy yo hear your thoughts on this. @ChrsMark if you have any other comments or anything to add I guess that could be helpful.

[dashpole]

The point about utilization is a good one. I think maybe switching to current from actual will mostly address my concerns. I reopened the comment thread above.

[ChrsMark]

Thank's @jmmcorreia!

[ChrsMark]

@open-telemetry/semconv-k8s-approvers @open-telemetry/specs-semconv-approvers PTAL

[ChrsMark]

@open-telemetry/specs-semconv-maintainers this one is approved by the K8s SIG. PTAL