聚焦 SIG API Machinery
我們最近與 Federico Bongiovanni (Google) 和 David Eads (Red Hat)（SIG API Machinery 主席）進行了訪談，以更深入了解這個 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：我參與 Kubernetes 的時間沒有 David 那麼早，但現在也已經超過六年了。在我之前的公司，我們開始將 Kubernetes 用於我們自己的產品，當我遇到直接參與 Kubernetes 工作的機會時，我便毅然決然地加入了這艘船（絕非雙關語）。我於 2018 年初加入 Google 和 Kubernetes，並從那時起一直參與其中。
SIG Machinery 的範圍
FSM：只需快速瀏覽 SIG API Machinery 的章程，就能發現它具有相當廣泛的範圍，不亞於 Kubernetes 控制平面。您能否用自己的話描述這個範圍？
David：我們負責 kube-apiserver 以及如何有效率地使用它。在後端，這包括它與後端儲存的合約，以及它如何隨著時間的推移實現 API 模式演進。在前端，這包括模式最佳實務、序列化、客戶端模式以及所有這些之上的控制器模式。
Federico：Kubernetes 有許多不同的組件，但控制平面具有非常關鍵的任務：它是您與叢集的通訊層，並且擁有使 Kubernetes 如此強大的所有擴展機制。我們不能犯回歸錯誤或不相容變更之類的錯誤，因為影響範圍非常巨大。
FSM：鑑於範圍如此廣泛，您如何管理它的不同方面？
Federico：我們嘗試將大量工作組織成較小的區域。工作小組和子專案是其中的一部分。SIG 中的不同人員都有自己的專業領域，如果一切都失敗了，我們非常幸運能夠擁有像 David、Joe 和 Stefan 這樣真正「全能型」的人，他們的方式即使經過這麼多年仍然讓我印象深刻。但另一方面，這也是為什麼我們需要更多人來幫助我們將 Kubernetes 的品質和卓越性從一個版本延續到下一個版本的原因。
不斷演進的協作模式
FSM：現有的模式一直都是這樣嗎？還是隨著時間推移而演進？如果是，您認為主要變化是什麼？背後的原因是什麼？
David：API Machinery 的範圍隨著時間推移而演進，既有擴大也有縮小。當試圖滿足客戶端存取模式時，很容易在功能和應用方面都增加範圍。
範圍擴大的好例子是，我們發現需要減少編寫控制器的客戶端的記憶體使用率，並開發了共用資訊器。在開發共用資訊器和控制器模式（工作佇列、錯誤處理和列表器）的使用過程中，我們大大降低了記憶體使用率，並消除了許多昂貴的列表。缺點是：我們擴展了一組新的功能來支援，並有效地從 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 多個節點/命名空間）。這個時期的特點是快速變更。我們經歷了五個不同版本的模式，並迎接了需求。我們針對快速的樹狀結構內 API 演進進行了最佳化（有時會損害長期目標），並首次定義了模式。擴展以滿足需求：
v1.3-1.9左右（最多達到控制器中的共用資訊器）。當我們開始嘗試滿足客戶需求並獲得採用時，我們發現 CPU 和記憶體方面存在嚴重的擴展限制。這時我們擴展了 API 機械以包含存取模式，但仍然非常專注於樹狀結構內類型。我們建構了監看快取、protobuf 序列化和共用快取。促進生態系統：
v1.8-1.21左右（最多達到 CRD v1）。這時我們設計並編寫了 CRD（被認為是第三方資源的替代品）、我們知道即將到來的迫切需求（准入 webhook）以及我們知道需要的最佳實務演進（API 模式）。這促成了早期採用者的爆炸性增長，他們願意非常謹慎地在限制內工作，以實現他們服務 Pod 的使用案例。採用速度非常快，有時甚至超過了我們的能力，並產生了新的問題。簡化部署：
v1.22+。在相對較近的過去，我們一直在回應壓力，或者在大規模執行 kube 叢集，其中有大量有時會衝突的生態系統專案使用我們的擴展機制。現在，許多努力都投入到使平台擴展更容易編寫，並讓那些沒有 Kubernetes 博士學位的人也能更安全地管理。這始於伺服器端套用之類的功能，並持續到今天，例如 webhook 匹配條件和驗證准入策略等功能。
API Machinery 的工作對整個專案和生態系統都產生了廣泛的影響。對於那些能夠在長期視野中投入大量時間的人來說，這是一個令人興奮的領域。
未來的道路
FSM：考慮到這些不同的演進階段，您認為目前 SIG 的首要任務是什麼？
David： 大致按這個順序：可靠性、效率和功能。
隨著我們的 kube-apiserver 和擴展機制的使用量增加，我們發現我們的第一組擴展機制雖然在功能方面相當完整，但在潛在的誤用方面存在重大風險，影響範圍很大。為了降低這些風險，我們正在投資於減少意外影響範圍的功能（webhook 匹配條件），以及為大多數操作提供風險較低的替代機制（驗證准入策略）。
同時，使用量的增加也讓我們更加意識到我們可以改進伺服器端和客戶端擴展限制。這方面的努力包括更有效率的序列化 (CBOR)、降低 etcd 負載（從快取一致性讀取）以及降低峰值記憶體使用量（串流列表）。
最後，使用量的增加也突顯了一些長期存在的差距，我們正在彌合這些差距。例如 CRD 的欄位選擇器，Batch 工作小組 正熱切希望利用它，並最終將成為防止來自被利用節點的跳板 Pod 攻擊的新方法的基礎。
加入樂趣
FSM：對於任何想要開始貢獻的人，您有什麼建議？
Federico：SIG API Machinery 並不例外於 Kubernetes 的座右銘：砍柴挑水。每週都有多個會議向所有人開放，而且總是有比人更多的工作要做。
我承認 API Machinery 並不容易，學習曲線會很陡峭。標準很高，因為我們一直在討論的原因：我們承擔著巨大的責任。但當然，憑藉熱情和毅力，多年來有許多人逐漸上手，我們希望將來會有更多人加入。
關於具體機會，每兩週都會舉行 SIG 會議。歡迎所有人參加和聆聽，了解小組討論的內容，了解此版本的進展等等。
此外，每週兩次，週二和週四，我們都會進行公開的 Bug 分流，我們會檢查上次會議以來的所有新內容。我們已經保持這種做法超過 7 年了。這是一個很好的機會，可以自願審查程式碼、修復錯誤、改進文件等等。週二的時間是下午 1 點 (PST)，週四的時間是 EMEA 友善時間（PST 上午 9:30）。我們一直在尋求改進，我們希望將來能夠提供更多具體的機會來加入和參與。
FSM：太棒了，謝謝您！您還有什麼最後的評論想與我們的讀者分享嗎？
Federico：正如我所提到的，最初的步驟可能很困難，但回報也更大。從事 API Machinery 的工作是在一個影響巨大的領域工作（數百萬使用者？），您的貢獻將直接影響 Kubernetes 的運作方式和使用方式。對我來說，這已是足夠的回報和動力！