Kubernetes雲供應商架構的未來

首先，我想分享SIG的使命，因為我們用它來指導我們現在和將來的工作。從我們的章程中直接來看，SIG的使命是簡化，開發和維護雲供應商整合，作為Kubernetes叢集的擴充套件或附加元件。這背後的動機是雙重的：確保Kubernetes保持可擴充套件性和雲中立（agnostic）。

為了獲得前瞻性的工作視角，我認為重新審視雲供應商的當前狀態非常重要。今天，每個核心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取得聯絡。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31559985/viewspace-2644869/，如需轉載，請註明出處，否則將追究法律責任。