Kubernetes系统组件追踪

在 Kubernetes 中，系统组件追踪功能可以记录集群操作的时延信息以及这些操作之间的关系。Kubernetes 组件使用 gRPC 导出器的 OpenTelemetry 协议来发送追踪信息。并用OpenTelemetry Collector 收集追踪信息，再将其转交给追踪系统的后台。

一、收集追踪信息

默认情况下，Kubernetes 组件使用 gRPC 的 OTLP 导出器来导出追踪信息，将信息写到 IANA OpenTelemetry 端口。 举例来说，如果收集器以 Kubernetes 组件的边车模式运行， 以下接收器配置会收集 span 信息，并将它们写入到标准输出。

receivers:
otlp:
protocols:
grpc:
exporters:
# 用适合后端环境的导出器替换此处的导出器
logging:
logLevel: debug
service:
pipelines:
traces:
receivers: [otlp]
exporters: [logging]

二、组件追踪

1、kube-apiserver追踪

kube-apiserver 为传入的 HTTP 请求、传出到 webhook 和 etcd 的请求以及重入的请求生成 span。 由于 kube-apiserver 通常是一个公开的端点，所以它通过出站的请求传播 W3C 追踪上下文， 但不使用入站请求的追踪上下文。

2、kube-apiserver启用追踪

要启用追踪特性，需要使用 --tracing-config-file=<<配置文件路径> 为 kube-apiserver 提供追踪配置文件。下面是一个示例配置，它为万分之一的请求记录 span，并使用了默认的 OpenTelemetry 端点。

apiVersion: apiserver.config.k8s.io/v1beta1
kind: TracingConfiguration
# 默认值
#endpoint: localhost:4317
samplingRatePerMillion: 100

3、kubelet 追踪

kubelet CRI 接口和实施身份验证的 HTTP 服务器被插桩以生成追踪 span。 与 API 服务器一样，端点和采样率是可配置的。 追踪上下文传播也是可以配置的。始终优先采用父 span 的采样决策。 用户所提供的追踪配置采样率将被应用到不带父级的 span。

如果在没有配置端点的情况下启用，将使用默认的 OpenTelemetry Collector 接收器地址 “localhost:4317”。

4、kubelet启用追踪

要启用追踪，需应用追踪配置。 以下是 kubelet 配置的示例代码片段，每 10000 个请求中记录一个请求的 span，并使用默认的 OpenTelemetry 端点：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
KubeletTracing: true
tracing:
# 默认值
#endpoint: localhost:4317
samplingRatePerMillion: 100

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

Kubernetes v1.28 中的 kubelet 收集与垃圾回收、Pod 同步例程以及每个 gRPC 方法相关的 Span。 kubelet 借助 gRPC 来传播跟踪上下文，以便 CRI-O 和 containerd 这类带有跟踪插桩的容器运行时可以在其导出的 Span 与 kubelet 所提供的跟踪上下文之间建立关联。所得到的跟踪数据会包含 kubelet 与容器运行时 Span 之间的父子链接关系，从而为调试节点问题提供有用的上下文信息。

请注意导出 span 始终会对网络和 CPU 产生少量性能开销，具体取决于系统的总体配置。 如果在启用追踪的集群中出现类似性能问题，可以通过降低 samplingRatePerMillion 或通过移除此配置来彻底禁用追踪来缓解问题。

三、稳定性

追踪工具仍在积极开发中，未来它会以多种方式发生变化。 这些变化包括：span 名称、附加属性、检测端点等等。 此类特性在达到稳定版本之前，不能保证追踪工具的向后兼容性。