fix(opentelemetry-kube-stack): make prometheus-otel example work from the packaged chart

[adityareddy-dev]

Description

the example tells you to set scrape_configs_file to examples/prometheus-otel/kubelet_scrape_configs.yaml, but that folder never ships in a packaged chart, so if you helm pull or install from the repo you just get nothing back. that's #1777.

it's actually worse than just packaged charts though, .helmignore excludes examples/ and helm applies that even when loading from a directory, so .Files.Get comes back empty on a source checkout too. the committed rendered output already shows scrape_configs: [], so kubelet, cAdvisor and probes were being silently dropped for everyone this whole time.

What the fix does

went with what the issue thread suggested, the example uses ScrapeConfig CRs now instead of the static file.

new kubelet_scrape_configs_cr.yaml with three ScrapeConfigs, kubelet /metrics, /metrics/cadvisor with the usual drop rules, and /metrics/probes. same scrape config the old file had, minus the prometheus-operator sharding stuff (hashmod + the $(SHARD) keep pair) since that doesn't apply once the target allocator is handing out targets. ScrapeConfig can't read the collector's mounted SA token, so the manifest creates its own service account, a long lived token secret and the RBAC to scrape kubelet, the TA picks the secret up through its asset store and embeds the token in what it serves the collector.

example values sets scrape_configs_file: "" and turns on scrapeConfigSelector: {}. README gets usage steps plus why the static file doesn't work. also fixed the stale comment above kubelet: in the chart values that said the config "is currently only in kubelet_scrape_configs.yaml". bumped to 0.20.7 and re-ran make generate-examples.

left the old kubelet_scrape_configs.yaml where it is so existing links keep working, and for anyone who'd rather inline the raw prometheus form.

How I tested it

make check-examples CHARTS=opentelemetry-kube-stack passes all eleven, helm lint is clean.

diffed the freshly rendered prometheus-otel output byte for byte against what was already committed, only difference is the added scrapeConfigSelector: {} line, rest is just the version label.

applied the manifest to a throwaway kind cluster on 1.35 with the bundled ScrapeConfig CRD, server side dry run passes on all seven resources and a real apply confirmed kube-controller-manager fills in the token secret. also checked field names and enum casing (role: Node, scheme: HTTPS, secret based authorization, safe tlsConfig) against the CRD in charts/prometheus-crds.

what I didn't do is a real end to end run with the operator, TA and collector actually scraping kubelet through these. I read the operator source to confirm the TA side holds up, the prometheus CR watcher does register a ScrapeConfig informer and resolves secrets through the asset store, defaults to its own namespace, that's why the README says apply into the release namespace.

Link to tracking issue

Fixes #1777

Authorship

• I, a human, wrote this pull request description myself.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: adityareddy-dev / name: Aditya Reddy (62c6c80)

[jaronoff97]

Hello, it appears you did not follow the guidelines for contribution using agents we specify here, you also removed the attestation we ask contributors to make from the PR description. I would gladly accept this change (after a review), however, I must ask that you follow the guidelines for contributing to this project. Thank you.

[adityareddy-dev]

Sorry about that, AI wrote the original description and I forgot to check the template. I've rewritten the description myself and added an Assisted-by trailer to the commit per AGENTS.md. Happy to reopen this one or open a fresh PR, whichever you'd prefer.