OpenTelemetry 的 Kubernetes Attribute Processor 已完成 1.0.0 版本发布。据 InfoQ 报道，这一组件从孵化走向稳定，意味着它在测试、基准测试、文档与遥测输出四方面的稳定性门槛全部达标；对把它嵌入自家 Collector 发行版或二进制分发的组织来说，还额外拿到了 API 稳定性的背书。

三类遥测信号获得 Pod、命名空间、节点级上下文

该处理器在 OpenTelemetry 部署链路中承担的角色相当关键：它会主动发现集群内的 Kubernetes 资源，为日志、指标、追踪三种信号挂上 Pod、命名空间、节点与工作负载等元数据，从而把原本缺乏上下文的原始遥测转成能按 Kubernetes 维度查询、联动分析的数据。目前这三类信号的稳定性均已就位，只有性能分析（Profiling）部分尚在推进中。

并非完全向后兼容：属性命名规则整体调整

v1.0.0 并不是一个可以直接无痛替换的版本。稳定版本采用的是更新后的 OpenTelemetry Kubernetes 语义约定，而这套约定自身要等到 2026 年 6 月随 Semantic Conventions v1.42.0 发布才正式定型。按照原文说法，处理器要稳定，其产出的遥测所依赖的语义也必须先稳定，这要求 Collector 与 Kubernetes Semantic Conventions SIG 两个团队紧密协同。

由此带来的是若干属性名变更。举例来说，原本表示镜像标签的 container.image.tag 转为 container.image.tags；Pod 的标签与注解属性则从 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 发行版中提供基础设施属性处理器，Kubernetes 元数据从 Datadog 的 Node Agent 与 Cluster Agent 获取，而不是让每个 Collector 各自向 Kubernetes API 发查询。Datadog 的观点是，这样做能减少 API 压力，并在大规模场景下让标签处理更为一致。

OpenTelemetry 的 Kubernetes Attributes Processor 走的是更中立的路线：直接通过 Kubernetes API 发现资源，再用项目自身的标准语义约定为日志、指标、追踪补充信息。由此两者的真正差别不在于能否给遥测附加 Kubernetes 元数据，而在于三点——增强动作发生在哪一层、元数据发现由谁负责、以及生成的遥测在不同可观测性后端之间的可移植程度如何。

小结：Kubernetes Attributes Processor 1.0.0 是 OpenTelemetry「默认稳定」路线的一次关键落地，它让日志、指标、追踪都拿到稳定的 Kubernetes 上下文；但语义约定升级带来的属性改名意味着使用方必须全链路排查旧字段，并善用功能闸门完成平滑迁移。同时，元数据缓存带来的内存开销在大型集群中仍需重点关注，相关基准数据为容量规划提供了可用参考。