📚 课程目录第4章多租户模型与资源隔离

4、多租户模型与资源隔离：Namespace与ResourceQuota、租户标识与标签策略、租户数据存储路径

在多租户 Kubernetes 集群中，租户隔离是保障安全性与稳定性的基石。本章聚焦于 Namespace、ResourceQuota、租户标签策略 以及 数据存储路径 四个核心维度，构建一套可落地、可审计的多租户模型。该模型在 etcd 故障场景下，能够快速定位租户边界、隔离故障域，并支持迁移恢复操作。

4.1 租户模型设计原则

多租户模型遵循以下三条核心原则：

边界清晰：每个租户拥有独立的 Namespace 集合，资源配额、网络策略、RBAC 权限均以 Namespace 为最小隔离单元。
可观测性：通过统一的标签体系，在集群层面快速聚合、筛选、审计租户资源。
故障域隔离：租户数据存储路径与 etcd 键空间结构对应，确保在 etcd 局部故障时，能够按租户粒度执行数据导出、恢复与迁移。

实践建议：在集群规划阶段，将租户模型与 etcd 键空间前缀设计对齐。例如，使用 /registry/namespaces/<tenant-id>/* 作为租户资源存储路径，便于故障时按前缀批量操作。

4.2 Namespace 与 ResourceQuota

Namespace 是 Kubernetes 多租户隔离的基本单位。每个租户至少拥有一个 Namespace，大型租户可按环境（dev、staging、prod）或业务模块划分多个 Namespace。

ResourceQuota 用于限制 Namespace 级别的资源消耗总量，防止单个租户过度占用集群资源。下表列出典型 ResourceQuota 配置项：

资源类型	配置示例	说明
CPU 请求	`requests.cpu: "10"`	该 Namespace 所有 Pod CPU 请求总和上限
内存请求	`requests.memory: "20Gi"`	该 Namespace 所有 Pod 内存请求总和上限
CPU 限制	`limits.cpu: "20"`	该 Namespace 所有 Pod CPU 限制总和上限
内存限制	`limits.memory: "40Gi"`	该 Namespace 所有 Pod 内存限制总和上限
Pod 数量	`count/pods: "50"`	该 Namespace 允许的最大 Pod 数量
PVC 数量	`count/persistentvolumeclaims: "20"`	该 Namespace 允许的最大 PVC 数量
Service 数量	`count/services: "30"`	该 Namespace 允许的最大 Service 数量

以下是一个完整的 ResourceQuota YAML 示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-alpha-prod
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    count/pods: "50"
    count/persistentvolumeclaims: "20"
    count/services: "30"
    count/secrets: "50"
    count/configmaps: "50"

注意：ResourceQuota 仅限制资源总量上限，不保证资源预留。若需保障租户最小资源，需配合 LimitRange 或 PriorityClass 使用。在 etcd 故障恢复场景中，ResourceQuota 配置应作为租户元数据的一部分，随 Namespace 一起备份。

4.3 租户标识与标签策略

统一的标签策略是实现租户资源可观测性与自动化运维的基础。推荐使用以下标签体系：

标签键	标签值示例	用途
`tenant.id`	`alpha`, `beta`, `gamma`	租户唯一标识，用于资源聚合与筛选
`tenant.environment`	`dev`, `staging`, `prod`	租户环境分类，用于环境级隔离
`tenant.tier`	`gold`, `silver`, `bronze`	租户服务等级，用于资源调度与优先级控制
`tenant.owner`	`team-a`, `team-b`	租户所属团队，用于告警通知与审计

标签策略实施要求：

强制注入：通过准入控制器（如 OPA/Gatekeeper 或 Kyverno）强制所有 Namespace 及工作负载资源携带 tenant.id 标签。
不可变更：租户创建后，tenant.id 标签禁止修改，确保审计链路完整性。
继承机制：Namespace 级别的标签自动继承到其下的 Pod、Service、PVC 等子资源，减少重复标注。

以下 SVG 展示了租户标签在 Namespace 与工作负载之间的继承关系：

4.4 租户数据存储路径

在 etcd 中，Kubernetes 资源以键值对形式存储，键路径遵循 /registry/<resource_type>/<namespace>/<name> 的格式。多租户场景下，租户数据存储路径设计直接影响故障恢复效率。

典型租户数据存储路径结构如下：

etcd 键前缀	对应资源	租户关联方式
`/registry/namespaces/tenant-alpha-prod`	Namespace 定义	直接包含租户标签
`/registry/pods/tenant-alpha-prod/`	Pod 资源	通过 Namespace 归属关联
`/registry/configmaps/tenant-alpha-prod/`	ConfigMap 资源	通过 Namespace 归属关联
`/registry/secrets/tenant-alpha-prod/`	Secret 资源	通过 Namespace 归属关联
`/registry/persistentvolumeclaims/tenant-alpha-prod/`	PVC 资源	通过 Namespace 归属关联

在 etcd 故障恢复场景中，按租户前缀进行数据导出与恢复的操作示例如下：

# 导出指定租户的所有资源（基于 Namespace 前缀）
etcdctl get /registry/pods/tenant-alpha-prod/ --prefix --keys-only

# 导出租户的完整数据快照（包含所有资源类型）
etcdctl get /registry/ --prefix --keys-only | grep "/tenant-alpha-prod/"

# 恢复时，将导出的租户数据写入目标 etcd 集群
etcdctl put /registry/pods/tenant-alpha-prod/frontend-v1 '{"apiVersion":"v1","kind":"Pod",...}'

    关键设计：租户数据存储路径与 Namespace 名称强绑定。在集群升级或 etcd 迁移前，应确保所有租户 Namespace 名称符合 <tenant-id>-<environment> 的命名规范，以便在故障恢复时通过前缀快速定位租户数据边界。

以下 SVG 展示了 etcd 中多租户数据存储路径的层级结构：

4.5 多租户隔离策略总结

下表汇总了多租户模型中各隔离维度的实现方式与故障恢复关联：

隔离维度	实现方式	故障恢复关联
资源边界	Namespace + ResourceQuota	按 Namespace 导出/恢复 etcd 数据
身份标识	标签策略（tenant.id 等）	通过标签筛选租户资源，验证恢复完整性
数据路径	etcd 键前缀 + Namespace 名称	按前缀批量操作，提升恢复效率
权限控制	RBAC + 网络策略	恢复后需重建 RBAC 绑定与网络策略

演练建议：在 etcd 故障模拟环境中，尝试按租户前缀导出数据，并恢复到一个全新的 etcd 实例。验证恢复后的 Namespace、ResourceQuota、标签及资源对象是否完整一致。该操作应作为多租户迁移恢复演练的标准步骤。