回答“如何为多租户配置 Kubernetes？”的问题时，架构师必须首先了解可用的概念边界和隔离模型。 AKS 中的多租户是在共享 Kubernetes 群集上运行多个独立工作负载（属于不同团队、应用程序或客户）的做法。 本文详细介绍了 Azure Kubernetes 服务 (AKS) 上多租户的核心概念和体系结构模型。
Tip
AKS 中的三种多租户模型是什么？ AKS 多租户采用一种隔离谱系，其中包括三种常见模型：命名空间隔离、节点池隔离以及每个租户一个集群。 命名空间隔离最适合受信任的内部团队，并且成本效率最高；节点池隔离以适中的开销提供更强的工作负载隔离；而每租户一个集群则为不受信任或监管要求严格的场景提供最强的隔离。
有关分步实施说明和 YAML 清单，请参阅配套指南：AKS 中多租户的最佳实践。
为什么在 AKS 上采用多租户架构？
多租户允许多个团队、应用程序或客户共享单个 Kubernetes 群集。 在 AKS 上采用多租户的首要原因是 成本效益 和 规模化运营。
为每个应用程序或团队运行专用集群会导致严重的资源碎片化、闲置的计算能力以及成倍增加的控制平面开销。 通过将工作负荷合并到多租户群集中，组织将资源利用率最大化并减少云支出。 在运维层面，多租户减少了集群规模，这意味着平台团队需要打补丁、升级、监控和实施安全防护的集群更少，从而简化了生命周期管理。
软和硬多租户之间的区别是什么？
Kubernetes 本质上不是多租户系统。 若要实现多租户，必须根据租户之间的信任级别设计“软”或“硬”隔离模型。
Kubernetes 中软多租户和硬多租户之间的区别主要在于信任模型以及由此产生的隔离要求。 软多租户以受信任的内部租户为前提，侧重于通过命名空间、RBAC 和配额等逻辑控制措施来防止意外干扰。 严格多租户假定租户之间仅存在低信任或零信任关系，因此需要更强的隔离控制，以降低恶意访问、横向移动和数据泄露的风险。
| 建模 | 信任级别 | 目标 | 用例 | 示例方案 |
|---|---|---|---|---|
| 软隔离多租户 | 内部租户之间的高信任 | 防止意外干扰、资源不足和配置冲突 | 团队共享基础结构的内部平台环境 | 一个组织中的多个产品团队共享用于开发/测试和内部服务的 AKS 群集 |
| 硬多租户 | 租户之间的低信任或零信任 | 防止恶意攻击、横向移动和数据外泄 | 外部客户托管和管控工作负载 | 托管特定于客户的工作负荷的 SaaS 提供商，其中租户隔离是一项安全性和符合性要求 |
隔离范围
AKS 上的多租户不是二进制选择;它存在于光谱上。 在跨范围移动时，隔离会增加，但运营复杂性和成本也随之增加。 此光谱构成了多租户群集设计的组织脊椎：
- 命名空间隔离（逻辑）：租户共享相同的节点池和控制平面，但以逻辑方式由 Kubernetes 命名空间分隔。 这是软性多租户架构的基础。
- 节点池隔离（物理计算）：租户共享控制平面，但分配了专用工作器节点。 这改善了工作负载隔离，并缓解了“噪声邻居”问题，但由于控制平面和集群级组件仍然是共享的，因此这并非完整的租户隔离。
- 每个租户一个群集（完全物理隔离）：每个租户都拥有各自独立的 AKS 控制平面和数据平面，实现完全隔离。 这是硬性多租户的终极形态，通过绕开 Kubernetes 层级的共享机制，转而采用 Azure 层级的隔离。
多租户的 AKS 基元
AKS 提供一组原生和 Azure 集成的原语，以实现不同级别的隔离。
- Microsoft Entra ID：提供集中标识和访问管理，用于对用户和自动化系统进行身份验证，以便向 Kubernetes API 进行身份验证。
- Azure RBAC：将Microsoft Entra ID标识映射到 Kubernetes 权限，确保租户只能访问其授权资源。
- 托管命名空间：在群集中提供逻辑边界来对租户资源进行分组、应用配额和范围访问。
- Azure Policy/Gatekeeper：在整个群集中强制实施集中式合规性和治理规则，以防止租户部署不安全或未经授权的配置。
- Azure CNI：为 AKS 网络提供本机虚拟网络集成，并支持使用网络策略控制进行租户流量分段。 Pod IP 行为取决于所选 CNI 模式（例如 覆盖 或 Pod 子网）。
- Azure容器网络服务 （ACNS） Cilium L7：提供高性能、基于 eBPF 的网络策略和第 7 层流量筛选，以严格隔离租户网络流量。
- 工作负荷标识：允许单个 Pod 使用联合标识安全地向外部Azure服务进行身份验证，从而消除租户之间的共享机密。
跨平面映射隔离层
若要构建安全的多租户体系结构，必须跨群集环境的三个不同平面应用 AKS 基元。
| 飞机 | Description | 应用的 AKS 基元 |
|---|---|---|
| 控制平面 | 保护对 Kubernetes API 服务器和逻辑边界的访问。 | Microsoft Entra ID、Azure RBAC、托管命名空间 |
| 数据平面 | 保护网络流量、计算执行和节点级边界。 | Azure CNI、ACNS Cilium L7、节点池 |
| 资源平面 | 控制计算消耗、外部访问和配置符合性。 | Azure Policy，工作负载标识 |
应选择哪种隔离模型？
使用以下矩阵来确定隔离范围上的哪个点最符合组织要求。
| 隔离模型 | 安全级别 | 成本效益 | 操作复杂性 | 最适合 |
|---|---|---|---|---|
| 每个租户的命名空间 | 低到中等（逻辑） | 高（最大程度共享） | 低（仅需管理单个集群） | 内部团队、开发/测试环境、软性多租户。 |
| 每个租户一个节点池 | 高（计算隔离型） | 中等（共享控制平面） | 中等（管理污点/容忍度） | 内部和外部工作负载在共享控制平面的同时需要更强的计算隔离；不适用于敌对的零信任多租户环境。 |
| 每个租户的群集数 | 最高 （物理） | 低（高开销） | 高 （需要车队管理） | 敌对多租户环境、外部企业客户、零信任。 |
何时使用每个模型
- 当租户属于内部或受信任租户、优先考虑成本效益，且逻辑隔离控制已足够时，可采用每个租户一个命名空间的方式。
- 当您需要更强的计算隔离并减少“嘈杂邻居”影响，同时仍共享同一个 AKS 控制平面时，请使用每租户一个节点池。
- 当租户不受信任、法规边界严格或风险模型需要最少的共享基础结构时，请使用每租户群集。
后续步骤
现在你已经了解了多租户的概念模型和原语，请继续阅读实现指南，将这些概念应用到你的集群中。
底线
- Azure Kubernetes 服务 (AKS)中的多租户做法是在共享 Kubernetes 基础结构上运行多个独立租户工作负荷，以降低成本并简化操作。
- 每个租户一个命名空间是受信任的内部工作负载中成本效益最高的模型，因为它在实施逻辑隔离的同时，最大限度地实现了基础设施共享。
- 每个租户一个节点池可提升计算隔离和“嘈杂邻居”控制，但仍会共享 AKS 控制平面和其他群集级组件。
- 每个租户一个集群可为零信任和高度监管场景提供最强的租户隔离，但成本更高，运维开销也更大。