OpenTelemetry Operator：Kubernetes 上可观测性的“自动驾驶仪”



OpenTelemetry Operator：Kubernetes 上可观测性的“自动驾驶仪”

云原生SRE

2025-11-13

欢迎点击下方👇关注我，记得星标哟~

文末会有重磅福利赠送

在云原生体系中，随着微服务化、容器化和弹性扩缩容的普及，应用的可观测性已从“可选项”变成“必需品”。OpenTelemetry（OTel）作为事实标准，为指标、日志、链路追踪提供统一的数据模型与采集方式。然而，在 Kubernetes 集群中，如何以“标准化、自动化、低侵入”的方式部署采集组件与注入自动探针？答案就是：OpenTelemetry Operator。

本文基于 OpenTelemetry Operator 官方文档与仓库内容，系统介绍其能力、安装方式、典型用法与最佳实践，帮助你在生产环境中稳健落地。

一、OpenTelemetry Operator 是什么？

OpenTelemetry Operator 是一个 Kubernetes Operator，实现了对 OpenTelemetry 生态组件的声明式管理，主要负责：

• OpenTelemetry Collector 的生命周期管理（部署、升级、观测配置）
• 面向多语言应用的自动探针注入（auto-instrumentation），包括 Java、NodeJS、Python、.NET、Go、Apache HTTPD、Nginx 等

简单理解：你通过 CRD（自定义资源）声明“我需要怎样的采集与注入”，Operator 会自动在集群中创建相应的 Pod、Service、证书、Sidecar 等，并在 Collector 配置变更时平滑地更新。

二、核心能力概览

管理对象

• OpenTelemetry Collector：核心数据面，负责接收、处理、导出遥测数据
• Instrumentation：自动注入语言探针，按命名空间或 Pod 注解触发

部署模式

• Deployment（默认）、DaemonSet、StatefulSet、Sidecar
• 自动注入

• 按语言开启注入开关；支持多容器选择性注入和多语言多容器注入（需开启 enable-multi-instrumentation）

Target Allocator（可选）

• 为 Prometheus Receiver 提供分布式目标分配，解决多实例 Collector 的抓取冲突与均衡问题

资源属性管理

• 通过注解、标签与 SDK 环境变量自动填充 service.name、k8s 相关属性
• 升级策略

• 支持 automatic/none，灵活选择是否由 Operator 接管升级

三、安装与“最小可用”示例

在现有集群中安装时，请确保已安装 cert-manager，然后应用发布清单：

安装命令


   kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

待 Operator 就绪后，创建一个最精简的 Collector 实例，接收 OTLP 并将数据输出到 stdout（调试用）：

示例：最小化 Collector


   apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: simplest
spec:
  config:
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
    processors:
      memory_limiter:
        check_interval: 1s
        limit_percentage: 75
        spike_limit_percentage: 15

    exporters:
      debug: {}

    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [memory_limiter]
          exporters: [debug]

提示：

• debug 导出器会将收到的遥测数据打印到 Collector 容器的 stdout，适合联调
• Collector 配置格式仍在演进，升级镜像时注意兼容性

四、部署模式与典型场景

OpenTelemetryCollector CR 的 spec.mode 支持多种模式：

• Deployment：默认；适合网关/集中式 Collector
• DaemonSet：每节点一个实例；适合节点级采集（日志、节点指标）
• StatefulSet：有序、稳定标识；适合需要稳定网络标识或与 Target Allocator 搭配
• Sidecar：随应用 Pod 注入 Collector Sidecar；适合应用就地转发与隔离

参考场景：

• 应用网关模式：Deployment，统一接收应用 OTLP 数据并转发到后端（如 Jaeger/Tempo/OTLP）
• 节点采集模式：DaemonSet，抓取节点/容器级指标与日志
• 有序采集模式：StatefulSet 配合 Target Allocator，实现 Prometheus 抓取的稳定分片
• 极致隔离模式：Sidecar，将 Collector 与业务容器同 Pod 部署，隔离网络与配置

