Kubernetes v1.35 終於 release 了，不過你有想過大型專案 Kubernetes 每一個版本背後，都有人在盯著「訊號」是否開始失真嗎？ Release Signal 在做什麼？每天到底在看什麼？
這篇文章記錄我從 Shadow 走進 Kubernetes Release Team，成為 sub-team lead 的心路歷程，實際參與版本節奏、code freeze、RC 前後的真實日常。
為何會加入 Release Team？#
當初是在 Kubernetes 社群和 LinkedIn 裡面閒逛，偶然就滑到別人在貼 Kubernetes Release Team 徵 shadow，有看到 v1.30 的訊息，但個人評估是沒有時間就先 skip 掉，直到 v1.31 嘗試申請。
台灣社群身邊的人似乎也沒人聽過 Release Team，FB 沒人分享這類型訊息，也是我額外的學習機會。另外，這會跟隨最新版本的釋出，會比別人先知道許多訊息，儘管內容 (e.g. KEP 等) 是公開的，但不是每個人都會去翻找。
仔細閱讀 handbook 後，就可以準備一下申請內容送出了。我自己因為是 SRE 職位的關係，看起來跟 CI 有關的就是 Release Signal，我也想藉機會學習 Kubernetes 的測試是如何進行，即使身處小公司，依然可以對外尋求資源，幫助自己拓展視野。
申請之後，就等待吧！我個人不偏好去跟 Lead 做「刷存在感」這類事，shadow 的決定還有很多因素影響，關於這點我放到後面段落解釋。
當時，很幸運被選中成為 Kubernetes v1.32 Release Signal 的 shadow，於是就開始協助這幾次版本發佈。
Release Team 在做什麼？#
Release Team 主要是負責新版的發佈工作，目前有四個組別在招募 shadow，基本上不用先備知識，分別是：
- Enhancements
- Release Signal
- Documentation
- Communications
Release Lead 也有徵 shadow，不過需要先當過上述任一組的 lead 才有資格申請。Branch Management (BM) 是由 SIG Release 管理，基本上要參與過 Release Team 才能成為 BM shadow。
Enhancements 負責整理新版 Kubernetes 的改善功能，同時也是 SIG Architecture 的子專案 Enhancement 聯絡人，需要維護 kubernetes/enhancements 專案和協助 KEP owner 和 SIG lead 之間溝通。後續要協助 Communications 組起稿和審閱 blog 文章。
Release Signal 主要觀察 SIG Release 的新版 dashboard，開發期間的 PR 只會執行較短時間的測試，需要長時間的 E2E 測試就會放到背景中定期啟動。如果有發現 failing test 和 flaking test，就要回報並提醒對應的 SIG 組別。定期跟 BM 回報是否能發版。同時負責追蹤 bug triage。
Documentation 處理新版的 Kubernetes 文件，相關內容都會在 kubernetes/website 的 dev-v1.y 分支中，定期與 SIG Docs 日常會議，負責 Release Note 的整理工作。
Communications 主要是對外的公關，前期雖然工作內容較少，但後期需要寫許多 Kubernetes blog 的文章，包含中期的 Deprecations and Removals、Release blog、該版本的功能 blog 後續發佈。代表 Release Team 跟 CNCF 安排新聞發佈和舉辦網路研討會。
Release Signal 的日常工作#
以下是我在 Release Signal 的工作內容需要做的事情：
- 監控
master-blocking和master-informing儀表板 - 尋找 Failing Test 和 Flaking Test
- 給 Branch Management 切版訊號 Go / No-Go
- Bug Triage
- 回報 Release Team 同步會議更新
1. 監控 master-blocking 和 master-informing 儀表板#
使用 TestGrid 去看 Kubernetes 的 CI 狀況，不過 TestGrid 不會只有 Kubernetes 的測試，還有其他 SIG 子專案和 CNCF Project (e.g. Istio、Cert Manager 等)。
我們是 SIG Release 的 Release Team，主要關心就會是 SIG Release 的儀表板，點進去後會有其他的子儀表板，分別有 master-blocking 和 master-informing 還有各版本的 blocking 和 informing，以及其他 Release Engineering 的儀表板。
Release Team 主要負責新版本的發佈，所以只需要關心 master-blocking 和 master-informing 的儀表板即可。
RC 切版後，會多出 release-1.y 分支，同時也會多出 1.y-blocking 和 1.y-informing 的儀表板，到正式版本發佈以前需要額外監控這兩個儀表板。
Blocking 和 Informing 差異主要是緊急和重要程度，放在 Blocking 的 job 通常都很緊急、重要，出現錯誤要跟 SIG 確認是否會阻礙發佈或修正，其他 job 很重要但不需要緊急處理（或測試頻率較低）就會放到 Informing。
如果想了解詳細內容，可以去看 Release Blocking 的判斷標準，雖然不是 Release Signal 先備知識，但可以理解前因後果。
2. 尋找 Failing Test 和 Flaking Test#
我們需要尋找兩個性質的錯誤：持續性錯誤 (Failing Test) 和偶發性錯誤 (Flaking Test)。
Failing Test 只要看有持續發生錯誤的測試，那就沒錯了。
Flaking Test 比較不好抓，但這會有很多原因，可能會是 infra issue 或潛在 race condition。
這時候就需要透過 Triage Tool 交叉比對，看看其他 job 的測試是不是有類似原因。
確認錯誤後，根據 SIG Owner 和 Test Owner 通知相關人員，mention 出 SIG Lead 來判斷。
不過，回報流程很複雜，Release Signal 會先檢查是否已有對應的 issue；若尚未存在，便會建立新的 issue 以利後續追蹤與協作。
issue 內容通常會描述異常發生的 dashboard、對應的測試項目、首次出現的時間點，以及實際觀察到的錯誤訊息，並在可能的情況下補充初步的背景或推測原因，讓後續接手 triage 的人能快速理解問題脈絡。實際撰寫方式可參考像是 kubernetes/kubernetes#132397 這類範例。
當確認 CI 訊號需要進一步關注時，Release Signal 會先將狀況回報至 #release-ci-signal。這個頻道作為 Release Team 集中追蹤訊號的入口，訊息通常會包含錯誤類型、具體錯誤訊息、相關的 Prow job，以及目前已知的 triage 狀態，確保其他 SIG 成員能快速掌握背景。
由於並非所有 SIG 成員都會即時關注 #release-ci-signal，在確認影響範圍後，Release Signal 也需要將相同訊息轉發至對應的 SIG Slack 頻道，並標記 SIG Lead 或相關 maintainer。以上述 issue 為例，錯誤與 node 行為相關，因此會同步回報至 #sig-node，確保負責該領域的 SIG 成員能及早介入處理。
這也是 Release Signal 工作最重的一環，因為回報流程非常繁瑣。這次 release 中我們透過 SignalHound 來簡化這個流程，關於這個工具的由來，後面會再提到。
3. 給 Branch Management 切版訊號 Go / No-Go#
追蹤這些 Failing Test 和 Flaking Test 後，就要詢問 SIG 或相關成員這會不會是發佈阻礙 (release blocker)。
這個 cycle 期間會有數次的切版，包含 alpha、beta、rc 等，每次要切版的前 3 天，就要傳訊息到 #release-management 確認能不能切版。基本上需要等對應的 SIG 成員或 lead 出來回覆是否為 release blocker。
4. Bug Triage#
以前有 Bug Triage 組，但現在已經跟 CI Signal 合併成為 Release Signal。
大約在程式碼凍結 (Code Freeze) 和測試凍結 (Test Freeze) 前 4~5 週，預計要在這次 release 解決的 Issue 或 PR 都會打上 milestone。需要跟該 Issue 相關人員和 PR 作者提醒「我們會在 X 月 X 日 code freeze，請把握時間把相關 PR 打上 /lgtm 和 /approve，如果有需要其他協助請跟我們聯繫。」
這期間，也會有其他新的 issue 和 PR 加入 milestone，這部分就要由 Release Signal Lead 去定期確認，確保每個 milestone 的 issue 和 PR 都有被 shadow 追蹤。
然後 Code Freeze 前 3 ~ 4 天要再傳一次訊息提醒那些有該版本的 milestone 還沒關閉的 Issue 和尚未處理的 PR（不包含已經有 /lgtm 或 /approve），說「已經剩下 X 天就要 code freeze，如果需要延後請發送 Exception 請求」
Exception 請求會傳到 Release Lead 團隊，同時該請求的 SIG Lead 也要附議，Release Lead 團隊會評估時程、進度等，給予 APPROVING 或 REJECTING。
這時候就有個問題會出現：
如果今天有很重要錯誤要修正，還會需要附上 Exception 請求嗎？
不用，程式碼凍結後，PR 除了原本 /lgtm 和 /approve 標籤外，另外需要 milestone 才能合併，這部分 Release Lead 和其他的 sub-team lead 都有加 milestone 權限（或其他 SIG Lead，不過通常會尊重 Release Team 決定）。
我通常還是會看一下 PR 確定是功能修正或測試修復，沒問題就會打上標籤。
5. 回報 Release Team 同步會議更新#
每週三會有 Release Team 會議，分為 APAC 時區和 EMEA 時區，以台灣時間來說，APAC 時區會在下午，EMEA 時區會在半夜。
因為涉及到跨時區的關係，所以一定要使用行事曆訂閱，以免錯過會議更新。
大約到第 10 週後，加開 Burndown meeting，分別是星期一和星期五，一樣會有 APAC 時區和 EMEA 時區。最後幾週會有 Slack 非同步更新，全部就在 Slack Channel 回覆。
這樣看下來，工作內容確實很多，但不會是只有自己一個人，別忘記還有其他國家、時區的工作夥伴，所以不需要擔心工作會做不完。
從 shadow 成為 sub-team lead 的轉變#
在 1.34 release 接近尾聲時，我開始以「下一版 Release Signal Lead」的角色參與交接，也因此第一次從 sub-team lead 的視角，完整理解 shadow 選擇所涉及的流程。
開始選擇 shadow#
每一個 release cycle，每一組的 sub-team 都會收到大量的 shadow 申請。各 sub-team lead 會依照工作型態與需求，提出對應的 shadow 名單。
名單彙整後，會由 Release Lead 與 Subproject Owner 進行審閱，確保每位 shadow 在同一個 release 週期中只隸屬於一個 sub-team，並同時考量時區分布與實際值班需求。由於 Release Team 的同步會議會有 APAC 與 EMEA 時區，加上 Release Signal 的工作本質需要持續關注 dashboard 與狀態變化，這些條件都會影響最終的成員配置結果。
確認沒問題後就會由 sub-team lead 發出 Slack 私訊通知，並且準備簡報介紹這組工作內容等，後續協助 shadow onboarding 的流程。
選定成員後，我讓有經驗的 shadow 去帶領新進的 shadow，有經驗的 shadow 可以獲得教學經驗，未來更容易接手 sub-team lead 的工作。
與 SIG Release 討論專案捐贈#
前面提到回報 CI 訊號的流程非常繁瑣，v1.35 的 shadow Amim 在這個 cycle 開發了 SignalHound 來簡化這個流程。當工具逐漸成熟後，我跟 Release Lead 討論將它捐贈到 kubernetes-sigs 組織的可能性，也跟 SIG Release 的 Lead 溝通，最終讓它從個人的 PoC 變成社群共同維護的子專案。
Amim 有能力寫出工具，但要讓工具進入社群，需要有人在流程面協助推進，而這正是 lead 該做的事。
讓 shadow 站上舞台#
另一個我刻意安排的事情是，讓 shadow 輪流在 Release Team 週會上報告 CI signal update。以前這件事通常由 lead 自己做，但我希望每位 shadow 都有機會練習對外溝通、面對其他 sub-team lead 和 Release Lead 回答問題。
實際做法是依照時區排班，每人負責一到兩週的會議報告，有經驗的 shadow 先上，新進的 shadow 觀摩幾次後再嘗試接手。報告前我會先跟他們檢查內容，確保資訊正確，但不會幫他們講。
不管是讓資深 shadow 帶人、推動工具捐贈、還是安排輪流報告，目的都一樣：sub-team lead 的工作不是自己把事情做完，而是讓每一位成員都有成長的機會。
交接給下一位 sub-team lead#
Release 接近尾聲的幾週前，sub-team lead 會開始與 shadow 討論下一個 release cycle 的參與方向。常見的選項包含：
- 繼續留在原本的 sub-team
- 承接該組的 lead 角色
- 參與其他的 sub-team shadow
- 加入其他的 SIG 貢獻
整理每個 shadow 回饋後，與 Release Lead 和 Subproject Owner 討論後，提名出下一版合適的 sub-team lead 人選，並完成交接。
推薦誰來當 Release Shadow#
Shadow Program 其實就是給新人參與機會，我認為每個想要嘗試貢獻 Kubernetes 但不知道該如何下手，就可以從這裡開始，尤其是學生。
不過學生就需要注意時間 commitment，就 Release Signal 來說，可以事先填寫各自有薪假 (PTO) 或低活躍度的時間，給 sub-team lead 安排協調。
以我來說，小公司能學習的內容很有限，程式架構或測試不一定會像 Kubernetes 很複雜，從這些回報 E2E 錯誤和參與過程中，觀摩大型專案如何維護。
未來面對有新的工作機會，就算實務上沒有經驗，但還是可以根據在 Kubernetes 社群貢獻的觀察，有條理的描述現象和規劃，面試過程中絕對是有加分效益。
後記#
最後非常感謝 v1.35 跟我一起奮鬥的 Release Signal 成員（依照英文名字典序排列）：Amim Knabben、Ben Petersen、Keisuke Ishigami、Muhammad Adil Ghaffar、Prajyot Parab、Yun Chi Shih。
這些內容還只是介紹 Release Team，裡面還有其他有趣的故事呢！
希望這篇貼文以後，能讓大家了解大型專案的 Release Team 在做什麼，也期待未來台灣人能多參與國際開源技術社群。