本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG Architecture：一致性
這是 SIG Architecture 聚焦系列的首篇訪談，該系列將涵蓋不同的子專案。我們從 SIG Architecture：一致性子專案開始。
在本次 SIG Architecture 聚焦中，我們與 一致性子專案的負責人 Riaan Kleinhans (ii.nz) 進行了交談。
關於 SIG Architecture 和一致性子專案
Frederico (FSM): 你好 Riaan，歡迎！首先，請介紹一下你自己、你的角色以及你是如何參與到 Kubernetes 中的。
Riaan Kleinhans (RK): 嗨！我叫 Riaan Kleinhans，住在南非。我是紐西蘭 ii.nz 團隊的專案經理。當我加入 ii 時，原計劃是 2020 年 4 月搬到紐西蘭，但後來新冠疫情爆發了。幸運的是，我們是一個靈活而充滿活力的團隊，我們成功地在不同的時區進行了遠端工作。
ii 團隊的任務是管理 Kubernetes 一致性測試的技術債務，並編寫測試來清除這些技術債務。我擔任了專案經理的角色，負責監控、測試編寫和社群之間的聯絡。透過這項工作，我有幸在最初的幾個月裡遇到了 Dan Kohn，他對我們工作的熱情給了我很大的啟發。
FSM: 謝謝。所以，你參與 SIG Architecture 是從一致性工作開始的？
RK: SIG Architecture 是 Kubernetes 一致性子專案的歸屬地。最初，我的大部分互動都是透過一致性子專案直接與 SIG Architecture 進行的。然而，隨著我們開始按 SIG 組織工作，我們開始與每個單獨的 SIG 直接接觸。這些與擁有未測試 API 的 SIG 的接觸幫助我們加快了工作進度。
FSM: 你如何描述一致性子專案的主要目標和工作領域？
RM: Kubernetes 一致性子專案透過開發和維護一個全面的一致性測試套件，專注於保證與 Kubernetes 規範的相容性和遵循性。其主要目標包括確保不同 Kubernetes 實現之間的相容性，驗證對 API 規範的遵循情況，透過鼓勵一致性認證來支援生態系統，以及促進 Kubernetes 社群內的協作。透過提供標準化的測試並促進一致的行為和功能，一致性子專案為開發者和使用者確保了一個可靠且相容的 Kubernetes 生態系統。
關於一致性測試套件的更多資訊
FSM: 我相信，提供這些標準化測試的一部分是一致性測試套件。你能解釋一下它是什麼以及它的重要性嗎？
RK: Kubernetes 一致性測試套件檢查 Kubernetes 發行版是否符合專案的規範，確保不同實現之間的相容性。它涵蓋了 API、網路、儲存、排程和安全等各種功能。透過測試可以確認其實現是正確的，並促進了一個一致且可移植的容器編排平臺。
FSM: 是的，這些測試之所以重要，是因為它們定義了任何 Kubernetes 叢集必須支援的最低功能。你能描述一下決定哪些功能被考慮納入的過程嗎？在更精簡的方法和來自其他 SIG 的提案之間是否存在任何張力？
RK: SIG Architecture 明確定義了每個進行一致性測試的端點的要求。只有正式釋出（GA）且非可選的功能才有資格進行一致性測試。多年來，關於一致性配置（conformance profiles）有過多次討論，探討了將像 RBAC 這樣被大多數終端使用者廣泛使用的可選端點納入特定配置的可能性。然而，這方面的工作仍在進行中。
不符合一致性標準的端點列在 ineligible_endpoints.yaml 檔案中，該檔案在 Kubernetes 倉庫中是公開的。這個檔案可以根據端點的狀態或要求的變化來更新，以新增或刪除端點。這些不合格的端點也可以在 APISnoop 上看到。
確保透明度並採納社群關於端點合格或不合格的意見，對 SIG Architecture 至關重要。
FSM: 為新功能編寫測試通常需要某種強制執行。你如何看待 Kubernetes 在這方面的發展？是否有過專門的努力來改進流程，使必要的測試成為一等公民，或者這從來都不是問題？
RK: 當 2018 年開始討論 Kubernetes 一致性計劃時，只有大約 11% 的端點被測試覆蓋。當時，CNCF 的理事會要求，如果要為覆蓋缺失的一致性測試的工作提供資金，Kubernetes 社群應該採取一項政策，即不允許新增新功能，除非它們為其穩定 API 包含了一致性測試。
SIG Architecture 負責管理這一要求，而 APISnoop 在這方面被證明是一個非常寶貴的工具。透過自動化，APISnoop 每週末都會生成一個拉取請求，以突出一致性覆蓋範圍中的任何差異。如果有任何端點在沒有一致性測試的情況下被提升到正式可用（General Availability），它會立即被識別出來。這種方法有助於防止新的技術債務的累積。
此外，近期還計劃建立一個釋出通知作業，這將增加一個額外的層級來防止任何新的技術債務。
FSM: 我明白了，工具和自動化在這裡扮演了重要角色。在你看來，從一致性的角度來看，哪些領域仍然需要一些工作？換句話說，當前標記為需要改進的優先領域是什麼？
RK: 我們在 1.27 版本中已經達到了“100% 一致性測試”的里程碑！
那時，社群重新審視了所有被列為不符合一致性測試資格的端點。這個列表是多年來透過社群的意見彙集而成的。一些以前被認為不符合一致性測試資格的端點已被識別出來，並被移到一個新的專用列表中，該列表目前正受到一致性測試開發的重點關注。同樣，該列表也可以在 apisnoop.cncf.io 上檢視。
為確保在一致性專案中避免新的技術債務，未來計劃建立一個釋出通知作業作為額外的預防措施。
雖然 APISnoop 目前託管在 CNCF 基礎設施上，但該專案已被慷慨地捐贈給了 Kubernetes 社群。因此，它將在 2023 年底前轉移到社群擁有的基礎設施上。
FSM: 這是個好訊息！對於任何想要提供幫助的人，你會重點推薦哪些協作渠道？所有這些都需要對 Kubernetes 整體有深入的瞭解，還是有辦法讓專案的新手也能做出貢獻？
RK: 為一致性測試做貢獻就像“洗碗”一樣——可能不太引人注目，但卻非常重要。這需要對 Kubernetes 有深刻的理解，特別是在需要測試端點的領域。這就是為什麼與擁有被測試 API 端點的每個 SIG 合作如此重要的原因。
作為我們讓測試編寫對所有人開放的承諾的一部分，ii 團隊目前正在開發一個“點選即部署”的解決方案。該解決方案旨在讓任何人都能夠在幾分鐘內在真實硬體上快速建立一個工作環境。我們準備好後會分享關於這個開發的更新。
FSM: 這非常有幫助，謝謝。你還有什麼想與我們的讀者分享的最後評論嗎？
RK: 一致性測試是一項協作性的社群工作，涉及 SIG 之間的廣泛合作。SIG Architecture 率先發起了這項倡議並提供了指導。然而，工作的進展在很大程度上依賴於所有 SIG 在審查、改進和認可測試方面的支援。
我想向 ii 團隊表示誠摯的感謝，感謝他們多年來為解決技術債務所做的不懈努力。特別是，Hippie Hacker 對願景的指導和管理是無價的。此外，我還要特別感謝 Stephen Heywood，他在最近的版本中承擔了大部分的測試編寫工作，以及 Zach Mandeville 對 APISnoop 的貢獻。
FSM: 非常感謝你的時間和富有見地的評論，我個人從中獲益匪淺，我相信我們的讀者也會如此。