聚焦 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 開發人員，該公司將 Kubescape 捐贈給了 CNCF。
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 在許多不同尺寸和形狀的節點上工作，從具有廉價硬體的小型實體 VM 到針對大型 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 commit 的情況下保留 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 增強提案) 做出貢獻
- 提高意識： 建立內容，重點介紹 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 推向新的視野。