4. 多租户模型设计：租户（Tenant）定义、命名空间（Namespace）与租户映射、租户标签规范与资源配额
多租户模型是构建企业级 Kubernetes 平台的基础。在多租户签名链路网络隔离场景中，租户不仅是资源隔离的边界，更是网络策略签名与信任链的起点。本节将系统阐述租户的定义方式、命名空间与租户的映射关系、标签规范以及资源配额控制策略。
4.1 租户（Tenant）定义
在 Kubernetes 原生体系中，并不存在“租户”这一内置资源对象。因此，我们需要通过组合使用命名空间（Namespace）、标签（Label）、RBAC 以及资源配额（ResourceQuota）来抽象出租户的概念。一个租户通常包含以下核心属性：
| 属性 | 说明 | 示例值 |
|---|---|---|
| 租户 ID | 全局唯一标识，用于签名链路中的主体识别 | tenant-ai-platform |
| 租户名称 | 可读性名称，用于运维与审计 | AI 平台团队 |
| 租户类型 | 标识租户的隔离级别或业务属性 | production / sandbox |
| 签名公钥指纹 | 用于验证该租户下网络策略签名的公钥摘要 | SHA256:abc123... |
| 所属组织 | 上层组织架构归属 | org-data |
4.2 命名空间（Namespace）与租户映射
命名空间是 Kubernetes 中资源隔离的基本单位。在多租户模型中，一个租户可以拥有一个或多个命名空间。映射关系通常采用 1:N 模式，即一个租户对应多个命名空间，用于区分环境（如 dev、staging、prod）或业务模块。
映射策略分为以下三种常见模式：
- 严格一对一映射： 每个租户仅拥有一个命名空间，管理简单，但缺乏环境隔离能力。
- 标签驱动映射： 通过命名空间上的标签
tenant-id来标识归属，一个租户可跨多个命名空间。 - 层级命名映射： 命名空间名称包含租户前缀，例如
tenant-ai-platform-prod，通过命名规则实现映射。
在签名链路网络隔离场景中，推荐使用 标签驱动映射，因为它能够与网络策略的标签选择器无缝集成，且不依赖命名空间名称的解析。
tenant-ai-platform 拥有三个命名空间，分别对应开发、预发布和生产环境。
apiVersion: v1
kind: Namespace
metadata:
name: ai-platform-dev
labels:
tenant-id: tenant-ai-platform
environment: dev
---
apiVersion: v1
kind: Namespace
metadata:
name: ai-platform-staging
labels:
tenant-id: tenant-ai-platform
environment: staging
---
apiVersion: v1
kind: Namespace
metadata:
name: ai-platform-prod
labels:
tenant-id: tenant-ai-platform
environment: production4.3 租户标签规范
统一的标签规范是实现自动化策略签名、审计与隔离的关键。我们定义以下强制标签体系，所有与租户相关的资源（命名空间、Pod、Service、NetworkPolicy）均需携带：
| 标签键 | 标签值规范 | 作用范围 | 说明 |
|---|---|---|---|
tenant-id |
小写字母、数字、连字符，最长 63 字符 | 命名空间、Pod、Service、NetworkPolicy | 标识资源所属租户，签名链路中的主体标识 |
tenant-tier |
production / staging / development / sandbox |
命名空间、Pod | 标识环境层级，用于网络策略的层级隔离 |
tenant-org |
组织编码，如 org-data、org-infra |
命名空间 | 用于跨租户的审计与资源统计 |
policy-signature |
签名指纹，由策略控制器自动注入 | NetworkPolicy | 存储签名信息，用于验证策略的合法性与完整性 |
tenant-id 是签名链路的核心标识。任何网络策略在签名时，必须校验其 tenant-id 标签与签名者身份是否一致。禁止跨租户的 Pod 通过标签选择器直接访问，除非显式声明了跨租户策略并经过二次签名。
4.4 资源配额（ResourceQuota）与租户边界
资源配额是防止单个租户过度消耗集群资源的关键机制。每个租户的命名空间应绑定独立的 ResourceQuota 对象，确保租户间的资源公平性。
以下是为租户 tenant-ai-platform 的生产命名空间配置的资源配额示例：
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota-ai-platform-prod
namespace: ai-platform-prod
labels:
tenant-id: tenant-ai-platform
environment: production
spec:
hard:
requests.cpu: "40"
requests.memory: "80Gi"
limits.cpu: "80"
limits.memory: "160Gi"
persistentvolumeclaims: "10"
pods: "50"
services: "20"
configmaps: "30"
secrets: "30"除了 ResourceQuota，还可以结合 LimitRange 设置每个 Pod 或容器的默认资源请求与限制，防止单个 Pod 异常占用。
4.5 多租户模型架构总览
下图展示了租户、命名空间、标签与资源配额之间的整体关系：
4.6 租户生命周期与配额管理流程
为了保障多租户模型的可持续运维，建议建立标准化的租户生命周期管理流程。下图展示了从租户申请到配额回收的完整步骤：
4.7 租户隔离的边界条件
在多租户签名链路网络隔离中，除了资源配额，还需要关注以下隔离边界：
- 网络隔离边界： 默认禁止跨租户 Pod 通信，除非存在显式的、经过签名的 NetworkPolicy 允许规则。
- RBAC 隔离边界： 租户管理员只能管理本租户命名空间内的资源，不能查看或修改其他租户的策略。
- 签名密钥隔离： 每个租户拥有独立的签名密钥对，密钥的私钥部分仅由该租户的授权管理员持有。
- 审计日志隔离： 审计系统应支持按 tenant-id 标签过滤日志，确保租户只能查询到本租户的操作记录。