本文已發布超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 中雲端供應商的未來
大約 9 個月前，Kubernetes 社群同意成立雲端供應商特別興趣小組 (SIG)。理由是需要有一個單一的管理 SIG 來擁有和塑造 Kubernetes 與其支援的眾多雲端供應商之間的整合點。從那時起，發生了很多事情，我們在這裡與您分享迄今為止已完成的工作以及我們希望在未來看到的情況。
任務
首先，我想分享 SIG 的任務是什麼，因為我們使用它來指導我們目前和未來的工作。直接從我們的 章程 中摘錄，SIG 的任務是簡化、開發和維護雲端供應商整合，使其成為 Kubernetes 叢集的擴充功能或附加元件。這背後的動機有兩個：確保 Kubernetes 保持可擴展性和雲端不可知。
雲端供應商的現狀
為了對我們的工作獲得前瞻性的觀點，我認為回顧一下雲端供應商的現狀非常重要。如今，每個核心 Kubernetes 元件（排程器和 kube-proxy 除外）都有一個 --cloud-provider 標誌，您可以設定該標誌以啟用一組與底層基礎架構供應商（又名雲端供應商）整合的功能。啟用此整合為您的叢集解鎖了廣泛的功能，例如：節點位址和區域探索、Type=LoadBalancer 的 Service 的雲端負載平衡器、IP 位址管理以及透過 VPC 路由表的叢集網路功能。如今，雲端供應商整合可以在樹內或樹外完成。
樹內和樹外供應商
樹內雲端供應商是我們在 主要 Kubernetes 儲存庫 中開發和發布的供應商。這導致將每個雲端供應商的知識和背景資訊嵌入到大多數 Kubernetes 元件中。這實現了更原生的整合，例如 kubelet 透過雲端供應商的中繼資料服務請求關於自身的資訊。
樹內雲端供應商架構（來源：kubernetes.io）
樹外雲端供應商是可以獨立於 Kubernetes 核心開發、建構和發布的供應商。這需要部署一個名為 cloud-controller-manager 的新元件，該元件負責執行先前在 kube-controller-manager 中執行的所有雲端特定控制器。
樹外雲端供應商架構（來源：kubernetes.io）
當雲端供應商整合最初開發時，它們是以原生方式（樹內）開發的。我們將每個供應商整合到 Kubernetes 的核心附近，並整合到當今 k8s.io/kubernetes 這個單體儲存庫中。隨著 Kubernetes 變得越來越普及，越來越多的基礎架構供應商希望以原生方式支援 Kubernetes，我們意識到這種模型無法擴展。每個供應商都帶來了大量的依賴關係，這增加了我們程式碼庫中潛在的漏洞，並顯著增加了每個元件的二進位檔案大小。除此之外，越來越多的 Kubernetes 版本說明開始關注供應商特定的變更，而不是影響所有 Kubernetes 使用者的核心變更。
在 2017 年底，我們開發了一種讓雲端供應商無需將整合新增到主要 Kubernetes 樹（樹外）即可建構整合的方法。這成為生態系統中新的基礎架構供應商與 Kubernetes 整合的預設方式。從那時起，我們一直積極努力將所有雲端供應商遷移到使用樹外架構，因為如今大多數叢集仍在使用樹內雲端供應商。
展望未來
展望未來，SIG 的目標是移除所有現有的樹內雲端供應商，轉而使用它們的樹外對等物，並盡可能減少對使用者的影響。除了上面提到的核心雲端供應商整合之外，還有更多的雲端整合擴充點，例如 CSI 和映像憑證供應商，這些擴充點正在為 v1.15 版本積極開發中。達到這一點意味著 Kubernetes 是真正的雲端不可知，沒有任何雲端供應商的原生整合。透過完成這項工作，我們授權每個雲端供應商以他們自己的節奏獨立於 Kubernetes 開發和發布新版本。到目前為止，我們已經了解到這是一項巨大的壯舉，並且面臨著一系列獨特的挑戰。遷移工作負載從來都不是一件容易的事，尤其當它是一個控制平面的重要組成部分時。在即將發布的版本中，為我們的 SIG 提供樹內和樹外雲端供應商之間安全且簡單的遷移路徑是最高優先事項。如果這些內容中的任何一個聽起來對您來說很有趣，我鼓勵您查看我們的一些 KEP，並透過加入 郵寄清單 或我們的 Slack 頻道（Kubernetes Slack 中的 #sig-cloud-provider）與我們的 SIG 聯絡。