这篇文章已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 的三种租户模型
Kubernetes 集群通常被组织中的多个团队使用。在其他情况下，Kubernetes 可用于向最终用户交付应用程序，这些应用程序需要在不同组织的用户之间进行资源分段和隔离。安全共享 Kubernetes 控制平面和工作节点资源可以在这两种情况下最大化生产力并节省成本。
Kubernetes 多租户工作组的任务是定义 Kubernetes 的租户模型，并使其更容易操作与租户相关的用例。这篇来自工作组成员的博客文章介绍了三种常见的租户模型，并介绍了相关的工作组项目。
我们还将在 2021 年 Kubecon EU 小组会议上介绍此内容并讨论不同的用例，多租户与多集群：何时应该使用哪个？。
命名空间即服务
使用命名空间即服务模型，租户共享一个集群，租户工作负载被限制为分配给该租户的一组命名空间。集群控制平面资源（如 API 服务器和调度器）以及工作节点资源（如 CPU、内存等）可供所有租户使用。
为了隔离租户工作负载，每个命名空间还必须包含
使用此模型，租户共享集群范围的资源（如 ClusterRole 和 CustomResourceDefinitions (CRD)），因此无法创建或更新这些集群范围的资源。
分层命名空间控制器 (HNC) 项目使用户可以更容易地管理基于命名空间的租户，允许用户在命名空间下创建其他命名空间，并在命名空间层次结构中传播资源。这允许租户进行自助服务命名空间，而无需集群范围的权限。
多租户基准 (MTB) 项目提供基准和一个命令行工具，该工具执行多项配置和运行时检查，以报告租户命名空间是否正确隔离并且是否实施了必要的安全控制。
集群即服务
使用集群即服务使用模型，每个租户都获得自己的集群。此模型允许租户拥有不同版本的集群范围资源（如 CRD），并提供 Kubernetes 控制平面的完全隔离。
租户集群可以使用 Cluster API (CAPI) 等项目进行配置，其中管理集群用于配置多个工作负载集群。工作负载集群分配给租户，租户可以完全控制集群资源。请注意，在大多数企业中，中央平台团队可能负责管理必需的附加服务（如安全和监控服务），并负责提供集群生命周期管理服务（如修补和升级）。租户管理员可能被限制修改集中管理的服务和其他关键集群信息。
控制平面即服务
在集群即服务模型的变体中，租户集群可能是虚拟集群，其中每个租户都获得自己的专用 Kubernetes 控制平面，但共享工作节点资源。与其他形式的虚拟化一样，虚拟集群的用户看不到虚拟集群与其他 Kubernetes 集群之间的显着差异。这有时称为 控制平面即服务 (CPaaS)。
这种类型的虚拟集群共享工作节点资源和独立于工作负载状态的控制平面组件，如调度器。其他感知工作负载的控制平面组件（如 API 服务器）是按租户创建的，以允许重叠，并使用其他组件来同步和管理每个租户控制平面和底层共享集群资源之间的状态。使用此模型，用户可以管理自己的集群范围的资源。
虚拟集群项目实现了此模型，其中一个 超级集群 由多个 虚拟集群 共享。Cluster API Nested 项目正在扩展这项工作以符合 CAPI 模型，允许使用熟悉的 API 资源来配置和管理虚拟集群。
安全注意事项
云原生安全涉及不同的系统层和生命周期阶段，如 CNCF SIG 安全的 云原生安全白皮书 中所述。如果未在所有层和阶段实施适当的安全措施，则 Kubernetes 租户隔离可能会受到损害，并且一个租户的安全漏洞可能会威胁到其他租户。
对于任何新的 Kubernetes 用户来说，重要的是要意识到新的上游 Kubernetes 集群的默认安装是不安全的，并且您需要投入精力对其进行加固以避免安全问题。
至少需要以下安全措施
- 镜像扫描：容器镜像中的漏洞可能被利用来执行命令并访问其他资源。
- RBAC：对于命名空间即服务模型，必须在每个命名空间级别正确配置用户角色和权限；对于其他模型，可能需要限制租户访问集中管理的附加服务和其他集群范围的资源。
- 网络策略：对于命名空间即服务模型，建议使用拒绝所有入口和出口流量的默认网络策略，以防止跨租户的网络流量，并且也可用作其他租户模型的最佳实践。
- Kubernetes Pod 安全标准：为了强制执行 Pod 加固最佳实践，建议将
Restricted策略作为租户工作负载的默认策略，并且仅在需要时配置排除项。 - Kubernetes 的 CIS 基准：应该使用 Kubernetes 的 CIS 基准指南来正确配置 Kubernetes 控制平面和工作节点组件。
其他建议包括使用
- 策略引擎：用于配置安全最佳实践，例如仅允许受信任的注册表。
- 运行时扫描器：用于检测和报告运行时安全事件。
- 基于 VM 的容器沙箱：用于更强的数据平面隔离。
虽然适当的安全性是独立于租户模型的要求，但在共享集群中没有诸如 Pod 安全之类的基本安全控制，会为攻击者提供破坏租户模型并可能跨租户访问敏感信息的手段，从而增加整体风险状况。
总结
2020 年 CNCF 的一项调查显示，自 2016 年以来，生产环境 Kubernetes 的使用量增加了 300% 以上。随着越来越多的 Kubernetes 工作负载转移到生产环境，各组织正在寻找跨团队共享 Kubernetes 资源的方法，以提高敏捷性和节省成本。
命名空间即服务租户模型允许共享集群，从而实现资源效率。但是，它需要正确的安全配置，并且由于所有租户共享相同的集群范围资源而存在局限性。
集群即服务租户模型解决了这些局限性，但管理和资源开销更高。
控制平面即服务模型提供了一种共享单个 Kubernetes 集群资源的方法，也允许租户管理自己的集群范围资源。共享工作节点资源可以提高资源效率，但也暴露了共享集群中存在的跨租户安全和隔离问题。
在许多情况下，组织将使用多种租户模型来解决不同的用例，并且不同的产品和开发团队将有不同的需求。遵循安全和管理最佳实践，例如应用 Pod 安全标准并且不使用 default 命名空间，可以更轻松地从一个模型切换到另一个模型。
Kubernetes 多租户工作组创建了多个项目，例如 分层命名空间控制器、虚拟集群 / CAPI 嵌套 和 多租户基准，以使多租户模型的配置和管理更加容易。
如果您对多租户主题感兴趣，或想分享您的用例，请加入我们即将举行的 社区会议 或在 Kubernetes Slack 上的 wg-multitenancy 频道联系我们。