本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

聚焦 SIG API Machinery

作者：Frederico Muñoz (SAS Institute) | 2024 年 8 月 7 日，星期三

我們最近與 SIG API Machinery 的主席 Federico Bongiovanni (Google) 和 David Eads (Red Hat) 進行了交談，以更多地瞭解這個 Kubernetes 特別興趣小組。

介紹

Frederico (FSM)：你好，感謝你們抽出時間。首先，能介紹一下你們自己以及你們是如何參與到 Kubernetes 中的嗎？

David：我於 2014 年秋季開始在 OpenShift（Red Hat 的 Kubernetes 發行版）工作，並很快地參與到 API Machinery 中。我的第一個 PR 是修復 kube-apiserver 的錯誤訊息，之後我擴充套件到 kubectl（kubeconfigs 是我的鍋！）、auth（RBAC 和 *Review API 是從 OpenShift 移植過來的）、apps（例如 workqueues 和 sharedinformers）。別告訴其他人，但 API Machinery 仍然是我的最愛 :)

Federico：我沒有 David 那麼早就接觸 Kubernetes，但現在也已經超過六年了。在我之前的公司，我們開始為自己的產品使用 Kubernetes，當我遇到直接參與 Kubernetes 工作的機會時，我拋下一切登上了這艘船（沒有雙關的意思）。我在 2018 年初加入 Google 和 Kubernetes，並從那時起一直參與其中。

SIG Machinery 的範圍

FSM：只要快速看一下 SIG API Machinery 的章程，就會發現它的範圍相當廣泛，涵蓋了整個 Kubernetes 控制平面。你能用自己的話來描述這個範圍嗎？

David：我們負責 kube-apiserver 以及如何高效地使用它。在後端，這包括它與後端儲存的契約，以及它如何允許 API Schema 隨時間演進。在前端，這包括 Schema 最佳實踐、序列化、客戶端模式以及建立在這一切之上的控制器模式。

Federico：Kubernetes 有很多不同的元件，但控制平面有一個非常關鍵的任務：它是你與叢集的通訊層，也負責所有使 Kubernetes 如此強大的可擴充套件性機制。我們不能犯像迴歸或不相容變更這樣的錯誤，因為影響範圍非常大。

FSM：鑑於其廣度，你們是如何管理其不同方面的？

Federico：我們試圖將大量的工作組織成更小的領域。工作組和子專案是其中的一部分。SIG 中的不同人有各自的專業領域，如果一切都失敗了，我們很幸運有像 David、Joe 和 Stefan 這樣的人，他們真是“全能型選手”，即使這麼多年過去了，他們的方式仍然讓我印象深刻。但另一方面，這也是我們需要更多人來幫助我們，在一個又一個版本中，傳承 Kubernetes 的質量和卓越性的原因。

不斷演進的協作模式

FSM：現有的模式是一直如此，還是隨著時間演變的？如果是後者，你認為主要的變化及其背後的原因是什麼？

David：API Machinery 的範圍隨著時間不斷演變，既有擴充套件也有收縮。在試圖滿足客戶端訪問模式時，很容易在功能和應用方面增加範圍。

一個很好的擴充套件範圍的例子是，我們發現需要減少編寫控制器的客戶端的記憶體使用，並開發了共享 Informer。在開發共享 Informer 和使用它們的控制器模式（工作佇列、錯誤處理和 Listers）時，我們大大減少了記憶體使用並消除了許多昂貴的列表操作。缺點是：我們增加了一套新的功能需要支援，並實際上從 sig-apps 手中接管了那個領域的所有權。

對於一個更共享所有權的例子：在構建協作資源管理（伺服器端應用的目標）時，kubectl 擴充套件了其職能，負責利用伺服器端應用功能。這個過渡尚未完成，但 SIG CLI 負責管理和擁有該用法。

FSM：對於不同方法之間的界限，你們有什麼指導方針嗎？

David：我認為很大程度上取決於影響。如果影響在即時效應上是區域性的，我們會建議其他 SIG，讓他們按自己的節奏進行。如果影響在即時效應上是全域性性的，且沒有自然的激勵機制，我們發現有必要直接推動採用。

FSM：還是關於這個問題，SIG Architecture 有一個 API 治理子專案，它與 SIG API Machinery 大多是獨立的，還是有重要的連線點？

David：這兩個專案的名字聽起來很像，並且彼此之間有一些影響，但它們的使命和範圍是不同的。API Machinery 負責“如何做”，而 API 治理負責“做什麼”。API 約定、API 批准流程以及對單個 k8s.io API 的最終決定權屬於 API 治理。API Machinery 負責 REST 語義和非 API 特定的行為。

Federico：我非常喜歡 David 的說法：“API Machinery 負責‘如何做’，而 API 治理負責‘做什麼’”：我們不擁有實際的 API，但實際的 API 是透過我們而存在的。

Kubernetes 普及帶來的挑戰

FSM：隨著 Kubernetes 的採用率不斷增長，我們肯定看到了對控制平面日益增長的需求：這對你們有什麼影響，以及它如何影響 SIG 的工作？

