LeaderWorkerSet 源码解读：控制器架构与 Executor/Planner 工作原理完全剖析

LeaderWorkerSet 源码解读控制器架构与 Executor/Planner 工作原理完全剖析【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lwsLeaderWorkerSet 是一个把一组 Pod 当作复制单元来部署的 Kubernetes 原生 API而它的核心引擎就是由控制器、Executor 与 Planner 组成的协调系统。这篇 LeaderWorkerSet 源码解读将带你从零看懂控制器架构深入剖析滚动更新中 Executor 如何执行动作、Planner 如何规划每一步帮助新手快速建立对这套调度机制的整体认知。先看整体控制器架构的四大成员LeaderWorkerSet 的控制平面由多个控制器协同工作它们各司其职共同完成Leader Worker 分组的完整生命周期管理LeaderWorkerSetReconciler主控制器负责 Leader StatefulSet、ControllerRevision 与 Headless Service 的创建和滚动更新是整个 LWS 的总调度室。Pod Controller监听 Leader Pod 的创建事件为每一个 Leader 动态创建对应的 Worker StatefulSet实现一 Leader 一 Worker 组的拓扑。Pod Webhook在 Pod 创建时注入标签与调度亲和性为分组调度如 Volcano 的 PodGroup做好准备。DisaggregatedSetReconciler在 DisaggregatedSet解耦集场景下协调多个 LWS 实例与多个角色Role其内部正是依赖 Executor 与 Planner 完成复杂的多角色滚动更新。主控制器的入口在 leaderworkerset_controller.go一次 Reconcile 会依次完成获取 LWS 对象 → 获取/创建 ControllerRevision → 计算滚动更新分区 → 用 SSA 更新 Leader StatefulSet → 协调 Headless Service → 更新状态。整个过程围绕以 StatefulSet 为复制单元、以 Revision 为版本依据展开。一次协调的完整流水线主控制器的协调流程可以概括为四个关键步骤版本管理通过 getOrCreateRevisionIfNonExist 保证每个 LWS 都对应一个 ControllerRevision检测到 Spec 变化时创建新 Revision作为滚动更新的版本基准。计算分区rollingUpdateParameters根据当前版本与目标版本计算出 partition 值决定这次更新哪几个副本。执行更新SSAWithStatefulset用 Server-Side Apply 更新 Leader StatefulSet并把 partition 写入滚动更新策略。收尾协调创建共享 Headless Service更新 Status并在更新完成后裁剪历史 Revision。上图展示了 Pod 创建的动态协作过程StatefulSet Controller 创建 Leader Pod → API Server 触发 Pod Webhook 注入 PodGroup 关联 → Pod Controller 侦测到 Leader Pod 后创建专属的 Worker StatefulSet → 再由 StatefulSet Controller 创建 Worker Pod。这条Sts → Webhook → Pod Controller的链路就是 LWS 复制单元得以成型的核心机制。Executor 工作原理滚动更新的执行引擎当 DisaggregatedSet 需要把多个角色的 LWS 滚动升级到新版本时就轮到 Executor 登场。它的核心实现在 executor.go包含两个阶段阶段一初始化滚动更新initRollingUpdate给每个旧版本 LWS 打上initial-replicas注解快照当前副本数作为后续比例排空的基线。按角色Role创建新版本 LWS副本数从 0 开始等待下一轮协调逐步扩容。检测角色增删detectRoleChanges把新增/移除的角色纳入更新范围。阶段二推进滚动更新ReconcileRollingUpdate先检查新版本是否稳定每个角色的 ReadyReplicas Replicas不稳定就等 1 秒再试避免过度扩容。调用 Planner 计算下一步动作ComputeNextStep。执行动作scaleUpNew扩容新版本scaleDownOld按新创建的优先排空策略缩容旧版本。值得注意的细节是排空时的**协同排空coordinated drain**逻辑executor.go当某个角色缩容到 0 时同一 Revision 下所有角色会一起归零保证一组 Pod作为一个整体被回收而不是留下孤立的 Worker。Planner 工作原理每一步该怎么做Planner 是一个纯函数式的规划器核心函数 ComputeNextStep 不接触 API Server只根据四个输入初始旧副本、当前旧副本、当前新副本、目标新副本和滚动更新配置计算出下一步应该把副本调整到多少。它的数学基础是线性插值把整个滚动更新理想化为 totalSteps 步每一步新版本按ceil(i * target / totalSteps)增长旧版本按floor(i * initialOld / totalSteps)排空。由于控制器是无状态的Planner 从当前观测到的副本数反推出进行到第几步再算出下一步目标。规划器的决策优先级在 planner.go 中清晰可见异常纠正如果当前旧副本超过初始值先纠正到合理范围。新版本到位如果新版本已达目标直接把旧版本全部排空。尝试扩容tryScaleUp在满足old new target maxSurge的前提下优先扩容新版本。比例排空tryProportionalDrain无法扩容时按比例缩容旧版本并保证不低于 maxUnavailable 约束。强制排空tryForceDrain兜底策略必要时为新版本腾出 surge 配额。其中还有一个防止孤儿组的保护逻辑applyOrphanPrevention如果某个角色要排空到 0 而其他角色还没准备好会强制保留至少 1 个副本避免 Leader 与 Worker 组被拆散。Executor 与 Planner 的协作闭环Executor 与 Planner 的分工非常清晰Planner 负责想Executor 负责做。每一轮协调中Executor 从集群读取真实状态交给 Planner 计算下一步再把计算结果翻译成对 LWS 的 Scale 操作经由 lws_manager.go 的Scale方法以 Patch 方式修改副本数并发出 ScalingUp / ScalingDown 事件。如此反复直到 Planner 判定滚动更新完成所有旧副本归零、新副本达到目标。这种无状态规划 有状态执行的设计带来两大好处一是控制器重启后可以从当前集群状态无缝恢复不需要额外记录中间步骤二是所有决策集中在一个纯函数里可以用 ComputeAllSteps 模拟整场滚动更新让测试变得异常简单可靠。总结理解 LWS 控制器的三句话控制器负责编排管版本、管 StatefulSet、管 Service是所有资源的大脑。Planner负责计算用线性插值模型把复杂的多角色滚动更新拆解为可执行的每一步。Executor负责执行读取规划结果安全地扩容新版本、排空旧版本并保证 Leader/Worker 组的完整性。读完这篇 LeaderWorkerSet 源码解读你已经掌握了控制器架构的骨架与 Executor/Planner 的工作原理。沿着 pkg/controllers 目录继续阅读各控制器的测试文件你会发现每个算法细节都有对应的测试用例是理解这套机制最好的活文档。【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考