[receiver/k8scluster] Sync allocatable metric names with the latest semconv

[odubajDT]

Component(s)

receiver/k8scluster

Describe the issue you're reporting

Sync the current naming of the allocatable metrics to the latest semconv introduced in open-telemetry/semantic-conventions#2267.

There should be a feature gate in place to handle the breaking change. The following metrics should be affected:

k8s.node.allocatable_cpu
k8s.node.allocatable_ephemeral_storage
k8s.node.allocatable_memory
k8s.node.allocatable_pods

[github-actions]

Pinging code owners:

• receiver/k8scluster: @dmitryax @TylerHelmuth @povilasv @ChrsMark

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[ChrsMark]

Ideally we should wait until those metrics are GA in SemConv before changing them, to mitigate the risk of having additional breaking changes.

[bacherfl]

If this is still available, I'd like to work on this, now that the latest semconv release including the allocatable metrics is out: https://github.com/open-telemetry/semantic-conventions/releases/tag/v1.35.0

[ChrsMark]

Thank's @bacherfl!

I think the agreement is that we won't use any K8s Semantic Conventions in the Collector until they are GA. The fact that those were released is not a guarantee that they will remain as-is, since they are in development stability right now.

The plan is to port all GA Semantic Conventions once we have them, in a batch, following the migration plan described at https://opentelemetry.io/docs/specs/semconv/non-normative/k8s-migration/.

For reference, this effort is tracked by the K8s SemConv SIG. If you are interested into helping with this effort please feel free to join us :).

[joaopgrassi]

@ChrsMark I have a general question, from the semconv side: Although we don't have clear guidance (https://github.com/open-telemetry/semantic-conventions/blob/main/docs/general/how-to-define-semantic-conventions.md#stabilizing-existing-conventions) the common thing so far is that we have some prototypes out there before declaring conventions GA. Otherwise we have a chicken-and-egg problem.

Has this been discussed within the k8s SIG?

[ChrsMark]

Good question @joaopgrassi. This also applies to System SIG as well.

I'm not sure if we have thought of it yet in detail. My assumption would be the following:

The plan would be to change the Collector in order to use the defined SemConv behind a feature gate. The feature gate will initially be in alpha version. With this we will have a prototype proving that defined SemConv work as expected. Once we are ready, we can promote the Semconv to GA and the feature gate of the Collector to beta, then stable etc (see feature-lifecycle). We could even leverage a release candidate version of the SemConv as an intermediate state.

Would that make sense? In any case, I think that's a discussion worth taking place soon.

/cc @open-telemetry/semconv-k8s-approvers @open-telemetry/semconv-system-approvers