为什么选择 LeaderWorkerSet对比 StatefulSet 与 Deployment 的 5 大核心优势【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws如果你正在用 Kubernetes 部署 LLM 推理服务、多机分布式训练或需要一组 Pod 协同工作的 AI/ML 工作负载你一定纠结过该用Deployment还是StatefulSet。但两者都默认把每个 Pod 当作独立的复制单元无法表达1 个 Leader N 个 Worker 必须作为一个整体的语义。LeaderWorkerSetLWS正是 Kubernetes SIG 推出的新工作负载 API它把一组 Pod 当作一个超级 Pod进行复制为多节点推理、张量并行、预填充/解码分离等场景提供了更贴合的抽象。本文用 5 大核心优势帮你快速判断它是否适合你的场景。先看问题Deployment 和 StatefulSet 为什么不够用Deployment只保证有 N 个相同的 PodPod 无稳定身份彼此完全对等无法表达 Leader/Worker 分工。StatefulSet解决了稳定身份和有序部署但每个 Pod 仍是独立单元Pod 之间没有强关联滚动更新、故障恢复都是逐个 Pod进行。对分布式推理来说模型被切分到多张卡上Leader 负责汇总、Worker 负责分片计算任何一个 Pod 挂了整个推理服务都可能不可用。这种同生共死的语义传统工作负载 API 表达不了——这正是 LWS 存在的意义。核心优势一Leader Worker 双模板一组 Pod 才是复制单元LWS 引入leaderWorkerTemplate允许为 Leader 和 Worker 分别定义模板一个组 1 个 Leader M 个 Worker整个组才是一份副本。创建时组内 Pod并行创建、共享生命周期并拥有从 0 到 N-1 的唯一索引身份便于服务发现和组内寻址。一个最小示例只比普通 YAML 多几行apiVersion: leaderworkerset.x-k8s.io/v1 kind: LeaderWorkerSet metadata: name: leaderworkerset-sample spec: replicas: 3 leaderWorkerTemplate: size: 4 # 每组 1 个 Leader 3 个 Worker workerTemplate: spec: containers: - name: nginx image: nginxinc/nginx-unprivileged:1.27字段定义可参考 API 源码 leaderworkerset_types.go完整示例见 lws.yaml。运行后你会看到sample-0、sample-0-1、sample-0-2… 这样清晰的组 组内索引命名。核心优势二Gang Scheduling 全或无调度杜绝半个组在跑分布式推理最怕部分调度Worker 只起了 2 个、Leader 还在 Pending请求进来只能报错。LWS 支持Gang Scheduling整组 Pod 以全有或全无的方式被调度——要么整组成功要么整组等待从根源上避免资源浪费和死锁。结合 K8s 官方 KEP 文档 keps/407-gang-scheduling/README.md 可以了解设计细节。对于需要在同一批节点上协同工作的训练/推理任务这一特性价值巨大。核心优势三组级滚动更新升级时整组一起切换StatefulSet 的滚动更新是一个 Pod 一个 Pod 地滚对分布式推理来说新旧版本 Pod 混跑会导致模型版本不一致、张量切分错乱。LWS 的滚动更新以组为单位每次整体更新一组更新完再动下一组天然保证组内版本永远一致。它还支持maxUnavailable和maxSurge两个参数你可以同时控制最多允许多少组不可用与最多额外多起几组实现真正的零停机升级spec: rolloutStrategy: type: RollingUpdate rollingUpdateConfiguration: maxUnavailable: 2 maxSurge: 2 replicas: 4原理讲解与分阶段推演表参见官方文档 rollout-strategy/_index.md。核心优势四拓扑感知放置把整组钉在一起跨节点推理的通信延迟直接影响性能。LWS 支持拓扑感知放置通过一行注解让同一组的 Pod 被调度到同一机架rack、同一可用区最大化跨节点带宽利用率metadata: annotations: leaderworkerset.sigs.k8s.io/exclusive-topology: rack更进一步LWS 还提供SubGroup 子组能力例如预填充prefill和解码decode服务器可以各自成组调度到同一机架而两组之间又保持在同一个可用区兼顾性能与可用性。详见 KEP 文档 keps/115-Subgroup-support/README.md。核心优势五全或无重启故障处理组内一致当组内某个 Pod 崩溃时LWS 默认执行RecreateGroupOnPodRestart整组 Pod 全部重建保证所有成员从同一状态重新启动——这对需要强一致状态的多机推理至关重要。当然你也可以通过restartPolicy切换策略RecreateGroupOnPodRestart默认一损俱损整组重建。RecreateGroupAfterStart启动完成前不触发整组重建避免大镜像拉取被中断。None只重启失败 Pod适合松耦合场景。配置方式与行为对比详见官方文档 failure-handling/_index.md。快速开始3 分钟跑起来准备一个Kubernetes ≥ 1.26的集群安装 kubectl。安装 LWS 控制器支持 kubectl、Helm 两种方式见 installation/_index.md。使用上方示例 YAML 创建 LeaderWorkerSet即可看到组内 Pod 并行启动。想从源码构建体验可 clone 仓库git clone https://gitcode.com/gh_mirrors/lws2/lws控制器核心实现位于 pkg/controllers/leaderworkerset_controller.goWebhook 校验逻辑在 pkg/webhooks/leaderworkerset_webhook.go适合想深入源码的读者。一张表帮你做决定什么时候该用谁场景推荐理由无状态 Web / API 服务Deployment简单Pod 对等有状态单机服务数据库等StatefulSet稳定身份 持久化多机 LLM 推理、张量并行、Leader/Worker 分工LeaderWorkerSet组级复制、组级滚动、全或无调度预填充/解码分离等分角色部署LeaderWorkerSet DisaggregatedSet多角色协同扩缩容与滚动小结简单说Deployment 管一堆一样的 PodStatefulSet 管一堆有身份的 Pod而 LeaderWorkerSet 管一组必须同生共死的 Pod。如果你的工作负载是 LLM 推理、分布式训练这类多节点强耦合场景LeaderWorkerSet 的组级复制、Gang Scheduling、组级滚动更新与全或无故障恢复几乎是为你量身定制的 5 大优势。想了解更多可继续阅读官方概念文档 concepts/_index.md 和 overview/_index.md也可以看看 docs/examples 中的 vLLM、SGLang、TensorRT-LLM 等真实推理框架示例。【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为什么选择 LeaderWorkerSet？对比 StatefulSet 与 Deployment 的 5 大核心优势
为什么选择 LeaderWorkerSet对比 StatefulSet 与 Deployment 的 5 大核心优势【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws如果你正在用 Kubernetes 部署 LLM 推理服务、多机分布式训练或需要一组 Pod 协同工作的 AI/ML 工作负载你一定纠结过该用Deployment还是StatefulSet。但两者都默认把每个 Pod 当作独立的复制单元无法表达1 个 Leader N 个 Worker 必须作为一个整体的语义。LeaderWorkerSetLWS正是 Kubernetes SIG 推出的新工作负载 API它把一组 Pod 当作一个超级 Pod进行复制为多节点推理、张量并行、预填充/解码分离等场景提供了更贴合的抽象。本文用 5 大核心优势帮你快速判断它是否适合你的场景。先看问题Deployment 和 StatefulSet 为什么不够用Deployment只保证有 N 个相同的 PodPod 无稳定身份彼此完全对等无法表达 Leader/Worker 分工。StatefulSet解决了稳定身份和有序部署但每个 Pod 仍是独立单元Pod 之间没有强关联滚动更新、故障恢复都是逐个 Pod进行。对分布式推理来说模型被切分到多张卡上Leader 负责汇总、Worker 负责分片计算任何一个 Pod 挂了整个推理服务都可能不可用。这种同生共死的语义传统工作负载 API 表达不了——这正是 LWS 存在的意义。核心优势一Leader Worker 双模板一组 Pod 才是复制单元LWS 引入leaderWorkerTemplate允许为 Leader 和 Worker 分别定义模板一个组 1 个 Leader M 个 Worker整个组才是一份副本。创建时组内 Pod并行创建、共享生命周期并拥有从 0 到 N-1 的唯一索引身份便于服务发现和组内寻址。一个最小示例只比普通 YAML 多几行apiVersion: leaderworkerset.x-k8s.io/v1 kind: LeaderWorkerSet metadata: name: leaderworkerset-sample spec: replicas: 3 leaderWorkerTemplate: size: 4 # 每组 1 个 Leader 3 个 Worker workerTemplate: spec: containers: - name: nginx image: nginxinc/nginx-unprivileged:1.27字段定义可参考 API 源码 leaderworkerset_types.go完整示例见 lws.yaml。运行后你会看到sample-0、sample-0-1、sample-0-2… 这样清晰的组 组内索引命名。核心优势二Gang Scheduling 全或无调度杜绝半个组在跑分布式推理最怕部分调度Worker 只起了 2 个、Leader 还在 Pending请求进来只能报错。LWS 支持Gang Scheduling整组 Pod 以全有或全无的方式被调度——要么整组成功要么整组等待从根源上避免资源浪费和死锁。结合 K8s 官方 KEP 文档 keps/407-gang-scheduling/README.md 可以了解设计细节。对于需要在同一批节点上协同工作的训练/推理任务这一特性价值巨大。核心优势三组级滚动更新升级时整组一起切换StatefulSet 的滚动更新是一个 Pod 一个 Pod 地滚对分布式推理来说新旧版本 Pod 混跑会导致模型版本不一致、张量切分错乱。LWS 的滚动更新以组为单位每次整体更新一组更新完再动下一组天然保证组内版本永远一致。它还支持maxUnavailable和maxSurge两个参数你可以同时控制最多允许多少组不可用与最多额外多起几组实现真正的零停机升级spec: rolloutStrategy: type: RollingUpdate rollingUpdateConfiguration: maxUnavailable: 2 maxSurge: 2 replicas: 4原理讲解与分阶段推演表参见官方文档 rollout-strategy/_index.md。核心优势四拓扑感知放置把整组钉在一起跨节点推理的通信延迟直接影响性能。LWS 支持拓扑感知放置通过一行注解让同一组的 Pod 被调度到同一机架rack、同一可用区最大化跨节点带宽利用率metadata: annotations: leaderworkerset.sigs.k8s.io/exclusive-topology: rack更进一步LWS 还提供SubGroup 子组能力例如预填充prefill和解码decode服务器可以各自成组调度到同一机架而两组之间又保持在同一个可用区兼顾性能与可用性。详见 KEP 文档 keps/115-Subgroup-support/README.md。核心优势五全或无重启故障处理组内一致当组内某个 Pod 崩溃时LWS 默认执行RecreateGroupOnPodRestart整组 Pod 全部重建保证所有成员从同一状态重新启动——这对需要强一致状态的多机推理至关重要。当然你也可以通过restartPolicy切换策略RecreateGroupOnPodRestart默认一损俱损整组重建。RecreateGroupAfterStart启动完成前不触发整组重建避免大镜像拉取被中断。None只重启失败 Pod适合松耦合场景。配置方式与行为对比详见官方文档 failure-handling/_index.md。快速开始3 分钟跑起来准备一个Kubernetes ≥ 1.26的集群安装 kubectl。安装 LWS 控制器支持 kubectl、Helm 两种方式见 installation/_index.md。使用上方示例 YAML 创建 LeaderWorkerSet即可看到组内 Pod 并行启动。想从源码构建体验可 clone 仓库git clone https://gitcode.com/gh_mirrors/lws2/lws控制器核心实现位于 pkg/controllers/leaderworkerset_controller.goWebhook 校验逻辑在 pkg/webhooks/leaderworkerset_webhook.go适合想深入源码的读者。一张表帮你做决定什么时候该用谁场景推荐理由无状态 Web / API 服务Deployment简单Pod 对等有状态单机服务数据库等StatefulSet稳定身份 持久化多机 LLM 推理、张量并行、Leader/Worker 分工LeaderWorkerSet组级复制、组级滚动、全或无调度预填充/解码分离等分角色部署LeaderWorkerSet DisaggregatedSet多角色协同扩缩容与滚动小结简单说Deployment 管一堆一样的 PodStatefulSet 管一堆有身份的 Pod而 LeaderWorkerSet 管一组必须同生共死的 Pod。如果你的工作负载是 LLM 推理、分布式训练这类多节点强耦合场景LeaderWorkerSet 的组级复制、Gang Scheduling、组级滚动更新与全或无故障恢复几乎是为你量身定制的 5 大优势。想了解更多可继续阅读官方概念文档 concepts/_index.md 和 overview/_index.md也可以看看 docs/examples 中的 vLLM、SGLang、TensorRT-LLM 等真实推理框架示例。【免费下载链接】lwsLeaderWorkerSet: An API for deploying a group of pods as a unit of replication项目地址: https://gitcode.com/gh_mirrors/lws2/lws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考