雲供應商的現狀
爲了獲得前瞻性的工作視角，我認爲重新審視雲供應商的當前狀態非常重要。今天，每個核心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集成的事實上的方式。從那時起，我們一直在積極努力遷移所有云供應商以使用樹外架構，因爲如今大多數集羣仍在使用樹內雲供應商。