聚焦 SIG Architecture：增強功能
這是 SIG Architecture 聚焦系列第四次訪談，將介紹不同的子專案，本次我們將介紹 SIG Architecture：Enhancements。
在這次 SIG Architecture 聚焦中，我們與 Enhancements 子專案的負責人 Kirsten Garrison 進行了交談。
Enhancements 子專案
Frederico (FSM)：你好，Kirsten，很高興有機會談論 Enhancements 子專案。我們先來簡單瞭解一下你自己和你的角色吧。
Kirsten Garrison (KG)：我是 SIG-Architecture 下屬的 Enhancements 子專案的負責人，目前在 Google 工作。我最初是在 Carolyn Van Slyck 的幫助下開始為 service-catalog 專案做貢獻的。後來，我加入了釋出團隊，最終成為 Enhancements 負責人和一名釋出負責人實習成員。在釋出團隊期間，我根據我們團隊的經驗，提出了一些改進 SIG 和 Enhancements 團隊流程的想法（即選擇性加入流程）。最終，我開始參加子專案的會議，併為子專案的工作做出貢獻。
FSM：你提到了 Enhancements 子專案：你會如何描述它的主要目標和工作範圍？
KG：Enhancements 子專案主要關注Kubernetes 增強提案（簡稱 KEP）—— 這是所有特性和對 Kubernetes 專案的重大變更所必需的“設計”文件。
KEP 及其影響
FSM：KEP 流程的改進是（並且現在也是）SIG Architecture 重點參與的一個方面。你能為那些不瞭解它的人解釋一下這個流程嗎？
KG：每個釋出版本，SIG 都會告知釋出團隊他們打算在該版本中開發哪些特性。如上所述，這些變更的前提是需要一個 KEP —— 一個標準化的設計文件，所有作者都必須在釋出週期的前幾周填寫並獲得批准。大多數特性都會經歷 3 個階段：alpha、beta，最後是 GA，因此批准一個特性意味著 SIG 作出了一項重大承諾。
KEP 是一個特性的完整事實來源。KEP KEP 模板根據特性所處的階段有不同的要求，但通常要求詳細討論設計和影響，並提供穩定性和效能方面的製品。KEP 需要作者、SIG 評審員、API 評審團隊和生產就緒性評審團隊1之間進行大量的迭代工作才能獲得批准。每組評審員都會確保提案符合他們的標準，以保證 Kubernetes 版本的穩定性和高效能。只有在獲得所有批准後，作者才能繼續將他們的特性合併到 Kubernetes 程式碼庫中。
FSM：我明白了，確實增加了很多額外的結構。回顧過去，這種方法最顯著的改進是什麼？
KG：總的來說，我認為影響最大的改進是專注於 KEP 的核心意圖。KEP 的存在不僅僅是為了記錄設計，更是為了提供一種結構化的方式來討論和就變更的不同方面達成一致。KEP 流程的核心是溝通和周全的考慮。
為此，一些重大的變化圍繞著一個更詳細、更易於訪問的 KEP 模板。隨著時間的推移，我們投入了大量工作才將 k/enhancements 倉庫發展成現在的形式 —— 一個按 SIG 組織的目錄結構，具有現代 KEP 模板的輪廓（包含提案/動機/設計細節等子部分）。我們今天可能認為這個基本結構是理所當然的，但它確實代表了許多人長期以來為建立這個流程基礎所做的努力。
隨著 Kubernetes 的成熟，我們需要考慮的不僅僅是合併單個特性的最終目標。我們需要考慮諸如穩定性、效能、設定和滿足使用者期望等問題。隨著我們對這些問題的思考，模板也變得更加詳細。生產就緒性評審的引入以及增強的測試要求（在 KEP 的生命週期的不同階段有所不同）也是重大的改變。
當前的重點領域
FSM：說到成熟，我們最近釋出了 Kubernetes v1.31，v1.32 的工作也已經開始。Enhancements 子專案目前是否正在處理任何可能改變現有工作方式的領域？
KG：我們目前正在做兩件事：
- 建立一個流程 KEP 模板。 有時人們希望利用 KEP 流程來進行更偏向於流程而非特性的重大變更。我們希望支援這一點，因為記錄變更是非常重要的，為人們提供更好的工具來做到這一點，只會鼓勵更多的討論和透明度。
- KEP 版本控制。 儘管我們對模板的更改旨在儘可能減少干擾，但我們相信，透過一個帶版本號的 KEP 模板以及與之配套的策略，可以更輕鬆地跟蹤這些更改，並更好地與社群溝通。
這兩項特性都需要一些時間才能正確完成並全面推出（就像一個 KEP 特性一樣），但我們相信它們都將帶來改進，使整個社群受益。
FSM：你提到了改進：我記得在最近的釋出版本中引入了用於增強跟蹤的專案看板，效果非常好，得到了釋出團隊成員的一致好評。這是子專案的一個特別關注的領域嗎？
KG：子專案為釋出團隊的 Enhancements 團隊從使用電子表格遷移到專案看板提供了支援。增強功能的收集和跟蹤一直是一個後勤挑戰。在我參與釋出團隊期間，我協助過渡到了一個增強功能的選擇性加入系統，即由 SIG 負責人“選擇加入”KEP 以進行釋出跟蹤。這有助於在對 KEP 進行任何重大工作之前加強作者和 SIG 之間的溝通，並減輕了 Enhancements 團隊的重複性工作。這一變化利用了現有工具，以避免一次性向社群引入太多變化。後來，釋出團隊向子專案提出了一個利用 GitHub 專案看板來進一步改進收集流程的想法。這將是擺脫使用複雜電子表格，轉而使用 k/enhancement 問題和專案看板上的倉庫原生標籤的做法。
FSM：這無疑對簡化工作流程產生了影響……
KG：消除摩擦來源和促進清晰的溝通對 Enhancements 子專案非常重要。同時，對於影響整個社群的決策，進行審慎的考慮也很重要。我們希望確保變更能夠平衡，既帶來好處，又不在推出過程中造成任何迴歸和痛苦。我們支援釋出團隊進行構思，並全程參與了向專案看板的實際遷移。這是一個巨大的成功，看到團隊做出高影響力的改變，幫助了所有參與 KEP 流程的人，這非常令人興奮！
參與進來
FSM：對於那些可能感到好奇並有興趣提供幫助的讀者，你會如何描述參與這個子專案所需的技能？
KG：熟悉 KEPs，無論是透過經驗還是花時間瀏覽 kubernetes/enhancements 倉庫都會很有幫助。歡迎所有感興趣的人參與 —— 我們可以從那裡開始。
FSM：太好了！非常感謝你的時間和見解 —— 你有什麼最後的評論想與我們的讀者分享嗎？
KG：Enhancements 流程是 Kubernetes 最重要的部分之一，需要專案內外的人員和團隊之間大量的協調與合作才能成功。我感謝併為每個人持續的辛勤工作和致力於使專案變得偉大的奉獻精神所鼓舞。這真是一個了不起的社群。
要了解更多資訊，請檢視本系列中的生產就緒性評審聚焦訪談。 ↩︎