Kubernetes 系统组件的跟踪

系统组件追踪用于记录集群中操作的延迟以及操作之间的关系。

Kubernetes 组件使用 OpenTelemetry 协议 (OTLP) 配合 gRPC 导出器来发送追踪信息，并可以使用 OpenTelemetry Collector 对其进行采集并路由到追踪后端。

追踪采集

Kubernetes 组件内置了用于 OTLP 的 gRPC 导出器，既可以配合 OpenTelemetry Collector 使用，也可以不配合它使用。

有关采集追踪和使用 Collector 的完整指南，请参阅 OpenTelemetry Collector 入门。不过，有一些针对 Kubernetes 组件的注意事项。

默认情况下，Kubernetes 组件在 IANA OpenTelemetry 端口 4317 上使用 gRPC 导出器发送 OTLP 追踪信息。例如，如果 Collector 作为 Sidecar 运行在 Kubernetes 组件旁，以下接收器配置将采集 Span 并将其输出到标准输出：

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  # Replace this exporter with the exporter for your backend
  exporters:
    debug:
      verbosity: detailed
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [debug]

若要直接将追踪信息发送到后端而不使用 Collector，请在 Kubernetes 追踪配置文件中的 endpoint 字段指定所需的追踪后端地址。此方法消除了对 Collector 的需求并简化了整体结构。

对于包含认证详细信息的追踪后端头部配置，可以使用环境变量 OTEL_EXPORTER_OTLP_HEADERS，详情请参阅 OTLP 导出器配置。

此外，对于 Kubernetes 集群名称、命名空间、Pod 名称等追踪资源属性的配置，也可以使用环境变量 OTEL_RESOURCE_ATTRIBUTES，详情请参阅 OTLP Kubernetes 资源。

组件追踪

kube-apiserver 追踪

kube-apiserver 会为传入的 HTTP 请求、发送给 Webhook 和 etcd 的传出请求以及重入请求生成 Span。它会在传出请求中传播 W3C Trace Context，但不会使用传入请求所携带的追踪上下文，因为 kube-apiserver 通常是一个公共端点。

在 kube-apiserver 中启用追踪

要启用追踪，请为 kube-apiserver 提供一个追踪配置文件，参数为 --tracing-config-file=<path-to-config>。以下是一个配置示例，该配置记录每 10,000 个请求中的 1 个，并使用默认的 OpenTelemetry 端点：

apiVersion: apiserver.config.k8s.io/v1
kind: TracingConfiguration
# default value
#endpoint: localhost:4317
samplingRatePerMillion: 100

有关 TracingConfiguration 结构体的更多信息，请参阅 API server 配置 API (v1)。

kubelet 追踪

kubelet 的 CRI 接口和已认证的 HTTP 服务器已被植入仪表以生成追踪 Span。与 apiserver 一样，端点和采样率是可配置的。追踪上下文的传播也已配置。父 Span 的采样决策始终会被遵循。提供的追踪配置采样率将应用于没有父级的 Span。如果在未配置端点的情况下启用，将设置为默认的 OpenTelemetry Collector 接收器地址 "localhost:4317"。

在 kubelet 中启用追踪

要启用追踪，请应用追踪配置。以下是 kubelet 配置的一个示例片段，它记录每 10,000 个请求中的 1 个，并使用默认的 OpenTelemetry 端点：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
tracing:
  # default value
  #endpoint: localhost:4317
  samplingRatePerMillion: 100

如果 samplingRatePerMillion 设置为一百万 (1000000)，则每个 Span 都将被发送到导出器。

Kubernetes v1.36 中的 kubelet 会从垃圾回收、Pod 同步例程以及每个 gRPC 方法中收集 Span。kubelet 会随 gRPC 请求传播追踪上下文，以便具备追踪植入能力的容器运行时（如 CRI-O 和 containerd）能够将其导出的 Span 与来自 kubelet 的追踪上下文相关联。生成的追踪信息将在 kubelet 和容器运行时 Span 之间建立父子链接，这在调试节点问题时提供了有用的上下文。

请注意，导出 Span 总会带来少量的网络和 CPU 性能开销，具体取决于系统的整体配置。如果运行已启用追踪的集群时出现任何此类问题，请通过降低 samplingRatePerMillion 或移除配置以完全禁用追踪来减轻该问题。

稳定性

追踪植入仍处于活跃开发阶段，可能会以多种方式发生变化。这包括 Span 名称、附加属性、已植入的端点等。在该特性达到稳定之前，不对追踪植入的向后兼容性做任何保证。

接下来

• 阅读关于 OpenTelemetry Collector 入门
• 阅读关于 OTLP 导出器配置