聚焦 SIG Node

在容器編排領域，Kubernetes 獨佔鰲頭，為全球一些最複雜、最動態的應用程式提供支援。在幕後，一個由特殊興趣小組（SIG）組成的網路推動著 Kubernetes 的創新和穩定。

今天，我很榮幸能與 Matthias Bertschy、Gunju Kim 和 Sergey Kanzhelev 交談，他們是 SIG Node 的成員，將為我們揭示他們在 SIG Node 中的角色、面臨的挑戰以及令人興奮的發展。

所有受訪者共同給出的答案將以其姓名首字母標記。

介紹

Arpit: 感謝你們今天加入我們。請你們介紹一下自己，並簡要概述一下你們在 SIG Node 中的角色。

Matthias: 我叫 Matthias Bertschy，是法國人，住在日內瓦湖畔，靠近法國阿爾卑斯山。我從 2017 年開始成為 Kubernetes 貢獻者，是 SIG Node 的審查員和 Prow 的維護者。我為一家名為 ARMO 的安全初創公司擔任高階 Kubernetes 開發人員，該公司向 CNCF 捐贈了 Kubescape。

Gunju: 我叫 Gunju Kim。我是 NAVER 的一名軟體工程師，主要負責開發搜尋服務的雲平臺。自 2021 年以來，我一直在業餘時間為 Kubernetes 專案做貢獻。

Sergey: 我叫 Sergey Kanzhelev。我從事 Kubernetes 和 Google Kubernetes Engine 的工作已有 3 年，並且多年來一直從事開源專案的工作。我是 SIG Node 的主席。

瞭解 SIG Node

Arpit: 謝謝！能否為我們的讀者概述一下 SIG Node 在 Kubernetes 生態系統中的職責？

M/G/S: SIG Node 是 Kubernetes 中最早的 SIG 之一，如果不是第一個的話。該 SIG 負責 Kubernetes 與節點資源之間的所有迭代，以及節點維護本身。這是一個相當大的範圍，SIG 擁有 Kubernetes 程式碼庫的很大一部分。由於這種廣泛的所有權，SIG Node 始終與其他 SIG（如 SIG Network、SIG Storage 和 SIG Security）保持聯絡，幾乎所有 Kubernetes 中的新功能和開發都以某種方式涉及 SIG Node。

Arpit：SIG Node 如何為 Kubernetes 的效能和穩定性做出貢獻？

M/G/S: Kubernetes 在各種不同大小和形狀的節點上執行，從帶有廉價硬體的小型物理虛擬機器到大型 AI/ML 最佳化的 GPU 節點。節點可能會線上數月，也可能是短暫的，隨時可能因為在雲提供商的過剩計算資源上執行而被搶佔。

kubelet —— 節點上的 Kubernetes 代理 —— 必須在所有這些環境中可靠地工作。至於 kubelet 操作的效能，如今變得越來越重要。一方面，隨著 Kubernetes 越來越多地在電信和零售環境中的超小型節點上使用，它需要擴充套件到儘可能小的佔用空間。另一方面，對於 AI/ML 工作負載，每個節點都極其昂貴，每一秒的延遲操作都會顯著改變計算成本。

挑戰與機遇

Arpit: SIG Node 正在關注哪些即將到來的挑戰和機遇？

M/G/S: 隨著 Kubernetes 進入其第二個十年，我們看到支援新工作負載型別的巨大需求。SIG Node 將在其中扮演重要角色。我們稍後會談到的 Sidecar KEP 就是一個例子，說明了對支援新工作負載型別的重視程度越來越高。

未來幾年我們面臨的關鍵挑戰是如何在保持高質量和現有場景向後相容性的同時，繼續創新。SIG Node 將繼續在 Kubernetes 中發揮核心作用。

Arpit: SIG Node 內部是否有任何正在進行的研究或開發領域讓你們感到興奮？

M/G/S: 支援新的工作負載型別對我們來說是一個非常有趣的領域。我們最近對 Sidecar 容器的探索就是證明。Sidecar 為增強應用程式功能提供了一種通用的解決方案，而無需更改核心程式碼庫。

Arpit: 你們在維護 SIG Node 期間遇到過哪些挑戰，你們是如何克服這些挑戰的？

M/G/S: SIG Node 最大的挑戰是它的規模和收到的眾多功能請求。我們鼓勵更多的人加入成為審查員，並始終樂於改進流程和處理反饋。對於每個版本，我們都會在 SIG Node 會議上進行反饋會，並確定問題領域和行動項。

Arpit: SIG Node 是否正在密切關注或整合到 Kubernetes 中的特定技術或進步？

M/G/S: SIG 所依賴的元件的發展，如容器執行時（例如 containerd 和 CRI-O）以及作業系統特性，是我們積極貢獻並密切關注的領域。例如，即將到來的 cgroup v1 棄用和移除，Kubernetes 和 SIG Node 需要引導 Kubernetes 使用者順利過渡。Containerd 也在釋出 2.0 版本，該版本移除了已棄用的功能，這將影響 Kubernetes 使用者。

Arpit: 在擔任 SIG Node 維護者期間，你是否能分享一次讓你特別自豪的難忘經歷或成就？

Mathias: 我認為最美好的時刻是我的第一個 KEP（引入 startupProbe）最終升級為 GA（正式釋出）。我也很高興看到我的貢獻被貢獻者們日常使用，比如包含 GitHub 樹雜湊的註釋，用於在 squash 提交後保留 LGTM。

Sidecar 容器

Arpit: 你能提供更多關於 Sidecar 容器概念及其在 Kubernetes 環境中演變的背景資訊嗎？

