html网站模板下载,扬州大发网站建设,电脑培训机构哪个好,做冷冻食品的网站概述 kubelet的主要作用是确保pod状态和podspec保持一致#xff0c;这里的pod状态包括pod中的container状态#xff0c;个数等。 为了达到这个目的#xff0c;kubelet需要从多个来源watch pod spec的变化#xff0c;并周期从container runtime获取最新的container状态。比如…概述 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 发送。 kubelet 会在 pod sync loop 中监听 PLEG Channel从而针对状态变化执行相应的逻辑来尽量保证 pod spec 和 status 的一致。 Evented PLEG
引入 Evented PLEG 后对 Generic PLEG 做了些许调整主要是 relist 的周期和阈值以及对缓存的更新策略。
relist 的同步周期由 1s 增加到 300s。同步阈值从 3min 增加到 10min。缓存更新时updateTime 不再是取本地的时间而是 runtime 返回的时间。
除此之外Generic PLEG 会和之前一样运行这样也保证了及时 Evented PLEG 丢失了一些状态变更的 event也可以由 Generic PLEG 兜底。
Evented PLEG 会调用 runtime 的 GetContainerEvents 来监听 runtime 中的事件然后生成 pod 的 event并发送到 PLEG Channel 中供 kubelet pod sync loop 消费。
如果 Evented 不能按照预期工作比如 runtime 不支持 GetContainerEvents还会降级到 Generic PLEG。降级逻辑是
停止自己停止已有的 Generic PLEG更新 Generic PLEG 的 relist 周期和阈值为 1s, 3min启动新的 Generic PLEG 因为 Evented PLEG 和 Generic PLEG 会同时更新缓存所以在更新时还会对比当前值和缓存值的时间戳保证当前值是更新的状态才会更新到缓存中。 参考文章
Kubelet: Pod Lifecycle Event Generator (PLEG)KEP-3386: Kubelet Evented PLEG for Better Performance
