CNCF 展示了 vCluster 如何缓解 Kubernetes 多租户挑战

云原生计算基金会（CNCF）发表了一篇博客文章，讨论了 Loft Labs 的开源项目 vCluster 如何通过在单个宿主机群中启用“虚拟集群”来解决 Kubernetes 集群中关键的多租户挑战。这种方法使得多个租户可以拥有隔离的控制平面，同时共享底层计算资源，从而在不牺牲隔离性的情况下减少开销。

在 Kubernetes 中，传统的基于命名空间的隔离通常在租户需要部署集群范围的资源（如自定资源定义，CRDs）或平台工程团队希望在团队之间保持强大的分离性时力不从心。根据 CNCF 的文章，vCluster提供了一个实用的替代方案。虚拟集群作为应用程序在宿主的命名空间中运行，但为租户负载提供了完整的 Kubernetes API 服务器、控制器管理器和数据存储。同步组件确保虚拟集群中的 Pods、ConfigMaps、密钥和服务被镜像到宿主命名空间，允许它们在底层宿主节点上正常执行。

文章描述的最亮眼的用例之一是团队需要自治（例如，安装 CRDs）而不授予他们在共享集群上的广泛管理员权限。没有虚拟集群，团队将面临一系列没什么吸引力的选择：拒绝请求并冒着摩擦的风险，扩大权限并削弱隔离，集中管理资源并增加负担，或提供专用集群，代价是更高的成本和运营开销。vCluster 模型让租户表现得几乎就像他们拥有自己的集群一样，同时保持底层资源由平台团队共享和控制，从而规避了上述权衡。

博客还探讨了常见的平台工程工具，如用于策略执行的 Kyverno 或用于运行时安全监控的 Falco，如何与虚拟集群交互。例如，安装在宿主集群上的 Falco 仍然可以检测来自 vCluster 的负载中的可疑活动，因为这些负载以转换后的名称和命名空间存在于宿主上。同样，宿主级别定义的 Kyverno 策略可以验证或强制执行针对虚拟集群负载的规则。然而，文章指出，团队必须为同步延迟和被镜像的资源等细节做好计划。

虽然虚拟集群有望平衡成本、隔离和开发者自治，但文章也提醒团队要了解对应的权衡。由于负载仍然共享相同的宿主集群节点，围绕数据、网络和潜在的“嘈杂邻居”效应的强大租户隔离仍然需要适当的配置。此外，虚拟集群模型中对某些集群范围或节点特定资源的支持可能仍然有限，这是组织在评估是否采用这种架构时必须权衡的考虑因素。

不过，不仅仅是 vCluster 在这一领域寻求发展。Capsule提供了一个以命名空间为中心的运营商方法。它通过在面向多租户使用的 RBAC、资源配额、网络策略和准入控制中增加层次，增强了 Kubernetes 原生命名空间。虽然它不提供每个租户的完全独立的控制平面，但它相对轻量级，并且可以很好地集成到现有集群中。这使得 Capsule 非常适合需要自助命名空间配置和共享集群经济的组织，而不需要虚拟集群编排的全部开销。

另一方面，Kamaji针对一个略有不同的角度：它旨在通过代表租户提供专用的控制平面来实现“集群即服务”，但仍然共享底层基础设施和控制平面管理。换句话说，它提供了更类似于专用集群模型的每个租户控制平面分离，但自动化了许多多集群运维负担。

CNCF 对 vCluster 的报道强调了 Kubernetes 多租户方法的成熟：从简单的命名空间隔离，转向真正的虚拟集群抽象，提供更好的隔离，而不需要完全独立的物理集群的成本。对于与多个租户团队打交道的平台团队来说，这可能提供了一个实际的前进道路。

原文链接：CNCF Highlights How vCluster Eases Kubernetes Multi-Tenancy Challenges