Kubernetes雲供應商架構的將來

首先，我想分享SIG的使命，由於咱們用它來指導咱們如今和未來的工做。從咱們的章程中直接來看，SIG的使命是簡化，開發和維護雲供應商集成，做爲Kubernetes集羣的擴展或附加組件。這背後的動機是雙重的：確保Kubernetes保持可擴展性和雲中立（agnostic）。

雲供應商的現狀

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

In-Tree和Out-of-Tree供應商

樹內雲提供程序是咱們在主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取得聯繫。