在現代的大規模雲端運算環境中，批處理任務（Batch Workloads）的調度與資源管理一直是技術挑戰的核心。這類任務通常涉及大量且非即時的計算工作，例如數據分析、模型訓練或影片轉碼，其特點是需要大量資源且對執行順序與優先級有特定要求。Netflix 作為全球領先的串流媒體平台，長期以來依賴其自研的容器平台 Titus 以及配套的批處理管理系統 Compute Managed Batch (CMB) 來處理海量任務。然而，隨著雲原生生態的演進，自研系統在維護成本與功能迭代上逐漸面臨瓶頸。
根據 InfoQ 的報導，Netflix 近期決定將大部分的批處理工作負載遷移至 Kueue。Kueue 是一個開源的 Kubernetes 原生批處理工作執行系統，旨在解決 Kubernetes 原生 Job 物件在處理大規模排隊、資源配額管理以及多租戶優先級調度時的不足。對於 Netflix 而言，這次遷移不僅是工具的替換，更是將內部私有實作轉向工業標準化路徑的戰略調整。
自研系統的侷限與遷移動機
Netflix 的 CMB 系統於 2018 年推出，當時的主要目標是在 Titus 容器平台上實現租戶層級的容量管理，並支持跨多個單元（Cells，即多個 Kubernetes 集群）的聯合工作負載調度。在當時的技術背景下，CMB 提供了必要的租戶層級管理與資源分配能力，滿足了業務成長的需求。
然而，隨著時間推移，工程團隊發現 CMB 的開發難度日益增加。主要原因在於 CMB 並非原生整合在 Kubernetes 生態中，導致在引入新功能時必須投入大量人力去同步 Kubernetes 的演進。與此同時，許多 CMB 曾經領先的自研功能，如今已在開源社群中被成熟地實作。面對這種情況，繼續維護一個與主流生態脫節的自研系統，其成本已遠高於遷移至開源解決方案的風險。
Kueue 的核心運作與技術對接
Kueue 作為替代方案的核心價值在於它能為 Kubernetes 提供強大的工作隊列管理能力。它並不直接取代 Kubernetes 的調度器（Scheduler），而是作為一個管理層，決定哪些工作應該在何時被提交到集群中執行。Kueue 提供了基於優先級的隊列策略、進階的資源管理、以及感知拓撲（Topology-aware）的多集群調度能力，這與 Netflix 原有的 CMB 需求高度契合。
為了確保遷移過程的平滑，Netflix 採取了 API 兼容策略，使現有用戶在無需更改操作習慣的情況下完成切換。在技術對接上，Netflix 將 CMB 內部的租戶（Tenants）對應到 Kueue 的 Cohorts（協作組），而將葉子租戶（Leaf Tenants）對應到 ClusterQueue（集群隊列）與 LocalQueue（本地隊列）的組合。此外，透過 Resource Flavors（資源風味）與名義配額（Nominal Quotas）的配置，Netflix 成功將原有的容量需求定義導入到 Kueue 中。
實務影響與性能優化
目前 Netflix 已在生產環境中利用 Kueue 管理數百萬個批處理工作負載。最顯著的成效之一是資源利用率的提升。透過導入基於搶佔（Preemption）的公平共享機制，系統可以在維持預留資源語義的同時，將閒置容量暫時借給其他租戶使用。這種動態調整能力大幅減少了計算資源的浪費。
在遷移過程的實作經驗中，Netflix 分享了兩個關鍵策略。首先是採取先難後易的遷移順序，他們優先將最大且最複雜的客戶遷移至新系統。這種做法雖然初期壓力較大，但能迅速驗證系統在高壓力下的穩定性，一旦複雜案例通過，後續的遷移工作便能快速推進，最終使整個生產環境的遷移在短短四週內完成。其次，他們在非生產環境中進行了嚴格的壓力測試，以微調性能相關的配置參數，確保系統能承載極高的容器啟動速率與最大吞吐量。
限制與技術洞察
儘管 Kueue 帶來了顯著的效益，但這次遷移也揭示了雲原生轉型的核心邏輯：在技術快速演進的時代，自研系統的價值在於解決當下沒有方案的問題，而長期的可持續性則在於能否與開源生態對接。Netflix 的案例證明，透過維持 API 兼容性與分階段的租戶遷移，可以將底層基礎設施更換的風險降至最低。
對於其他面臨類似抉擇的企業而言，關鍵在於評估自研功能的獨特性。如果自研功能的價值已被開源社群的標準化實作覆蓋，那麼將精力轉向如何優化開源工具的配置與整合，將比死守私有代碼庫更能提升工程效率。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。