feat(kube-stack): add presets.prometheus.{nodeExporter,cadvisor,podAnnotations}

[cyrille-leclerc]

Summary

Adds a new top-level presets.prometheus.* namespace to the kube-stack chart — a daemonset-local replacement for scrape_configs_file: daemon_scrape_configs.yaml. Three independently-toggleable presets, each adding a dedicated named instance of the prometheus receiver to the daemonset collector's metrics pipeline:

• prometheus.nodeExporter — scrapes a Prometheus Node Exporter on the local node via static_configs targeting ${OTEL_K8S_NODE_IP}:9100.
• prometheus.cadvisor — scrapes cAdvisor from the local kubelet at https://${OTEL_K8S_NODE_IP}:10250/metrics/cadvisor with bearer-token auth. Drops the high-cardinality / low-value series by default (same drop list as daemon_scrape_configs.yaml).
• prometheus.podAnnotations — scrapes pods on the local node carrying classic prometheus.io/scrape=true annotations via kubernetes_sd_configs with a node field selector.

Sharded by design: each daemonset pod scrapes only its own node, no central Prometheus bottleneck.

UX

collectors:
  daemon:
    scrape_configs_file: ""   # required when enabling any prometheus/* preset
    presets:
      prometheus:
        nodeExporter:
          enabled: true
        cadvisor:
          enabled: true
        podAnnotations:
          enabled: true

Per-preset knobs: scrapeInterval (default 30s), scrapeTimeout (default 10s), plus port for nodeExporter / cadvisor (podAnnotations reads port per-pod from the prometheus.io/port annotation).

Time-series alignment with the daemon_scrape_configs.yaml jobs

All three presets produce the same identifying labels as daemon_scrape_configs.yaml — job / instance / Kubernetes label sets, so existing queries, dashboards, alerts, and recording rules relying on these labels keep working unchanged:

Preset	Maps to daemon_scrape_configs.yaml job	Compatibility
nodeExporter	node-exporter	Drop-in + bonus node label
cadvisor	kubelet (/metrics/cadvisor)	Drop-in — job_name: kubelet kept for KPS + daemon_scrape_configs.yaml parity
podAnnotations	kubernetes-pods	Drop-in + bonus node label + collector self-scrape filter

Documentation

• README.md: new subsection presets.prometheus.* under the existing Kube-Prometheus-Stack compatability heading. Covers the constraints, discovery model, per-preset label set, alignment with daemon_scrape_configs.yaml, and remaining duplicate-scrape risks (e.g. the prometheus-node-exporter subchart's own ServiceMonitor).
• values.yaml: each preset documented inline; constraints called out at the umbrella block.
• values.schema.json: full schema entries with descriptions; scrape_configs_file description notes the mutual exclusivity.

Constraints (chart-enforced)

Template-render assertions fail with a clear error if either is violated:

• Mutually exclusive with scrape_configs_file — the presets are a replacement, not an addition. The default daemon_scrape_configs.yaml already has node-exporter, kubelet/cAdvisor, and pod-annotation jobs; running both would cause duplicate scrapes.
• Require mode: daemonset — the scrape configs use ${OTEL_K8S_NODE_IP} / ${OTEL_K8S_NODE_NAME} and node field selectors that only make sense on daemonset collectors.

Errors name the specific presets enabled, e.g. presets.prometheus.{nodeExporter, cadvisor} are a replacement for scrape_configs_file....

Why a standalone Prometheus receiver rather than receiver_creator?

The standalone Prometheus receiver reuses the native Prometheus discovery & scrape code paths and config, so users can lift-and-shift existing Prometheus jobs and relabel chains. The receiver_creator path is still available via the existing presets.annotationDiscovery.metrics.enabled.

Test plan

• make generate-examples CHARTS=opentelemetry-kube-stack produces no further diff.
• helm lint charts/opentelemetry-kube-stack clean.
• New example examples/daemonset-prometheus-presets/ demonstrates enabling all three presets together.
• Validation: helm template with scrape_configs_file set + a preset enabled fails with the expected error naming the enabled presets.
• Validation: helm template with mode: deployment + a preset enabled fails with the expected error.
• Render examples and confirm each preset's scrape job has the expected job_name (node-exporter / kubelet / kubernetes-pods), scheme, metrics_path, relabel rules (including node label injection), and metric_relabel_configs.
• Deploy to a k3d cluster and verify metrics flow through each receiver.

[cyrille-leclerc]

@dashpole FYI, as I suggested in open-telemetry/opentelemetry-specification#4956 (comment), we could evolve the prometheus/addPrometheusLabels config in this PR so that it not only avoids generating labels such as pod, namespace, etc., but also maps the Prometheus job and instance labels to prometheus.job and prometheus.instance.

This would allow service.name and service.instance.id to remain unset in the PRometheus receiver layer, so that the k8sattributes processor can generate the desired values based on Kubernetes metadata, matching the guidance from SemConv: Specify resource attributes using Kubernetes annotations.
We could temporarily implement this with a transform processor waiting to add the capability in the PRometheus receiver.

[cyrille-leclerc]

@jaronoff97 I hope this meets your expectations. The code change is quite small.

[cyrille-leclerc]

FYI the build failure looks odd, make check-examples on github actions is unhappy with a few line breaks in generated files when there are no problems on my laptop. I have to investigate more.

[dashpole]

The latest iteration of the spec PR just keeps job/instance as-is. Hopefully that simplifies things.

[cyrille-leclerc]

@jaronoff97 the build is fixed could you please have a look?

[jaronoff97]

The docs are incorrect and quite misleading. Please go through them again and correct the errors. The content of the PR's actual helm changes looks good however.

[cyrille-leclerc]

Thanks for your feedback @jaronoff97. The PR is ready for another review.

I have cleaned up the docs following your recommendations.
I kept the documentation of the differences between metrics captured by daemon_scrape_configs.yaml and by presets.prometheus.* but I stop talking of compatibility.

[jaronoff97]

much better, thank you very much!

[jaronoff97]

@dashpole or @TylerHelmuth mind adding your review in here when you get a chance?

[dashpole]

Looks correct overall to me. I don't have much experience with helm, though