為 Kubernetes 建構多租戶託管控制平面
我注意到有一些雲提供商為 kubernetes 提供託管解決方案，我想知道此產品中涉及的各種組件是什麼。
我的直覺告訴我會涉及到一些組件，例如 ,
NetworkPolicy，OPA但我無法完全理解整個項目的概述，因為對於集群的每個使用者來說，API 都是相同的。他們是在部署各種控制平面，還是為每個使用者部署單獨的控制平面？
我認為您指的是主要雲提供商中的 GKE、EKS 和 AKS 等託管解決方案。每個雲提供商對於如何管理集群控制平面都有不同的“秘訣”，但共同的主題是控制平面（kube-apiserver、etcd、kube-controller-manager、kubelet 等）被隱藏起來您作為集群所有者。
從您作為這些集群之一的創建者/所有者的角度來看，它是一個完全獨立的集群。您可以為自己的集群獲取自己的 Kubernetes API 端點的 IP 地址。只有集群的數據會顯示在您的 API 中。
現在，至於他們在幕後做了什麼讓事情看起來像這樣——這不是公開的知識，但我們可以對他們可能是如何做的做出一些合理的猜測。
一種方法是，他們實際上是在為每個集群建構獨立的控制平面，並配有自己的虛擬機。有像 ClusterAPI 這樣的框架可以自動執行此操作。但這並不是在主要雲平台上執行數千或數百萬個 Kubernetes 集群的一種非常節省資源的方式，因此大玩家可能不是這樣做的。
另一種方法是在虛擬機池上的獨立容器中執行單獨的控制平面組件。甚至可能是另一個 Kubernetes 集群。所以當一個新的 Kubernetes 集群的請求進來時，編排器只是產生一個新的 kube-apiserver 部署、一個新的 etcd StatefulSet 等，並將它們連接到指定的工作節點池。我想這或多或少是Google和亞馬遜正在做的事情，但可能比我所描述的要復雜得多。
最後，一種方法是消除“上游”Kubernetes API 和管理組件（除了 kubelet 和 kube-proxy），而是創建一些定制的、可擴展的、多租戶 Kubernetes 控制平面服務。這似乎是Google可能會做的事情，因為這將是最容易擴展的，因此可以讓他們以最低的成本提供最多的集群和最好的性能。但是，它偏離了上游 Kubernetes 程式碼，因此需要一個龐大、資金充足且敬業的開發團隊來完成這項工作。
如果您正在考慮建構自己的多租戶 Kubernetes 基礎架構，我建議您考慮使用 Rancher 之類的編排工具來執行此操作，而不是自己動手。使用 Rancher 之類的東西將允許您創建角色來控制租戶的訪問權限並創建預配置的集群“模板”。租戶點擊按鈕以使用您擁有的任何 VM 編排工具（例如 VMware、Digital Ocean 或 AWS 或 GCP 等雲提供商）部署新的 Kubernetes 集群。尤其是 Rancher 還具有執行多租戶集群的能力，即建構許多應用程序開發人員同時使用的單個大型 Kubernetes 集群。在這種情況下，您將命名空間分配給每個應用程序團隊（Rancher 有一個他們稱之為“項目”的抽象），每個應用程序團隊可以完全管理其命名空間中的所有資源，但不能在集群級別管理任何東西。然後由“平台運營”團隊（我猜是你？）來管理集群本身。