我注意到有些云提供商为 kubernetes 提供托管解决方案，我想知道此产品涉及哪些各种组件。
我的直觉告诉我会涉及到一些组件，例如，，，NetworkPolicy但OPA我无法理解整个项目概述应该如何，因为 API 对于集群的每个用户都是相同的。
他们是否部署了各种控制平面，还是为每个用户部署单独的控制平面？
答案1
我猜你指的是主要云提供商的托管解决方案，如 GKE、EKS 和 AKS。每个云提供商都有不同的“秘诀”来管理集群控制平面，但共同的主题是控制平面（kube-apiserver、etcd、kube-controller-manager、kubelet 等）对你作为集群所有者来说是隐藏的。
从您作为这些集群的创建者/所有者的角度来看，这是一个完全独立的集群。您可以为自己的集群获取自己的 kubernetes API 端点的 IP 地址。只有集群的数据才会显示在您的 API 中。
现在，至于他们在幕后做什么让事情看起来如此——这不是公开的知识，但我们可以对他们可能如何做到做出一些合理的猜测。
一种方法是，他们实际上正在为每个集群构建独立的控制平面，并配备自己的虚拟机。有像 ClusterAPI 这样的框架可以以自动化的方式做到这一点。但这不是在主要云平台上运行数千或数百万个 Kubernetes 集群的非常资源高效的方式，所以这可能不是大公司的做法。
另一种方法是在虚拟机池中，在它们自己的隔离容器中运行单独的控制平面组件。也许甚至是另一个 Kubernetes 集群。因此，当收到对新 Kubernetes 集群的请求时，编排器只会生成一个新的 kube-apiserver 部署、一个新的 etcd StatefulSet 等，并将它们连接到指定的工作节点池。我想这或多或少就是 Google 和 Amazon 正在做的事情，但可能比我描述的要复杂得多。
最后，一种方法是完全消除“上游” Kubernetes API 和管理组件（kubelet 和 kube-proxy 除外），而是创建一些定制的、可扩展的、多租户 Kubernetes 控制平面服务。这似乎是 Google 可能会做的事情，因为它最容易扩展，因此可以让他们以最低的成本提供性能最佳的最多集群。然而，它偏离了上游 Kubernetes 代码，因此需要一个庞大、资金充足且专注的开发团队来实现这一点。
如果您正在考虑构建自己的多租户 Kubernetes 基础架构，我建议您考虑使用 Rancher 之类的编排工具来执行此操作，而不是自己动手。使用 Rancher 之类的工具，您可以创建角色来控制租户的访问并创建预配置的集群“模板”。租户单击按钮即可使用您拥有的任何 VM 编排工具（例如 VMware、Digital Ocean 或 AWS 或 GCP 等云提供商）部署新的 Kubernetes 集群。特别是 Rancher 还具有运行多租户集群的能力，即构建一个许多应用程序开发人员同时使用的单个大型 Kubernetes 集群。在这种情况下，您将命名空间分配给每个应用程序团队（Rancher 有一个抽象概念，他们称之为“项目”），并且每个应用程序团队可以完全管理其命名空间中的所有资源，但不能管理集群级别的任何资源。然后由“平台运营”团队（我猜是你？）来管理集群本身。