Kubernetes云供應商架構的未來

為了獲得前瞻性的工作視角，我認為重新審視云供應商的當前狀態非常重要。今天，每個核心Kubernetes組件（除了調度程序和kube-proxy）都有一個-cloud-provider標志，你可以配置該標志以啟用一組與底層基礎架構提供程序集成的功能，即云供應商程序。啟用此集成可為群集啟用一系列功能，例如：節點地址和區域發現，具有Type= LoadBalancer的服務的云負載平衡器，IP地址管理以及通過VPC路由表的群集網絡。今天，云供應商集成可以在樹中或在樹外完成。

樹內云提供程序是我們在主Kubernetes存儲庫中開發和發布的供應商程序。這導致將每個云供應商的知識和上下文嵌入到大多數Kubernetes組件中。這使得更多原生集成（例如，kubelet）能夠通過來自云供應商的元數據服務來請求關于其自身的信息。

In-Tree Cloud Provider Architecture

樹外云供應商是可以獨立于Kubernetes核心開發，構建和發布的供應商。這需要部署一個名為cloud-controller-manager的新組件，該組件負責運行以前在kube-controller-manager中運行的所有特定于云的控制器。

Out-of-Tree云供應商架構

當最初開發云提供程序集成時，它們是原生開發的（在樹中）。我們將每個供應商集成在Kubernetes的核心附近，并在今天的k8s.io/kubernetes整體存儲庫中。隨著Kubernetes變得越來越普遍，越來越多的基礎設施供應商希望原生支持Kubernetes，我們意識到這種模式不會擴展。每個提供程序都會帶來大量依賴項，這會增加代碼庫中的潛在漏洞，并顯著增加每個組件的二進制大小。除此之外，更多Kubernetes發行說明開始關注供應商特定的更改，而不是影響所有Kubernetes用戶的核心更改。

在2017年末，我們為云供應商開發了一種方法來構建集成，而無需將它們添加到主Kubernetes樹（樹外）。這成為生態系統中新的基礎設施供應商與Kubernetes集成的事實上的方式。從那時起，我們一直在積極努力遷移所有云供應商以使用樹外架構，因為如今大多數集群仍在使用樹內云供應商。

展望未來，SIG的目標是刪除所有現有的樹內云供應商，轉而使用樹外的實現，同時對用戶的影響最小。除了上面提到的核心云供應商集成之外，還有更多的云集成擴展點，如CSI和鏡像憑據供應商，正在為v1.15積極開展工作。達到這一點意味著Kubernetes真正與云中立，沒有針對任何云供應商的原生集成。通過這項工作，我們使每個云供應商能夠獨立于Kubernetes以自己的節奏開發和發布新版本。我們現在已經知道，這是一項具有獨特挑戰的巨大壯舉。遷移工作負載絕非易事，尤其是當它是控制平面的重要組成部分時。在即將發布的版本中，我們的SIG最優先考慮在樹內和樹外云供應商之間提供安全且簡便的遷移路徑。如果你對此感興趣，我建議你查看我們的一些KEP并通過加入郵件列表或我們的Slack渠道（Kubernetesslack中的#sig-cloud-provider）與我們的SIG取得聯系。