OpenTelemetry 已将其 Kubernetes Attribute Processor 提升至 1.0.0 版本，在提升可观测性管道中 Kubernetes 遥测数据的可预测性和稳定性方面迈出了重要一步。该处理器利用 Kubernetes 元数据对日志、指标和追踪数据进行扩充，其正式发布意味着该组件现在已经满足 OpenTelemetry 在测试、基准测试、文档和遥测方面的稳定性要求。此外，对于将该处理器作为自身 Collector 发行版或二进制文件的一部分进行再分发的组织，它还提供了 API 稳定性保障。
这一里程碑意义重大，因为 Kubernetes Attributes Processor 在许多 OpenTelemetry 部署中都占据着关键的位置。它能够发现 Kubernetes 资源，并将遥测数据与 Pod、命名空间、节点和工作负载等元数据进行关联，从而将原本通用的遥测数据转化为可以根据 Kubernetes 上下文进行查询和关联的数据。目前，该处理器在日志、指标和追踪方面都已趋于稳定，但性能分析功能还在开发当中。
v1.0.0 并非完全向后兼容。该处理器的稳定版本采用了更新的 OpenTelemetry Kubernetes 语义约定，而这些约定本身于 2026 年 6 月才在 Semantic Conventions v1.42.0 中正式稳定下来。OpenTelemetry 表示，这需要 Collector 和 Kubernetes Semantic Conventions SIG 之间进行密切协调，因为要使处理器稳定，就必须使其所依赖的遥测数据语义约定也保持稳定。
因此，多个属性名称发生了变化。例如，container.image.tag 变为 container.image.tags，而 Kubernetes 标签和注解属性则从 k8s.pod.labels 和 k8s.pod.annotations 等复数形式改成了 k8s.pod.label 和 k8s.pod.annotation。节点和命名空间的标签及注解也进行了相应的变更。
对于可观测性团队而言，这次迁移的重要性远不止是简单地更改 Collector 组件的版本。那些引用了旧属性名的仪表盘、告警、记录规则、查询、数据管道和下游集成可能都需要进行更新。OpenTelemetry 提供了功能闸门（feature gates），允许在迁移期间同时按新旧两种规范输出，为用户在完全依赖稳定模式之前提供了过渡途径。
该处理器的正式毕业是 OpenTelemetry 更广泛的“默认稳定（Stable by Default）”工作的一部分。Collector 特别兴趣小组（SIG）自 2025 年末开始关注高使用率组件的稳定性，通过社区反馈和 Collector 调查，识别出对用户而言稳定性和可靠性尤为重要的组件。随后，Kubernetes Attributes Processor 经历了一个正式的毕业流程，涵盖了代码所有权、测试、基准测试、文档以及遥测稳定性等多个方面。
该工作还阐明了一个可观测性标准的重要特征：一个组件仅凭自身并不一定能达到稳定状态。如果要确保处理器生成的遥测数据在时间上保持一致，其元数据就必须具备稳定的语义。因此，OpenTelemetry 将该处理器的毕业与 Kubernetes 语义约定工作进行了协调，后者在 3 月份达到发布候选状态，并在 6 月正式发布了稳定版本。
稳定性不会改变处理器的运营特性。它会为其监控的 Pod 维护一个 Kubernetes 元数据内存缓存。这意味着，在大型环境中，内存消耗可能会变得相当可观，特别是在未使用过滤功能对收集的元数据进行限制时。OpenTelemetry 的文档还指出了与使用主机网络的 Pod 以及 Sidecar 部署相关的限制。
该项目还发布了涵盖 Kubernetes 工作负载中 CPU 和内存行为的基准测试结果。这对于将 Collector 视为生产平台组成部分（而非仅仅是遥测转发组件）的组织而言至关重要：Kubernetes 元数据扩充处理已经成为另一项工作负载，其资源消耗情况需要得到充分地理解和管理。
此外，OpenTelemetry 的方法与特定于供应商的 Kubernetes 可观测性代理之间有一些重要的差异。例如，Datadog 在其 OpenTelemetry Collector 的 Datadog 分发中提供了一个基础设施属性处理器。该处理器从 Datadog Node Agent 和 Cluster Agent 中获取 Kubernetes 元数据，而不是让每个 Collector 直接查询 Kubernetes API。Datadog 认为，这种做法可以减轻 API 负载，并在大规模部署时提供更一致的标签处理。
OpenTelemetry 的 Kubernetes Attributes Processor 则采用了一种更为中立的方案：它通过 Kubernetes API 直接发现 Kubernetes 资源，并使用该项目的标准语义约定来扩充日志、指标和追踪信息。因此，两者的区别并不在于能否将 Kubernetes 元数据附加到遥测数据上，而在于数据增强发生在何处、元数据发现层由谁负责，以及生成的遥测数据在不同的可观测性后端之间的可移植性如何。
原文链接：https://www.infoq.com/news/2026/10/opentelemetry-kubernetes-observ/
