聚焦 SIG Architecture：生產就緒性

這是 SIG Architecture Spotlight 系列的第二次採訪，該系列將涵蓋不同的子專案。在本部落格中，我們將介紹 SIG Architecture：生產就緒性子專案.

在本次 SIG Architecture 聚焦中，我們與生產就緒性子專案的負責人 Wojciech Tyczynski (Google) 進行了交談。

關於 SIG Architecture 和生產就緒性子專案

Frederico (FSM): 你好 Wojciech，能給我們介紹一下你自己、你的角色以及你是如何參與到 Kubernetes 中來的嗎？

Wojciech Tyczynski (WT): 我從 2015 年 1 月開始為 Kubernetes 做貢獻。當時，我所在的公司 Google 決定在華沙辦公室成立一個 Kubernetes 團隊（當時已在加利福尼亞和西雅圖設有團隊）。我很幸運能成為該團隊的創始工程師之一。

經過兩個月的入職培訓並協助專案各方面的不同任務以迎接 1.0 版本的釋出後，我負責了可擴充套件性領域的工作，並帶領 Kubernetes 團隊支援擁有 5000 個節點的叢集。我目前仍然作為技術負責人參與 SIG Scalability。那是一段旅程的開始，因為可擴充套件性是一個貫穿多個領域的議題，我開始為許多其他領域做出貢獻，隨著時間的推移，也包括了 SIG Architecture。

FSM: 在 SIG Architecture 中，為什麼特別選擇生產就緒性子專案？這是你從一開始就有的想法，還是你最初參與可擴充套件性工作時的一個意外結果？

WT: 在實現 Kubernetes 支援 5000 節點叢集 這個里程碑之後，我們的目標之一是確保 Kubernetes 的可擴充套件性特性不會隨著時間的推移而退化。雖然不可擴充套件的實現總是可以修復的，但設計不可擴充套件的 API 或契約則是有問題的。我一直在尋找一種方法，以確保人們在建立新特性和功能時能考慮到可擴充套件性，同時又不會引入過多的開銷。

就在那時，我與 John Belamaric 和 David Eads 聯手，在 SIG Architecture 內部建立了生產就緒性子專案。雖然為可擴充套件性設定標準只是其眾多動機之一，但它最終非常契合。與此同時，我已經在內部參與了系統的整體可靠性工作，所以生產就緒性的其他目標也正合我意。

FSM: 對於任何不熟悉 SIG Architecture 運作方式的人，你會如何描述生產就緒性子專案的主要目標和介入領域？

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 給他們增加了一些額外的工作，但我們看到人們關心它，更令人鼓舞的是，每個版本的答案質量都在提高，“我真的需要一個反映我的功能是否工作的指標嗎”或“降級真的那麼重要嗎”這樣的問題幾乎不再出現了。

• ←上一篇
• 下一篇→