本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 的三种租户模型
Kubernetes 集群通常由组织内的多个团队使用。在其他情况下，Kubernetes 可能用于向最终用户交付应用程序，需要对来自不同组织的用户资源进行分段和隔离。安全共享 Kubernetes 控制平面和工作节点资源在这两种情况下都可以最大限度地提高生产力并节省成本。
Kubernetes 多租户工作组负责定义 Kubernetes 的租户模型，并使其更容易操作与租户相关的用例。这篇来自工作组成员的博文描述了三种常见的租户模型，并介绍了相关的工作组项目。
我们还将在 Kubecon EU 2021 小组会议上介绍此内容并讨论不同的用例，会议主题是 多租户与多集群：何时使用哪种？。
命名空间即服务
使用 *命名空间即服务* 模型，租户共享一个集群，租户工作负载被限制在分配给租户的一组命名空间中。集群控制平面资源（如 API 服务器和调度器）以及工作节点资源（如 CPU、内存等）可供所有租户使用。
为了隔离租户工作负载，每个命名空间还必须包含
使用此模型，租户共享集群范围的资源，例如 ClusterRole 和 CustomResourceDefinition (CRD)，因此无法创建或更新这些集群范围的资源。
分层命名空间控制器 (HNC) 项目通过允许用户在命名空间下创建额外的命名空间，并在命名空间层次结构中传播资源，从而更容易管理基于命名空间的租户。这允许租户进行自助命名空间，而无需集群范围的权限。
多租户基准 (MTB) 项目提供基准和命令行工具，该工具执行多项配置和运行时检查，以报告租户命名空间是否正确隔离以及是否实施了必要的安全控制。
集群即服务
使用 *集群即服务* 用例模型，每个租户都有自己的集群。此模型允许租户拥有不同版本的集群范围资源（如 CRD），并提供 Kubernetes 控制平面的完全隔离。
租户集群可以使用 Cluster API (CAPI) 等项目进行预置，其中管理集群用于预置多个工作负载集群。一个工作负载集群分配给一个租户，租户对集群资源拥有完全控制权。请注意，在大多数企业中，中央平台团队可能负责管理所需附加服务（如安全和监控服务），并提供集群生命周期管理服务（如修补和升级）。租户管理员可能被限制修改中央管理的服务和其他关键集群信息。
控制平面即服务
在 *集群即服务* 模型的一个变体中，租户集群可能是虚拟集群，其中每个租户都有自己专用的 Kubernetes 控制平面，但共享工作节点资源。与其他形式的虚拟化一样，虚拟集群的用户在虚拟集群和其他 Kubernetes 集群之间看不到显著差异。这有时被称为 控制平面即服务 (CPaaS)。
这种类型的虚拟集群共享工作节点资源和独立于工作负载状态的控制平面组件，例如调度器。其他感知工作负载的控制平面组件（如 API 服务器）是按租户创建的，以允许重叠，并且使用额外的组件来同步和管理每个租户控制平面和底层共享集群资源之间的状态。使用此模型，用户可以管理自己的集群范围资源。
虚拟集群项目实现了此模型，其中 超级集群 由多个 虚拟集群 共享。Cluster API Nested 项目正在扩展此工作以符合 CAPI 模型，允许使用熟悉的 API 资源来预置和管理虚拟集群。
安全注意事项
云原生安全涉及不同的系统层和生命周期阶段，如 CNCF SIG Security 的云原生安全白皮书中所述。如果没有在所有层和阶段实施适当的安全措施，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 Nested 和 多租户基准，以使其更容易预置和管理多租户模型。
如果您对多租户主题感兴趣，或者想分享您的用例，请参加我们即将举行的社区会议，或通过 Kubernetes Slack 上的 wg-multitenancy 频道 联系我们。