本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG 架構：一致性
這是 SIG Architecture Spotlight 系列的第一篇訪談，將涵蓋不同的子專案。我們先從 SIG Architecture：Conformance 子專案開始
在這次的 SIG Architecture spotlight 中，我們與 Riaan Kleinhans (ii.nz) 進行了對談，他是 Conformance 子專案 的負責人。
關於 SIG Architecture 和 Conformance 子專案
Frederico (FSM)：哈囉 Riaan，歡迎！首先，請告訴我們一些關於您自己、您的角色以及您如何參與 Kubernetes 的資訊。
Riaan Kleinhans (RK)：嗨！我叫 Riaan Kleinhans，住在南非。我是紐西蘭 ii.nz 團隊的專案經理。當我加入 ii 時，計畫是在 2020 年 4 月搬到紐西蘭，然後 Covid 就發生了。幸運的是，身為一個彈性且充滿活力的團隊，我們能夠遠端工作，並且在非常不同的時區工作。
ii 團隊的任務是管理 Kubernetes Conformance 測試的技術債務，並編寫測試來清除技術債務。我擔任專案經理的角色，成為監控、測試編寫和社群之間的連結。透過這項工作，我很榮幸在最初的幾個月裡見到了 Dan Kohn，他對我們正在做的工作的熱情給了我很大的啟發。
FSM：謝謝您 - 所以，您參與 SIG Architecture 是因為 Conformance 的工作而開始的？
RK：SIG Architecture 是 Kubernetes Conformance 子專案的所在地。最初，我的大部分互動都是透過 Conformance 子專案直接與 SIG Architecture 進行。然而，當我們開始按 SIG 組織工作時，我們開始直接與每個 SIG 進行互動。這些與擁有未經測試 API 的 SIG 的互動，幫助我們加速了工作進度。
FSM：您會如何描述 Conformance 子專案的主要目標和介入領域？
RM：Kubernetes Conformance 子專案的重點是透過開發和維護全面的 Conformance 測試套件，來保證相容性並遵守 Kubernetes 規範。其主要目標包括確保不同 Kubernetes 實作之間的相容性、驗證是否遵守 API 規範、透過鼓勵 Conformance 認證來支援生態系統，以及促進 Kubernetes 社群內的協作。透過提供標準化測試並促進一致的行為和功能，Conformance 子專案確保為開發人員和使用者提供可靠且相容的 Kubernetes 生態系統。
更多關於 Conformance 測試套件的資訊
FSM：我相信，提供這些標準化測試的一部分是 Conformance 測試套件。您可以解釋一下它是什麼以及它的重要性嗎？
RK：Kubernetes Conformance 測試套件檢查 Kubernetes 發行版是否符合專案規範，確保不同實作之間的相容性。它涵蓋各種功能，例如 API、網路、儲存、排程和安全性。通過測試可確認正確的實作，並促進一致且可攜式的容器編排平台。
FSM：是的，這些測試很重要，因為它們定義了任何 Kubernetes 叢集必須支援的最低功能。您可以描述一下決定哪些功能納入考量的過程嗎？在更簡約的方法與來自其他 SIG 的提案之間，是否存在任何緊張關係？
RK：SIG Architecture 明確定義了每個接受 Conformance 測試的端點的要求。只有一般可用且非選用的功能 API 端點才有資格進行 Conformance 測試。多年來，針對 Conformance 規範進行了多次討論，探討是否有可能將選用端點 (例如 RBAC，大多數終端使用者廣泛使用) 納入特定規範中。然而，這方面仍在進行中。
不符合 Conformance 標準的端點列在 ineligible_endpoints.yaml 中，該檔案可在 Kubernetes 儲存庫中公開存取。可以更新此檔案以新增或移除端點，因為其狀態或要求會變更。這些不合格的端點也顯示在 APISnoop 上。
確保透明度並納入社群關於端點合格性或不合格性的意見，對於 SIG Architecture 至關重要。
FSM：為新功能編寫測試通常需要某種程度的強制執行。您如何看待 Kubernetes 中這方面的演變？是否有特定的努力來改進流程，使所需的測試成為一等公民，還是這從來都不是問題？
RK：當 2018 年開始討論 Kubernetes Conformance 計畫時，只有大約 11% 的端點被測試涵蓋。當時，CNCF 的理事會要求，如果要為涵蓋遺失的 Conformance 測試的工作提供資金，Kubernetes 社群應採用一項政策，即除非新功能包含其穩定 API 的 Conformance 測試，否則不允許新增新功能。
SIG Architecture 負責管理此要求，而 APISnoop 已被證明是這方面非常寶貴的工具。透過自動化，APISnoop 每週末都會產生一個 pull request，以突顯 Conformance 涵蓋範圍中的任何差異。如果任何端點在沒有 Conformance 測試的情況下升級為正式發布 (General Availability)，它將會立即被識別出來。這種方法有助於防止新的技術債務累積。
此外，在不久的將來，計畫建立一個發布通知工作 (release informing job)，這將增加一個額外的層級來防止任何新的技術債務。
FSM：我明白了，工具和自動化在那裡發揮了重要作用。在您看來，Conformance 方面仍有哪些領域需要完成工作？換句話說，目前標記為需要改進的優先領域是什麼？
RK：我們在 1.27 版本中達成了「100% Conformance 測試」的里程碑！
在那個時間點，社群再次審視所有被列為不符合 Conformance 資格的端點。該列表是多年來透過社群意見填寫的。先前被認為不符合 Conformance 資格的幾個端點已被識別出來，並重新定位到一個新的專用列表，目前正在重點關注 Conformance 測試開發。同樣，該列表也可以在 apisnoop.cncf.io 上查看。
為了確保避免 Conformance 專案中產生新的技術債務，即將推出建立發布通知工作的計畫，作為額外的預防措施。
雖然 APISnoop 目前託管在 CNCF 基礎架構上，但該專案已慷慨地捐贈給 Kubernetes 社群。因此，它將在 2023 年底之前轉移到社群擁有的基礎架構。
FSM：真是個好消息！對於任何想要提供協助的人，您會強調哪些協作途徑？它們都需要對整個 Kubernetes 有紮實的知識嗎？還是有新手可以貢獻的方式？
RK：貢獻 Conformance 測試就像「洗碗」的工作一樣——它可能不是非常引人注目，但仍然非常重要。它需要對 Kubernetes 有深入的了解，尤其是在需要測試端點的領域。這就是為什麼與擁有被測試 API 端點的每個 SIG 合作如此重要的原因。
作為我們致力於讓每個人都能輕鬆編寫測試的一部分，ii 團隊目前正在從事「點擊並部署」解決方案的開發。此解決方案旨在讓任何人都能在幾分鐘內在真實硬體上快速建立工作環境。一旦準備就緒，我們將分享有關此開發的更新。
FSM：這非常有幫助，謝謝您。您還有什麼最後想與我們的讀者分享的評論嗎？
RK：Conformance 測試是一項協作社群努力，涉及 SIG 之間的廣泛合作。SIG Architecture 率先發起了這項倡議並提供了指導。然而，這項工作的進展很大程度上取決於所有 SIG 在審查、改進和認可測試方面的支持。
我要衷心感謝 ii 團隊多年來對解決技術債務的堅定承諾。特別是，Hippie Hacker 對願景的指導和管理非常寶貴。此外，我要特別感謝 Stephen Heywood，他在最近的版本中承擔了大部分的測試編寫工作量，以及 Zach Mandeville 對 APISnoop 的貢獻。
FSM：非常感謝您的撥冗和富有洞察力的評論，我個人從中學到了很多，我相信我們的讀者也會如此。