[receiver/kubeletstats] Move receiver.kubeletstats.enableCPUUsageMetrics feature gate to stable

[ChrsMark]

Component(s)

receiver/kubeletstats

Describe the issue you're reporting

Follow up from #39487.

Based on the release schedule the receiver.kubeletstats.enableCPUUsageMetrics feature gate will get landed as beta with v0.125.0.

Based on the featuregate lifecycle we can wait for 5 releases and target to move it to stable at v0.130.0 (open to other timelines here :) ).

Related to #27885.

[github-actions]

Pinging code owners:

• receiver/kubeletstats: @dmitryax @TylerHelmuth @ChrsMark

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

[TylerHelmuth]

@ChrsMark I am very tempted to wait to move this gate to stable until the semantic conventions for k8s are stable. I want to reduce the number of names changes we make users deal with.

[ChrsMark]

I'm afraid stable SemConv for k8s will not come very soon (as mentioned also at this comment). We should keep in mind that applying stable SemConv back to the Collector will take extra time too :(.

And until then we still have to "maintain" this debt in the receiver for something that we are sure that needs to be changed.

At the same time without removing first these old metrics we cannot fix the k8s.node.cpu.utilization as discussed at #27885 (comment). (maybe we can fix it as part of receiver.kubeletstats.enableCPUUsageMetrics feature gate but will be "hacky")

I would be fine waiting for more than 5 releases before moving it to stable, if needed, but I would like this cleanup to happen regardless of when stable SemConv will be adopted back to the Collector.

[TylerHelmuth]

Ok, I dont want to block other progress. We need to evangelize this change as much as possible though.

[ChrsMark]

@TylerHelmuth any suggestions regarding the target release for GA-ing the feature gate?

I'm not sure if a blogpost would be a good fit for this but maybe before moving the feature gate to GA we could consider it as well. I would fine co-authoring this if we agree on having one (cc-ing @odubajDT if you are up to co-authoring it, since you were involved that'd be great).

[TylerHelmuth]

Blogs are useful, updating the components README with a warning, and a big message in the release notes/changelog during the release.

[ChrsMark]

I think the README already has a warning: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/v0.125.0/receiver/kubeletstatsreceiver/README.md

I will create an issue for the blog-post so as we can discuss it further.

[ChrsMark]

Since the blog is out, we can decide on when to actually move the feature gate to stable.

Copying from the initial comment my suggestion:

Based on the release schedule the receiver.kubeletstats.enableCPUUsageMetrics feature gate will get landed as beta with v0.125.0.

Based on the featuregate lifecycle we can wait for 5 releases and target to move it to stable at v0.130.0 (open to other timelines here :) ).

With v0.130.0 scheduled for mid July (2025-07-14), we can take the whole current month (June) and wait for any objections otherwise we can proceed with v0.130.0. @TylerHelmuth @dmitryax let me know what you think.