引言
在雲端原生架構中，資料規模的管理與應用程序的穩定運行是關鍵挑戰。Kubernetes 作為容器編排平臺，其應用程序組（Application Group, SIG Apps）持續推動核心控制器的演進，以應對大規模資料處理的複雜需求。本文探討 SIG Apps 的職責、已實現的關鍵功能，以及未來技術方向，為開發者提供最佳實踐與技術洞察。
主要內容
SIG Apps 的職責與功能
SIG Apps 是 Kubernetes 社區的核心組別，專注於核心控制器的開發與維護，包括 Deployments、Jobs、StatefulSets 等資源。其主要功能包括：
- 社區協作：開放問題提報與解決方案討論，協助解決資源限制與場景挑戰。
- 年度報告：總結 10 年演進歷程與 API 資源變遷，提供技術趨勢分析。
- 定期會議：每兩週舉辦會議，透過 Slack（#sig-apps）與郵件列表（[email protected]）協作。
已發布穩定功能
1. Pod 中斷預算（PDB）改進
- 計數邏輯修正：僅計算 Ready Pod 作為中斷預算，非 Ready Pod 可被驅逐。
- 後向兼容性：新增字段區分計數方式，確保舊版本應用無需調整。
2. ReplicaSet 隨機化演算法
- 下架機制優化：改進 Pod 選取機制，避免集中淘汰，提升系統穩定性。
- 滾動更新靈活性：支援更靈活的 Pod 替換策略，適應不同負載場景。
3. StatefulSet 進階功能
- 跨集群遷移控制：支援 Pod 編號自定義（如從 3 開始），確保遷移一致性。
- PVC 管理策略：明確指定 Scale Down 或刪除時是否移除 PVC，避免資料遺失。
- 操作分離：將 Scale Down 與刪除配置分離，提供更細粒度控制。
4. 批次工作（Batch）功能
- 彈性索引作業（Elastic Index Jobs）：
- 每個 Pod 有固定索引，失敗時保留索引並重新啟動。
- 支援動態調整 Parallelism 與 Completions，需同步修改。
- 環境變數注入索引資訊，方便應用識別執行位置。
- CronJob 延遲處理：
- 新增 Job 延遲資訊註解，顯示實際執行時間與預期差異。
- 支援延遲後仍執行 Job，避免排程異常導致任務遺失。
- Job 成功與完成策略：
- 允許定義退出條件，提前終止 Job（不需完成所有 Pod）。
- 新增 Backoff Limit 限制重試次數，支援 Job 級與 Pod 級別設定。
- 支援外部控制器管理 Job 狀態，確保一致性。
即將推出功能
1. Job Pod 失敗策略（Job Pod Failure Policy）
- 子語言定義：新增 Job 內部子語言，定義特定 Pod 的重試條件。
- 條件判斷：支援根據 Exit Code 或狀態條件決定是否重試，提升容錯能力。
2. Deployment 滾動更新優化
- 資源敏感度：改進滾動更新邏輯，避免在接近配額限制時過度推進。
- 資源控制：僅在舊 Pod 進入終止階段後才創建新 Pod，降低資源風險。
3. 多集群作業狀態管理
- 狀態鏡像：主集群僅鏡像 Job 狀態，執行邏輯分散至子集群。
- 狀態一致性：確保外部控制器與內建控制器狀態驗證規則一致，維護狀態一致性。
關鍵技術重點
1. 外部控制器狀態驗證
- 目標：確保外部控制器報告的 Job 狀態正確性，並與內建控制器遵循相同規則。
- 實現方式：
- 在 Kubernetes API Server 中明確定義 Job 物件狀態驗證邏輯。
- 強制外部控制器遵循相同狀態規則與限制。
- 場景：多集群環境中，Hub Cluster 僅鏡像 Job 狀態，執行於 SubCluster。
2. Job 失敗策略（Job Failure Policy）
- 功能：允許用戶在 Job 中定義 Pod 重試條件，例如根據 Exit Code 或狀態條件決定是否重試。
- 進展：已開發逾一年，目前處於實現階段。
- 應用場景：當 Pod 因預期錯誤（如 Exit Code 0）或非預期錯誤（如異常終止）需不同處理時，提供靈活策略。
3. 滾動更新優化（Rolling Update）
- 問題：當資源接近配額時，滾動更新可能無法按預期進行。
- 解決方案：要求僅在舊 Pod 進入終止階段後才創建新 Pod，避免資源過度使用。
- 應用場景：資源配額限制下，逐步替換 Pod 以降低風險。
4. 節點自動擴縮（Node Autoscaling）
- 現狀：無內建機制描述節點排水（Drain）過程，如排水時間、強制移除 Pod 條件等。
- 目標：引入外部作用者協助節點排水，並明確定義工作負載遷移邏輯。
- 相關組別：由 SIG Apps 與其他專案組討論，涉及節點資源管理與擴縮策略。
5. StatefulSet 的 Max Available 功能
- 現狀：已存在於 Deployment 與 ReplicaSet，但 StatefulSet 尚未實現。
- 挑戰：難以定義 StatefulSet 滾動更新的可靠指標（如時間預估），因應用啟動時間差異影響整體效能。
- 進展：原主要貢獻者已轉移專案，需尋求新貢獻者推動實現。
技術優勢與挑戰
優勢：
- 社區協作：SIG Apps 的開放協作模式加速功能迭代與問題解決。
- 功能擴展性：核心控制器的持續優化提升 Kubernetes 在大規模資料處理的適應性。
- 狀態一致性：通過狀態驗證與跨集群管理，確保多環境下應用行為一致。
挑戰：
- StatefulSet 的 Max Available 實現：需解決應用啟動時間差異對滾動更新的影響。
- 資源控制精準度：在滾動更新與節點擴縮中，需平衡資源使用與系統穩定性。
總結
SIG Apps 透過持續優化核心控制器，為 Kubernetes 提供更穩定、靈活的應用程序管理能力。從 Pod 中斷預算到多集群狀態管理，其功能設計體現了對大規模資料處理的深度洞察。開發者應善用這些功能，並參與社區協作，共同推動技術進步。未來，Job 失敗策略、滾動更新資源控制與節點排水機制的完善，將進一步提升 Kubernetes 在雲原生環境中的可靠性與擴展性。