kubelet PLEG 实现

news2024/10/10 21:00:49

概述

kubelet的主要作用是确保pod状态和podspec保持一致，这里的pod状态包括pod中的container状态，个数等。

为了达到这个目的，kubelet需要从多个来源watch pod spec的变化，并周期从container runtime获取最新的container状态。比如创建了包括三个container的pod，当其中一个container异常退出时，kubelet能通过PLEG及时发现此事件并重建container。

PLEG(pod lifecycle event generate)是kubelet中的一个子模块，周期从container runtime获取最新的container状态，生成pod生命周期事件，并将此事件发到channel中，kubelet从channel获取事件进行相应的处理。

PLEG 全称是 Pod Lifecycle Event Generator，用来为 kubelet 生成 container runtime 的 pod 生命周期事件，这样 kubelet 就可以根据 pod 的 spec 和 status 对比，来执行对应的控制逻辑。

在 1.1 及之前的 kubelet 中是没有 PLEG 的实现的。kubelet 会为每个 pod 单独启动一个 worker，这个 worker 负责向 container runtime 查询该 pod 对应的 sandbox 和 container 的状态，并进行状态同步逻辑的执行。这种 one worker per pod 的 polling 模型给 kubelet 带来了较大的性能损耗。即使这个 pod 没有任何的状态变化，也要不停的对 container runtime 进行主动查询。

因此在 1.2 中，kubelet 引入了 PLEG，将所有 container runtime 上 sandbox 和 container 的状态变化事件统一到 PLEG 这个单独的组件中，实现了 one worker all pods。这种实现相比于 one worker per pod 已经带来了较大的性能提升，详细实现会在后文进行介绍。但是默认情况下，仍然需要每秒一次的主动向 container runtime 查询，在 node 负载很高的情况下，依然会有一定的性能问题，比较常见的情况是导致 node not ready，错误原因是 PLEG is not healthy。

在 1.26 中，kubelet 引入了 Evented PLEG，为了和之前的 PLEG 实现区别，之前的 PLEG 称为 Generic PLEG。当然，Evented PLEG 并不是为了取代 Generic PLEG，而是和 Generic PLEG 配合，降低 Generic PLEG 的 polling 频率，从而提高性能的同时，也能保证实时性。

kubelet 组件中的模块

上图展示了 kubelet 组件中的模块以及模块间的划分。

PLEG(Pod Lifecycle Event Generator） PLEG 是 kubelet 的核心模块,PLEG 会一直调用 container runtime 获取本节点 containers/sandboxes 的信息，并与自身维护的 pods cache 信息进行对比，生成对应的 PodLifecycleEvent，然后输出到 eventChannel 中，通过 eventChannel 发送到 kubelet syncLoop 进行消费，然后由 kubelet syncPod 来触发 pod 同步处理过程，最终达到用户的期望状态。

Generic PLEG

Generic PLEG 定时(默认1s)向 runtime 进行查询，这个过程称为 relist，这里会调用 cri 的 ListPodSandbox 和 ListContainers接口。runtime 返回所有的数据之后，PLEG会根据sandbox 和 container上的数据，对应的Pod 上并更新到缓存中。同时组装成事件向 PLEG Channel 发送。