字节跳动开源 Kelemetry：面向 Kubernetes 控制面的全局追踪系统

动手点关注

干货不迷路

Kelemetry是字节跳动开发的用于Kubernetes控制平面的追踪系统，它从全局视角串联起多个 Kubernetes 组件的行为，追踪单个 Kubernetes 对象的完整生命周期以及不同对象之间的相互影响。通过可视化 K8s 系统内的事件链路，它使得 Kubernetes 系统更容易观测、更容易理解、更容易 Debug。

背景

在传统的分布式追踪中，“追踪”通常对应于用户请求期间的内部调用。特别是，当用户请求到达时，追踪会从根跨度开始，然后每个内部RPC调用会启动一个新的子跨度。由于父跨度的持续时间通常是其子跨度的超集，追踪可以直观地以树形或火焰图的形式观察，其中层次结构表示组件之间的依赖关系。

与传统的RPC系统相反，Kubernetes API是异步和声明式的。为了执行操作，组件会更新apiserver上对象的规范（期望状态），然后其他组件会不断尝试自我纠正以达到期望的状态。例如，当我们将ReplicaSet从3个副本扩展到5个副本时，我们会将spec.replicas字段更新为5，rs controller会观察到此更改，并不断创建新的pod对象，直到总数达到5个。当kubelet观察到其管理的节点创建了一个pod时，它会在其节点上生成与pod中的规范匹配的容器。

在此过程中，我们从未直接调用过rs controller，rs controller也从未直接调用过kubelet。这意味着我们无法观察到组件之间的直接因果关系。如果在过程中删除了原始的3个pod中的一个，副本集控制器将与两个新的pod一起创建一个不同的pod，我们无法将此创建与ReplicaSet的扩展或pod的删除关联起来。因此，由于“追踪”或“跨度”的定义模糊不清，传统的基于跨度的分布式追踪模型在Kubernetes中几乎不适用。

过去，各个组件一直在实现自己的内部追踪，通常每个“reconcile”对应一个追踪（例如，kubelet追踪只追踪处理单个pod创建/更新的同步操作）。然而，没有单一的追踪能够解释整个流程，这导致了可观察性的孤立岛，因为只有观察多个reconcile才能理解许多面向用户的行为；例如，扩展ReplicaSet的过程只能通过观察副本集控制器处理ReplicaSet更新或pod就绪更新的多个reconcile来推断。

为解决可观察性数据孤岛的问题，Kelemetry以组件无关、非侵入性的方式，收集并连接来自不同组件的信号，并以追踪的形式展示相关数据。

设计

将对象作为跨度

为了连接不同组件的可观察性数据，Kelemetry采用了一种不同的方法，受到kspan项目的启发，与将单个操作作为根跨度的尝试不同，这里为对象本身创建一个跨度，而每个在对象上发生的事件都是一个子跨度。此外，各个对象通过它们的拥有关系连接在一起，使得子对象的跨度成为父对象的子跨度。因此，我们得到了两个维度：树形层次结构表示对象层次结构和事件范围，而时间线表示事件顺序，通常与因果关系