OpenTelemetry: Kubernetes-Semantik auf dem Weg zur Stabilität

In vielen Observability-Stacks existieren mehrere Namensschemata für dieselben Kubernetes-Entitäten. Im März 2026 wurden Kubernetes-bezogene Semantic Conventions in Richtung Release Candidate weiterentwickelt, um Resource Attributes wie Cluster-, Namespace- und Pod-Identitäten konsistent abzubilden.

#Was im SemConv-Update enthalten ist

Die Konsolidierung zielt darauf ab, zentrale Kubernetes-Kontexte standardisiert bereitzustellen:

• Cluster-Identität als Resource-Kontext (z. B. Name oder ID)
• Namespace-, Pod- und Node-Attribute im k8s.* Namensraum
• Klare Trennung zwischen stable, experimental und deprecated Attributen
• Guidance zu Cardinality (z. B. Labels/Annotations als selektive, gefilterte Signale)

#Migration in Collector und Instrumentation

Die technische Umsetzung findet oft im Collector statt, damit Applikationen weniger projektspezifische Mapping-Logik enthalten:

• Resource Detection für Cluster- und Node-Kontext
• k8sattributes-Processor zum Anreichern von k8s.namespace.name, k8s.pod.name und aehnlichen Feldern
• Explizite Filterregeln, um High-Cardinality aus Labels/Annotations zu begrenzen

Beispiel-Konfiguration für einen 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]

#Warum das wichtig ist

Standardisierte Kubernetes-Attribute reduzieren den Aufwand für Mapping, vereinheitlichen Dashboards und ermöglichen stabile Querbeziehungen zwischen Metrics, Logs und Traces. Das ist eine Voraussetzung für portable Observability-Strategien über Teams, Cluster und Vendoren hinweg.