引言
隨著雲原生技術的快速發展，Kubernetes與CNCF（Cloud Native Computing Foundation）成為現代軟體架構的核心基礎。然而，隨著專案規模的擴張，如何建立系統化的設計提案流程，以提升協作效率與透明度，成為關鍵議題。本文探討Kubernetes的增強提案流程（KEP）與Cube專案的演進實踐，分析其結構、挑戰與改進方向，為技術團隊提供可參考的流程設計框架。
Kubernetes增強提案流程（KEP）
技術定義與核心概念
KEP（Kubernetes Enhancement Proposal）是Kubernetes社群為標準化功能設計與實現所建立的流程機制。其核心目標在於確保提案的透明度、可追蹤性與社區參與，並透過結構化流程降低協作成本。
關鍵特性與功能
- KEP模板：明確提案需包含的內容與階段（Alpha/Beta/Stable），涵蓋動機、設計細節、測試計劃與風險評估。
- 元數據文件（YAML）：記錄提案參與者（Driver、Approver、Contributor、Informed）與項目管理視圖（DC模型），支持外部工具整合。
- PR審查流程：由獨立團隊進行生產就緒性審查，確保提案不會影響現有系統，審查結果存儲於GitHub並標註階段狀態。
與發布週期的整合
- 發布週期：每15-16週為一輪，分為討論、設計、實現、測試等階段。
- Enhancement Freeze：鎖定提案範圍，禁止修改相關文件。
- Code & Test Freeze：確保所有實現PR在截止日前完成審核與合併。
- 例外處理：未達標提案可申請延長時間，但需重新評估。
面臨的挑戰與改進
- 文檔負擔：部分貢獻者忽略更新提案文件，導致資訊過時。
- 流程靈活性：SIG可根據需求調整提案門檻，初期建議從小範圍開始。
- 工具整合：利用YAML元數據支持看板與儀錶板追蹤項目狀態。
- 持續演進：流程需隨著專案成長調整，強調社區溝通與責任分工。
Cube增強提案流程的演進
初期階段與問題
Cube專案於2016年成立，初期缺乏正式流程，僅透過PR與簡短文檔實現功能（如虛擬機器遷移）。貢獻者少（約3-5人），快速迭代但缺乏結構化流程，導致提案與其他討論混雜，透明度不足。
改進與現狀
- 設計目錄：分離提案與其他內容，提升可讀性。
- 追蹤機制：透過Git日誌追蹤貢獻者與功能狀態，但缺乏討論紀錄。
- 功能門檻：未明確界定提案範疇，導致部分功能（如虛擬機器偏好）未被記錄。
- 功能閥值：未明確定義功能閥值（如預設開關、移除時機），影響長期維護。
未來方向
- 流程標準化：參考KEP結構，建立更完整的提案模板。
- 社區參與：強化設計會議與社區協作，提升提案透明度與一致性。
- 工具整合：利用GitHub功能（如標籤、項目板）追蹤提案進度與狀態。
設計提案流程的擴展與優化
原有流程問題
- 模板簡化：初期僅使用簡化模板，未明確流程規則。
- 缺乏追蹤機制：提案與其他議題（如人力配置、權限調整）混雜，無明確流程管理。
- 透明度不足：無明確提案評估與進度追蹤，無法掌握誰在推動什麼功能。
- 個人關係依賴：功能進展依賴個人關係，缺乏制度化協作，影響包容性與新 Contributor 參與。
- 功能管理混亂：如Hot Plug功能因缺乏協調，導致儲存層與計算層實現方式不一致。
新流程設計
- 參考KEP結構：採用Kubernetes Enhancement Process，但簡化模板（約為原版一半）。
- 專屬倉庫：建立
cubert-enhancements倉庫，作為提案集中管理平臺。
- GitHub Issue模板：
- 功能目標：明確提案目的與非目標。
- 聯絡人指定：指定主要聯絡人（Primary Contact）與Cubert端負責人（Maintainer）。
- 成熟度狀態：標註功能當前階段（如草案、Alpha、Beta）。
- SIG路由機制：
- 提案自動路由至相關SIG（如Network、Storage）。
- SIG負責指定功能所有者（Owner）與評估可行性。
- 流程階段：
- 初始評估：由核心Maintainer進行初步審查（2-3人）。
- 所有權轉移：通過評估後，功能所有權移交至SIG。
- 生命週期管理：由SIG主導功能開發與整合。
發布週期與整合
- 與Kubernetes同步：遵循Kubernetes發布週期，每季3次釋出（原為4次，現延後2個月以利穩定測試）。
- 功能整合門檻：
- 功能需在釋出前完成整合測試，並修復阻礙Bug。
- 特別重要功能可申請延後釋出（如需90%完成度），經討論後決定是否調整週期。
- 回溯與測試：
- 社區成員可回溯功能至下游分支。
- 提供夜間構建（Nightly Builds）供測試。
未來建議
- 逐步擴展流程：
- 從輕量流程開始（如GitHub Issue），吸引Contributor參與。
- 漸進式增加流程複雜度，避免過早引入過多規則。
- 平衡流程與靈活性：
- 避免過度流程化（如OpenStack的經驗），保持開發效率。
- 以「時間驅動」釋出週期為主，偶爾因重要功能調整週期。
- 社區協作：
- 透過SIG降低個人關係依賴，提升包容性。
- 透過明確的流程與追蹤機制，確保功能進展可預測。
總結
設計提案流程的關鍵在於平衡結構化與靈活性，並透過社區協作提升透明度。Kubernetes的KEP流程提供了成熟的框架，而Cube專案的演進則展現了從簡化到標準化的實踐過程。未來，技術團隊可參考這些經驗，根據專案需求逐步建立適合的流程，並持續優化以應對成長挑戰。