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