五、Sidecar 注入与自动探针

1) Sidecar Collector 注入

• CR：Sidecar 模式 Collector


   apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: sidecar-for-my-app
spec:
  mode: sidecar
  config:
    receivers:
      jaeger:
        protocols:
          thrift_compact: {}
    exporters:
      debug: {}
    service:
      pipelines:
        traces:
          receivers: [jaeger]
          exporters: [debug]

• 应用 Pod：通过注解开启注入


   apiVersion: v1
kind: Pod
metadata:
  name: myapp
  annotations:
    sidecar.opentelemetry.io/inject: "true"
spec:
  containers:
  - name: myapp
    image: jaegertracing/vertx-create-span:operator-e2e-tests
    ports:
      - containerPort: 8080

注意：

• 当命名空间内存在多个 Sidecar 模式的 CR，应指定具体名称，如 sidecar.opentelemetry.io/inject: "sidecar-for-my-app"
• 对于 Deployment/StatefulSet 等控制器，应将注解写在 PodTemplate 的 metadata.annotations 下

2) 应用自动探针（Instrumentation）

创建 Instrumentation CR，集中定义 SDK 配置、采样、传播器、语言特定变量：


   apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: my-instrumentation
spec:
  exporter:
    endpoint: http://otel-collector:4317
  propagators:
    - tracecontext
    - baggage
    - b3
  sampler:
    type: parentbased_traceidratio
    argument: "0.25"
  python:
    env:
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: http://otel-collector:4318
  dotnet:
    env:
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: http://otel-collector:4318
  go:
    env:
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: http://otel-collector:4318

六、Target Allocator：Prometheus 抓取的“分片调度器”

当 Collector 实例横向扩缩时，Prometheus Receiver 的拉取容易重复或失衡。Target Allocator（TA）作为可选组件，会为每个 Collector Pod 动态下发 http_sd_config 目标列表，实现任务均衡与无重抓。

• 启用 TA 的 Collector 示例（StatefulSet 建议）：


   apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: collector-with-ta
spec:
  mode: statefulset
  targetAllocator:
    enabled: true
  config:
    receivers:
      prometheus:
        config:
          scrape_configs:
          - job_name: 'otel-collector'
            scrape_interval: 10s
            static_configs:
            - targets: [ '0.0.0.0:8888' ]
            metric_relabel_configs:
            - action: labeldrop
              regex: (id|name)
            - action: labelmap
              regex: label_(.+)
              replacement: $$1
    exporters:
      debug: {}
    service:
      pipelines:
        metrics:
          receivers: [prometheus]
          exporters: [debug]

Operator 会将上述配置“重写”为基于 target_allocator 的形式，并为每个 Collector Pod 注入自身 ID（collector_id: $POD_NAME）。另外需要注意：

• Collector 配置中由于支持环境变量替换，Prometheus relabel 中的
• 也可启用 prometheusCR，让 TA 消费 ServiceMonitor/PodMonitor，复用 prometheus-operator 生态
• 使用 Prometheus CR 的最小示例：


   apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: collector-with-ta-prometheus-cr
spec:
  mode: statefulset
  targetAllocator:
    enabled: true
    serviceAccount: everything-prometheus-operator-needs
    prometheusCR:
      enabled: true
      serviceMonitorSelector: {}
      podMonitorSelector: {}
  config:
    receivers:
      prometheus:
        config: {}
    exporters:
      debug: {}
    service:
      pipelines:
        metrics:
          receivers: [prometheus]
          exporters: [debug]

七、结语

OpenTelemetry Operator 将 Collector 管理与多语言自动探针注入“声明式、自动化”地整合到 Kubernetes 生态中，是在大规模集群内落地可观测性的关键基础设施。通过合理的部署模式选择、Target Allocator 分片、资源属性治理与 GitOps 管理，你可以在保证健壮性的同时，显著降低可观测性平台的运维复杂度。

如需进一步阅读与更新，请参考：