本文已發布超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG 架構：生產就緒狀態
這是 SIG 架構焦點系列訪談的第二篇，該系列將涵蓋不同的子專案。在本部落格中，我們將介紹 SIG 架構：生產就緒子專案.
在本次 SIG 架構焦點訪談中，我們與生產就緒子專案的負責人 Wojciech Tyczynski (Google) 進行了交談。
關於 SIG 架構和生產就緒子專案
Frederico (FSM)：您好 Wojciech，您能否向我們介紹一下您自己、您的角色以及您是如何參與 Kubernetes 的？
Wojciech Tyczynski (WT)：我於 2015 年 1 月開始為 Kubernetes 做出貢獻。當時，Google（我當時和現在仍然在職的公司）決定在華沙辦公室（除了加州和西雅圖的現有團隊之外）成立一個 Kubernetes 團隊。我很幸運成為該團隊的種子工程師之一。
在為期兩個月的入職培訓和協助專案中針對 1.0 版本發布的不同任務之後，我負責了可擴展性領域，並領導 Kubernetes 支援具有 5000 個節點的叢集。我仍然以技術負責人的身份參與 SIG 可擴展性。這是一個旅程的開始，因為可擴展性是一個跨領域的主題，我開始為許多其他領域做出貢獻，包括隨著時間的推移，為 SIG 架構做出貢獻。
FSM：在 SIG 架構中，為什麼特別是生產就緒子專案？這是您一開始就想到的事情，還是您最初參與可擴展性的意外結果？
WT：在達到 Kubernetes 支援 5000 個節點叢集 這個里程碑之後，目標之一是確保 Kubernetes 的可擴展性屬性不會隨著時間而降低。雖然不可擴展的實作始終可以修復，但設計不可擴展的 API 或合約卻很有問題。我一直在尋找一種方法來確保人們在創建新功能和能力時考慮到可擴展性，而不會引入過多的開銷。
這時我與 John Belamaric 和 David Eads 聯手，在 SIG 架構內創建了一個生產就緒子專案。雖然設定可擴展性的標準只是其少數動機之一，但最終它非常契合。同時，我已經在內部參與了系統的整體可靠性，因此生產就緒的其他目標也與我的初衷非常接近。
FSM：對於剛接觸 SIG 架構工作原理的人來說，您將如何描述生產就緒子專案的主要目標和介入領域？
WT：生產就緒子專案的目標是確保添加到 Kubernetes 的任何功能都可以在生產叢集中可靠地使用。這主要意味著這些功能是可觀察的、可擴展的、可支援的，始終可以安全地啟用，並且在發生生產問題時也可以停用。
生產就緒和 Kubernetes 專案
FSM：架構一致性是 SIG 的目標之一，Kubernetes 的分散式和開放性 是否使這一目標更具挑戰性？您是否認為這會影響生產就緒必須採用的方法？
WT：Kubernetes 的分散式特性當然會影響生產就緒，因為它使考慮啟用/停用或可擴展性等面向更具挑戰性。更準確地說，當啟用或停用跨越多個組件的功能時，您需要考慮它們之間的版本偏差並為其進行設計。對於可擴展性，一個組件中的變更實際上可能會導致完全不同的組件出現問題，因此這需要對整個系統（而不僅僅是個別組件）有良好的理解。但這也是使這個專案如此有趣的原因。
FSM：那些在生產環境中運行 Kubernetes 的人將有自己的觀點，您如何收集這些回饋？
WT：幸運的是，我們在這裡不是在談論“他們”，而是在談論“我們”：我們所有人都在為管理大量 Kubernetes 叢集的公司工作，我們也參與其中，因此我們自己也遭受這些問題的困擾。
因此，雖然我們正在努力獲取回饋（我們的年度 PRR 調查對我們非常重要），但它很少揭示全新的問題 - 它更多地顯示了問題的規模。我們嘗試對此做出反應 - 像“預設關閉 Beta API”這樣的變更就是對我們觀察到的數據做出反應。
FSM：關於反應這個話題，這讓我想到了 Kubernetes 增強提案 (KEP) 範本有一個生產就緒審查 (PRR) 部分，它與畢業流程相關聯。這是從已識別的不足之處中誕生的嗎？您將如何描述結果？
WT：如上所述，生產就緒子專案的總體目標是確保每個新增加的功能都可以在生產環境中可靠地使用。僅靠一個中央團隊來強制執行這一點是不可能的 - 我們需要讓它成為每個人的問題。
為了實現這一目標，我們希望確保每個設計新功能的人從一開始就考慮到安全啟用、可擴展性、可觀察性、可支援性等。這意味著不是在實作開始時，而是在設計期間。鑑於 KEP 實際上是 Kubernetes 設計文件，因此將其納入 KEP 範本是實現目標的方法。
FSM：所以，在某種程度上，確保功能所有者已考慮到其提案的影響。
WT：完全正確。我們已經觀察到，僅僅透過強迫功能所有者仔細考慮 PRR 方面（透過強迫他們填寫 PRR 問卷調查），許多原始問題正在消失。當然 - 作為 PRR 批准者，我們仍然在發現差距，但即使是 KEP 的初始版本，在考慮生產化方面也比幾年前要好得多，這正是我們想要實現的目標 - 傳播在最廣泛意義上思考可靠性的文化。
FSM：我們一直在談論 PRR 流程，您能否為我們的讀者描述一下？
WT：PRR 流程 非常簡單 - 我們只是想確保您儘早仔細考慮您的功能的生產化方面。如果您完成了您的工作，那麼只需回答 KEP 範本中的一些問題，並獲得 PRR 批准者（除了常規 SIG 批准之外）的批准即可。如果您之前沒有考慮過這些方面，則可能需要花費更多時間並可能修改一些決策，但這正是我們需要使 Kubernetes 專案可靠的原因。
協助生產就緒
FSM：生產就緒似乎是一個需要大量事先接觸才能成為有效貢獻者的領域。對於專案新手來說，還有其他貢獻方式嗎？
WT：PRR 批准者必須對整個 Kubernetes 專案有深入的了解才能發現潛在問題。Kubernetes 現在是一個如此龐大的專案，有如此多的細微差別，以至於剛接觸該專案的人可能會忽略上下文，無論他們有多資深。
也就是說，您有很多種可以隱含地提供幫助的方式。透過提高專案特定領域的可觀察性和可調試性、增加測試覆蓋率以及構建新型測試（升級、降級、混沌等）來提高其可靠性，這將對我們有很大幫助。請注意，PRR 子專案專注於將標準保持在設計層面，但我們也應該同樣關心實作。為此，我們依賴個別 SIG 和程式碼批准者，因此讓了解生產化方面並且非常關心它的人員在那裡將對專案有很大幫助。
FSM：謝謝！您還有什麼最後的評論想與我們的讀者分享嗎？
WT：我想強調並感謝所有貢獻者的合作。雖然 PRR 為他們增加了一些額外的工作，但我們看到人們關心它，更令人鼓舞的是，每個版本的答案品質都在提高，並且“我真的需要一個反映我的功能是否有效的指標”或“降級真的那麼重要嗎”這樣的問題不再出現了。