在 Kubernetes 上用 Helm 部署 OpenTelemetry Collector 完整指南

在 Kubernetes 中部署 OpenTelemetry Collector，官方 Helm Chart 是最省事的路径——它把 RBAC 权限、工作负载配置、服务暴露打包成模板，经配置与验证后部署；但要用好它，得先理解 values 覆盖、Presets 预设与部署模式这三个核心概念。

核心要点速览

• Helm Chart 通过 values.yaml 覆盖默认配置，切勿直接改模板；
• Presets 是一键开启的预置功能包（如 K8s 元数据富化），自动处理 RBAC；
• DaemonSet 贴近数据源、Deployment 便于集中处理，可组合使用；
• Collector 接入后端前，应分别确认接收器、导出器协议和网络可达性。

部署前先懂三个概念

1. 配置文件与默认 values：Chart 自带完整的默认配置，你的 values.yaml 只做增量覆盖。所有定制都发生在这一层，保留 values 便于迁移，但升级仍需核对字段、默认项与组件兼容性。

2. Presets 预设：复杂功能的一键开关。比如开启 kubernetesAttributes 预设，Chart 会自动创建所需 RBAC 权限，并配置好 k8sattributes 处理器，为遥测数据附加 Pod 名、命名空间、节点等 K8s 元数据——手动配这些要写几十行 YAML。

3. 环境变量替换：敏感信息（Token、密钥）不要写死在 values 里，通过环境变量注入，配置中以 ${env:VAR_NAME} 引用。

两种部署模式怎么选？

生产环境常见组合：DaemonSet 做节点级采集（Agent 角色），Deployment 做集群级汇聚（Gateway 角色），两层各司其职。

部署实操步骤

前置条件：与选定 Chart 兼容的 Kubernetes/Helm 版本及集群部署权限。以下固定 Chart 0.176.0、Contrib 0.162.0；需先在同一 namespace 建立 Secret datakit-otlp-endpoint，其 traces-url 保存接收端完整 HTTP Trace URL（含实际端口/路径），不凭空添加 Token Header。

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

准备 values.yaml：

mode: daemonset
image:
  repository: otel/opentelemetry-collector-contrib
  tag: "0.162.0"
command:
  name: otelcol-contrib

presets:
  kubernetesAttributes:
    enabled: true

extraEnvs:
  - name: DATAKIT_TRACES_URL
    valueFrom:
      secretKeyRef:
        name: datakit-otlp-endpoint
        key: traces-url

resources:
  requests:
    cpu: 100m
    memory: 256Mi
  limits:
    cpu: "1"
    memory: 1Gi

ports:
  otlp:
    enabled: true
    hostPort: 4317
  otlp-http:
    enabled: true
    hostPort: 4318
  jaeger-compact:
    enabled: false
  jaeger-thrift:
    enabled: false
  jaeger-grpc:
    enabled: false
  zipkin:
    enabled: false

config:
  receivers:
    jaeger: null
    prometheus: null
    zipkin: null
    otlp:
      protocols:
        grpc:
          endpoint: ${env:MY_POD_IP}:4317
        http:
          endpoint: ${env:MY_POD_IP}:4318
  processors:
    memory_limiter:
      check_interval: 5s
      limit_percentage: null
      spike_limit_percentage: null
      limit_mib: 800
      spike_limit_mib: 150
    batch:
      send_batch_size: 8192
      timeout: 5s
  exporters:
    debug: null
    otlp_http/datakit:
      traces_endpoint: ${env:DATAKIT_TRACES_URL}
  service:
    pipelines:
      logs: null
      metrics: null
      traces:
        receivers: [otlp]
        processors: [memory_limiter, k8s_attributes, batch]
        exporters: [otlp_http/datakit]

部署：

helm install otel-collector open-telemetry/opentelemetry-collector --version 0.176.0 -f values.yaml

配置要点解读

• memory_limiter 必须放在管道第一个处理器：它在接近配置阈值时拒绝数据，但不能保证避免 OOM，需结合容器限额和实际负载验证；
• 元数据处理后再 batch：攒批导出，显著降低后端请求压力；
• K8s 元数据富化：kubernetesAttributes 预设在资源身份可关联且权限/配置正确时附加 Pod/命名空间标签，不能保证每条数据都能关联，后续按业务维度聚合全靠它；
• CORS：若接收浏览器直发的 OTLP 流量，HTTP 接收器需配置 cors.allowed_origins；CORS 不是认证或网络访问控制。

配置 DataKit 作为接收端

后端使用观测云时，可以按 DataKit Kubernetes 部署文档配置 DaemonSet，再让 Collector 向已启用的 OTLP 接收端导出。应用清单前，先核对工作空间地址、权限与采集器配置：

# 应用观测云控制台生成的 datakit.yaml
kubectl apply -f datakit.yaml

按 OpenTelemetry 接入文档检查 DataKit 的实际监听地址与协议；Collector 的 exporter 需与之匹配，不能把示例中的 4318 当作 DataKit 默认端口。先发送一条测试链路，核对服务名和 Pod 标签，再决定是否调整原有 Collector 处理器。

常见问题（FAQ）

Q：DaemonSet 模式下应用怎么找到 Collector？ 示例开放 hostPort，网络策略与节点路由允许时可通过 status.hostIP 指向本节点；需核对 eligible node、端口冲突与协议。Deployment 应移除 hostPort，改用 Service 地址，不保证同节点或最低延迟。

Q：Chart 升级会丢配置吗？ 可能受默认项、字段和组件改名影响。保留 values，先 render 并检查配置、探针、RBAC 与后端连通性；本例使用新组件名 k8s_attributes/otlp_http，显式移除默认日志/指标管道并保留健康检查。

Q：资源限额设多少？ 视流量而定，示例 requests 100m/256Mi、limits 1C/1Gi 只是演示，需实测流量、队列与拒绝率决定容量；按《监控 Collector》的指标持续调优。

Q：多集群怎么管理配置？ values.yaml 按集群分层（基础层 + 集群覆盖层），用 Helm 的 -f 多文件叠加，或上 GitOps（ArgoCD/Flux）统一管理。

系列阅读

• 上一篇：《OpenTelemetry 对接 Prometheus 后端》
• 下一篇：《Go OpenTelemetry 链路追踪》
• 相关：《OpenTelemetry Collector 详解》 · 《OpenTelemetry 最佳实践》 · 《返回索引》

[1]: 观测云文档《DataKit》https://docs.guance.com/datakit/
[2]: 观测云文档《OpenTelemetry》https://docs.guance.com/integrations/opentelemetry/