OpenTelemetry: Kubernetes Semantics on the Path to Stability

In many observability stacks, multiple naming schemes exist for the same Kubernetes entities. In March 2026, Kubernetes-related semantic conventions progressed toward a release candidate to consistently represent resource attributes such as cluster, namespace, and pod identity.

#What the SemConv Update Covers

The consolidation focuses on exposing core Kubernetes context in a standardized way:

• Cluster identity as resource context (for example name or ID)
• Namespace, pod, and node attributes under the k8s.* namespace
• Clear separation between stable, experimental, and deprecated attributes
• Guidance on cardinality (for example, labels/annotations as selective, filtered signals)

#Migrating Collector and Instrumentation

In practice, migration often happens in the collector so applications contain less project-specific mapping logic:

• Resource detection for cluster and node context
• The k8sattributes processor to enrich k8s.namespace.name, k8s.pod.name, and related fields
• Explicit filters to limit high-cardinality label/annotation extraction

Example configuration for an OpenTelemetry Collector:

processors:
  k8sattributes:
    auth_type: serviceAccount
    extract:
      metadata:
        - k8s.namespace.name
        - k8s.pod.name
        - k8s.node.name
  resource:
    attributes:
      - key: k8s.cluster.name
        value: "production-eu-1"
        action: upsert
service:
  pipelines:
    traces:
      processors: [k8sattributes, resource]

#Why This Matters

Standard Kubernetes attributes reduce mapping overhead, make dashboards consistent, and enable reliable cross-links between metrics, logs, and traces. That consistency is a prerequisite for portable observability strategies across teams, clusters, and vendors.