OpenTelemetry has promoted its Kubernetes Attributes Processor to v1.0.0, marking a significant step in making Kubernetes telemetry more predictable and stable across observability pipelines. The processor enriches logs, metrics, and traces with Kubernetes metadata, and its graduation means the component now meets OpenTelemetry's stability requirements around testing, benchmarking, documentation, and telemetry. It also provides API stability for organisations redistributing the processor as part of their own Collector distributions or binaries.
The milestone is important because the Kubernetes Attributes Processor sits at a key point in many OpenTelemetry deployments. It discovers Kubernetes resources and associates telemetry with metadata such as pods, namespaces, nodes, and workloads, turning otherwise generic telemetry into data that can be queried and correlated by Kubernetes context. The processor is currently stable for logs, metrics, and traces, although profiles remain under development.
The move to v1.0.0 is not entirely backwards compatible. The processor's stable release adopts the newer OpenTelemetry Kubernetes semantic conventions, which themselves reached stable status in Semantic Conventions v1.42.0 in June 2026. OpenTelemetry says this required close coordination between the Collector and Kubernetes Semantic Conventions SIGs because stabilising the processor also required stabilising the conventions on which its telemetry depends.
Several attribute names therefore change. For example, container.image.tag becomes container.image.tags, while Kubernetes label and annotation attributes move from plural forms such as k8s.pod.labels and k8s.pod.annotations to k8s.pod.label and k8s.pod.annotation. Equivalent changes apply to node and namespace labels and annotations.
That makes the migration more significant for observability teams than simply changing a Collector component version. Dashboards, alerts, recording rules, queries, data pipelines and downstream integrations that reference the older attribute names may need to be updated. OpenTelemetry provides feature gates that allow the old and new conventions to be emitted during the migration period, giving users a way to transition before relying exclusively on the stable schema.
The processor's graduation forms part of OpenTelemetry's broader "Stable by Default" work. The Collector SIG began focusing on the stability of heavily used components in late 2025, using community feedback and Collector surveys to identify components where stability and reliability were particularly important to users. The Kubernetes Attributes Processor was subsequently put through a formal graduation process covering areas including code ownership, testing, benchmarking, documentation, and telemetry stability.
The work also illustrates an important characteristic of observability standards: a component cannot necessarily become stable in isolation. The processor's metadata needs to have stable semantics if telemetry produced by it is to remain consistent over time. OpenTelemetry therefore coordinated the processor's graduation with the Kubernetes semantic-conventions work, which reached release-candidate status in March before becoming stable in June.
Stability does not change the processor's operational characteristics. It maintains an in-memory cache of Kubernetes metadata for the pods it monitors, meaning memory consumption can become significant in larger environments, particularly when filtering is not used to limit the metadata being collected. OpenTelemetry's documentation also identifies limitations around host-networked pods and sidecar deployments.
The project has also published benchmarks covering CPU and memory behaviour across Kubernetes workloads. That matters for organisations treating the Collector as part of their production platform rather than simply a telemetry-forwarding component: Kubernetes metadata enrichment becomes another workload whose resource consumption needs to be understood and managed.
There are also important differences between the OpenTelemetry approach and vendor-specific Kubernetes observability agents. Datadog, for example, provides an infraattributes processor in its Datadog Distribution of the OpenTelemetry Collector that obtains Kubernetes metadata from the Datadog Node Agent and Cluster Agent rather than having each Collector query the Kubernetes API directly. Datadog argues that this can reduce API load and provide more consistent tagging at scale.
The OpenTelemetry Kubernetes Attributes Processor takes a more vendor-neutral approach: it directly discovers Kubernetes resources through the Kubernetes API and enriches logs, metrics, and traces using the project's standard semantic conventions. The distinction is therefore less about whether Kubernetes metadata can be attached to telemetry and more about where that enrichment occurs, who owns the metadata discovery layer, and how portable the resulting telemetry remains across observability backends.