本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 中雲驅動的未來
大約 9 個月前，Kubernetes 社群同意成立雲提供商特別興趣小組 (SIG)。這樣做的理由是，需要一個統一的 SIG 來負責並塑造 Kubernetes 與其支援的眾多雲提供商之間的整合點。自那時起，許多工作一直在進行中，我們在此與您分享迄今為止所取得的成就以及我們對未來的展望。
使命
首先，我想分享一下 SIG 的使命，因為我們用它來指導我們現在和未來的工作。直接摘自我們的章程，SIG 的使命是簡化、開發和維護雲提供商整合，作為 Kubernetes 叢集的擴充套件或附加元件。這背後的動機是雙重的：確保 Kubernetes 保持可擴充套件性和雲無關性。
雲提供商的現狀
為了對我們的工作有一個前瞻性的視角，我認為退一步審視雲提供商的現狀非常重要。如今，每個核心 Kubernetes 元件（排程器和 kube-proxy 除外）都有一個 --cloud-provider 標誌，您可以配置該標誌以啟用一組功能，這些功能與底層基礎設施提供商（即雲提供商）整合。啟用此整合將為您的叢集解鎖一系列廣泛的功能，例如：節點地址和區域發現、用於 Type=LoadBalancer 的服務的雲負載均衡器、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 取得聯絡。