為什么選擇 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），僅供參考