1. 租户隔离概述
1.1 多租户概念
多租户（Multi-Tenancy）是一种软件架构模式，其中单个软件实例为多个独立的用户组（租户）提供服务。在 Kubernetes 生态中，租户通常对应一个团队、一个项目或一个业务线，每个租户拥有独立的资源视图、访问权限和操作边界。
核心特征： 租户之间在逻辑上完全隔离，彼此不可见、不可访问，但共享同一套基础设施与控制平面。
| 维度 | 单租户 | 多租户 |
|---|---|---|
| 资源归属 | 所有资源归一个团队 | 资源按租户划分配额 |
| 安全边界 | 无跨租户风险 | 需严格网络与权限隔离 |
| 运维复杂度 | 低 | 高（需隔离策略与审计） |
| 资源利用率 | 可能闲置 | 共享池化，利用率高 |
1.2 Operator 中的租户隔离需求
Operator 作为 Kubernetes 的扩展控制器，负责管理特定应用的生命周期。当 Operator 需要服务多个租户时，隔离需求变得尤为突出：
- 自定义资源（CR）隔离： 不同租户的 CR 实例必须归属各自的命名空间，避免命名冲突与误操作。
- 控制器权限隔离： Operator 的 ServiceAccount 应遵循最小权限原则，仅能操作本租户命名空间内的资源。
- 状态与缓存隔离： Operator 内部维护的缓存（如 Informer）必须按租户划分，防止一个租户的数据泄露给另一个租户。
- 资源配额与优先级： 每个租户的 Operator 工作负载应受 ResourceQuota 和 LimitRange 约束，避免资源抢占。
- 审计与可观测性： 日志、指标和事件必须携带租户标签，支持按租户维度进行故障排查与计费。
常见陷阱： 许多 Operator 开发者在初期只关注功能实现，忽略租户隔离设计，导致后期出现跨租户数据泄露或权限越界事故。隔离设计应作为 Operator 架构的第一优先级。
1.3 隔离的层次模型
Kubernetes 提供了三个层次的隔离能力，Operator 需要在这三个层次上分别实施隔离策略：
- 集群级隔离： 通过 ClusterRole、ClusterRoleBinding 控制全局资源的访问；使用 PriorityClass、RuntimeClass 等集群范围策略区分租户行为。
- 命名空间级隔离： 每个租户独占一个或多个命名空间；通过 NetworkPolicy 限制 Pod 间通信；通过 ResourceQuota 限制总资源消耗。
- 资源级隔离： 在 CRD 定义中通过
scope: Namespaced确保 CR 实例归属命名空间；在 Operator 代码中通过client.InNamespace()限定查询范围。
1.4 隔离策略选择矩阵
不同的 Operator 类型和部署场景，需要选择不同的隔离组合。以下矩阵帮助开发者在设计阶段快速决策：
| 场景 | 推荐隔离层次 | 关键策略 | Operator 改造点 |
|---|---|---|---|
| 单一团队使用 Operator | 命名空间级 | ResourceQuota + Role | 无需改造，默认命名空间隔离 |
| 多个团队共享集群 | 命名空间级 + 资源级 | NetworkPolicy + CR 命名空间校验 | Reconciler 增加命名空间白名单检查 |
| SaaS 平台多租户 | 集群级 + 命名空间级 + 资源级 | ClusterRole 细分 + 租户 CRD 实例隔离 | Operator 内实现租户上下文管理器 |
| Operator 自身多实例部署 | 集群级 | LeaderElection + 租户标签选择器 | 每个 Operator 实例绑定特定租户标签 |
设计建议： 对于大多数 Operator 项目，建议从命名空间级隔离起步，预留资源级隔离的扩展接口。集群级隔离通常只在超大规模多租户场景下启用，且需要额外的审计与治理组件配合。