M/G/S: Sidecar 容器的概念可以追溯到 2015 年，當時 Kubernetes 引入了複合容器的概念。這些額外的容器與主應用程式容器在同一個 Pod 中執行，被視為一種擴充套件和增強應用程式功能而不修改核心程式碼庫的方式。Sidecar 的早期採用者使用自定義指令碼和配置來管理它們，但這種方法在一致性和可伸縮性方面帶來了挑戰。

Arpit: 你能分享一些 Sidecar 容器特別有益的具體用例或例子嗎？

M/G/S: Sidecar 容器是一種多功能工具，可用於以多種方式增強應用程式的功能。

• 日誌記錄和監控： Sidecar 容器可用於從主應用程式容器收集日誌和指標，並將其傳送到集中的日誌記錄和監控系統。
• 流量過濾和路由： Sidecar 容器可用於過濾和路由進出主應用程式容器的流量。
• 加密和解密： Sidecar 容器可用於在主應用程式容器和外部服務之間流動時對資料進行加密和解密。
• 資料同步： Sidecar 容器可用於在主應用程式容器和外部資料庫或服務之間同步資料。
• 故障注入： Sidecar 容器可用於向主應用程式容器注入故障，以測試其對故障的恢復能力。

Arpit: 提案中提到一些公司正在使用添加了 Sidecar 功能的 Kubernetes 分支。你能否提供關於該功能的採用水平和社群興趣的見解？

M/G/S: 雖然我們缺乏具體的指標來衡量採用率，但 KEP 已經引起了社群的極大興趣，特別是像 Istio 這樣的服務網格供應商，他們積極參與了其 Alpha 測試階段。KEP 透過眾多部落格文章、訪談、演講和研討會獲得了廣泛關注，進一步證明了其普遍的吸引力。KEP 解決了在 Kubernetes Pod 中主容器旁邊增加額外功能（如網路代理、日誌系統和安全措施）日益增長的需求。社群認識到為現有工作負載提供簡單的遷移路徑以促進該功能的廣泛採用的重要性。

Arpit: 有沒有一些公司在生產環境中使用 Sidecar 容器的顯著例子或成功案例？

M/G/S: 目前期望在生產環境中廣泛採用還為時過早。1.29 版本自 2024 年 1 月 11 日起才在 Google Kubernetes Engine (GKE) 中可用，並且仍然需要關於如何透過通用注入器有效啟用和使用它們的全面文件。流行的服務網格平臺 Istio 也缺乏啟用原生 Sidecar 的適當文件，這使得開發人員難以開始使用這一新功能。然而，隨著原生 Sidecar 支援的成熟和文件的完善，我們可以期待這項技術在生產環境中得到更廣泛的採用。

Arpit: 該提案建議為 init 容器引入一個 restartPolicy 欄位來指示 Sidecar 功能。你能解釋一下這個解決方案如何解決所述的挑戰嗎？

M/G/S: 為 init 容器引入 restartPolicy 欄位的提議透過利用現有基礎設施和簡化 Sidecar 管理來解決所概述的挑戰。這種方法避免了向 Pod 規約中新增新欄位，使其保持可管理性並避免了更多的混亂。透過利用現有的 init 容器機制，Sidecar 可以在 Pod 啟動期間與常規 init 容器一起執行，確保了一致的初始化順序。此外，將 Sidecar init 容器的重啟策略設定為 Always 明確表示即使在主應用程式容器終止後它們也會繼續執行，從而使日誌記錄和監控等持久服務能夠持續到工作負載結束。

Arpit: 為 init 容器引入 restartPolicy 欄位將如何影響與現有 Kubernetes 配置的向後相容性？

M/G/S: 為 init 容器引入 restartPolicy 欄位將保持與現有 Kubernetes 配置的向後相容性。現有的 init 容器將繼續像以前一樣執行，新的 restartPolicy 欄位將僅適用於明確標記為 Sidecar 的 init 容器。這種方法確保了現有應用程式和部署不會被新功能中斷，並提供了一種更簡化的方式來定義和管理 Sidecar。

為 SIG Node 貢獻

Arpit: 對於新成員，尤其是初學者來說，最好的貢獻地方是哪裡？

M/G/S: 新成員和初學者可以透過以下方式為 Sidecar KEP (Kubernetes Enhancement Proposal) 做出貢獻：

• 提高認知度： 建立內容，突出 Sidecar 的好處和用例。這可以教育其他人瞭解該功能並鼓勵其採用。
• 提供反饋： 分享你使用 Sidecar 的經驗，無論是積極的還是消極的。這些反饋可以用來改進該功能，使其更具可用性。
• 分享你的用例： 如果你在生產環境中使用 Sidecar，請與他人分享你的經驗。這有助於展示該功能的實際價值，並鼓勵其他人採用它。
• 改進文件： 幫助澄清和擴充套件該功能的文件。這可以使其他人更容易理解和使用 Sidecar。

除了 Sidecar KEP，SIG Node 在許多其他領域也需要更多的貢獻者：

• 測試覆蓋率： SIG Node 一直在尋找方法來提高 Kubernetes 元件的測試覆蓋率。
• CI 維護： SIG Node 維護一套 e2e 測試，確保 Kubernetes 元件在各種場景下都能按預期執行。

結論

總而言之，SIG Node 是 Kubernetes 發展過程中的基石，確保了其在不斷變化的雲原生計算領域的可靠性和適應性。在 Matthias、Gunju 和 Sergey 等敬業成員的帶領下，SIG Node 始終處於創新的前沿，推動 Kubernetes 邁向新的地平線。

• ←上一篇
• 下一篇→