David：這對 API Machinery 產生了巨大影響。多年來，我們經常響應並多次推動了 Kubernetes 的演進階段。作為 Kubernetes 叢集上幾乎所有功能的中心編排樞紐，我們既引領又跟隨社群。總的來說，我看到 API Machinery 多年來經歷了幾個演進階段，並且活動一直非常頻繁。

尋找目標：pre-1.0 到 v1.3 左右（直到我們首次支援 1000+ 節點/名稱空間）。這段時間的特點是快速變化。我們經歷了五個不同版本的 Schema，並滿足了需求。我們優化了快速的、樹內 API 演進（有時以犧牲長期目標為代價），並首次定義了模式。
擴充套件以滿足需求：v1.3-1.9 左右（直到控制器中的共享 Informer）。當我們開始試圖滿足客戶需求時，隨著採用率的增加，我們在 CPU 和記憶體方面發現了嚴重的擴充套件限制。正是在這個時候，我們擴大了 API Machinery 的範圍，以包括訪問模式，但仍然嚴重關注樹內型別。我們構建了 watch 快取、protobuf 序列化和共享快取。
培育生態系統：v1.8-1.21 左右（直到 CRD v1）。這是我們設計和編寫 CRD（被認為是第三方資源的替代品）、我們知道即將到來的即時需求（准入 Webhook）以及我們知道我們需要的最佳實踐演進（API Schema）的時候。這使得早期採用者願意在約束範圍內非常謹慎地工作，以實現他們為 Pod 提供服務的用例，從而促成了一次爆炸式增長。採用速度非常快，有時超出了我們的能力，併產生了新的問題。
簡化部署：v1.22+。在相對較近的過去，我們一直在應對大規模執行 Kube 叢集的壓力，其中有大量有時相互衝突的生態系統專案使用我們的擴充套件機制。現在，大量精力投入到使平臺擴充套件更容易編寫和更安全地由那些不持有 Kubernetes 博士學位的人來管理。這始於像伺服器端應用這樣的事情，並一直持續到今天，例如 Webhook 匹配條件和驗證准入策略等功能。

API Machinery 的工作對整個專案和生態系統都有廣泛的影響。對於那些能夠進行長期、大量時間投入的人來說，這是一個令人興奮的工作領域。

前路漫漫

FSM：考慮到這些不同的演進階段，你認為目前 SIG 的首要任務是什麼？

David： 可靠性、效率和能力，大致按這個順序。

隨著我們的 kube-apiserver 和擴充套件機制的使用增加，我們發現我們第一套擴充套件機制雖然在功能方面相當完備，但在潛在的濫用方面帶有重大風險，影響範圍很大。為了減輕這些風險，我們正在投資於能夠減少意外事故影響範圍的功能（Webhook 匹配條件），併為大多數操作提供風險較低的替代機制（驗證准入策略）。

與此同時，使用的增加使我們更加意識到我們可以從伺服器端和客戶端改進的擴充套件限制。這方面的努力包括更高效的序列化（CBOR）、減少 etcd 負載（從快取中進行一致性讀取）以及減少峰值記憶體使用（流式列表）。

最後，使用的增加凸顯了一些我們正在彌補的長期存在的差距。例如 CRD 的欄位選擇器，批處理工作組急於利用它，並最終將構成一種防止來自被利用節點的跳板 Pod 攻擊的新方法的基礎。

加入我們

FSM：對於任何想開始貢獻的人，你有什麼建議？

Federico：SIG API Machinery 也不例外於 Kubernetes 的座右銘：“挑水砍柴”。每週都有多個對所有人開放的會議，而且總是有比人力更多的工作要做。

我承認 API Machinery 不容易，入門曲線會很陡峭。門檻很高，原因我們已經討論過：我們肩負著巨大的責任。但當然，憑藉熱情和毅力，多年來許多人已經成長起來，我們希望未來會有更多人加入。

就具體機會而言，每兩週有一次 SIG 會議。歡迎大家參加和聆聽，瞭解小組在談論什麼，瞭解本版本中正在發生的事情等。

此外，每週兩次，週二和週四，我們有公開的 Bug 分類會議，我們會審查自上次會議以來的所有新內容。我們已經堅持這個做法超過 7 年了。這是一個絕佳的機會，可以自願審查程式碼、修復 Bug、改進文件等。週二的會議時間是下午 1 點（PST），週四的會議時間對 EMEA 地區友好（上午 9:30 PST）。我們一直在尋求改進，並希望將來能提供更多具體的加入和參與機會。

FSM：太好了，謝謝你們！還有什麼最後的評論想與我們的讀者分享嗎？

Federico：正如我提到的，起步可能會很困難，但回報也更大。在 API Machinery 工作，是在一個具有巨大影響力的領域工作（數百萬使用者？），你的貢獻將直接影響 Kubernetes 的工作方式和使用方式。對我來說，這本身就是足夠的回報和動力！