1. 课程导论：租户隔离的定义、演进驱动力、蓝图与准入控制的核心价值
1.1 租户隔离的定义与本质
在云原生架构中，租户隔离是指通过计算、网络、存储、身份与数据等多维度的资源与权限边界划分，确保不同租户（团队、业务线、外部客户）在共享基础设施上运行时，彼此之间互不感知、互不干扰、互不越权。隔离的本质是故障域与安全域的收敛。
| 隔离维度 | 核心目标 | 典型实现 |
|---|---|---|
| 计算隔离 | 防止资源争抢与噪声干扰 | Kubernetes Namespace + ResourceQuota + LimitRange |
| 网络隔离 | 禁止跨租户非法流量 | NetworkPolicy、Cilium、服务网格 mTLS |
| 存储隔离 | 数据不可跨租户访问 | PVC 绑定、存储类隔离、加密卷 |
| 身份隔离 | 租户间 RBAC 与审计独立 | OIDC、RBAC、ServiceAccount 映射 |
| 数据隔离 | 数据库/缓存/对象存储按租户分片 | Schema 隔离、Bucket 隔离、加密密钥分离 |
关键认知：租户隔离不是“一刀切”的物理隔离，而是基于风险等级与合规要求，在共享与独占之间选择最优的隔离策略组合。
1.2 演进驱动力：从单体到多租户云原生
租户隔离的演进并非技术自驱，而是由以下四大外部压力共同推动：
- 业务规模化：从单一产品扩展到多条产品线、多个客户环境，必须通过隔离来降低爆炸半径。
- 合规与监管：GDPR、SOC2、PCI-DSS 等标准要求租户数据在存储、传输、审计层面严格分离。
- 成本效率：物理隔离成本过高，云原生技术使软隔离在性能与安全之间取得平衡。
- 运维自治：每个租户需要独立的发布节奏、监控告警、配置管理，隔离是自治的前提。
1.3 租户隔离蓝图：分层架构总览
一个完整的租户隔离蓝图，应当覆盖从基础设施到应用层的五个层次。每一层解决不同的隔离问题，且层与层之间通过统一的准入控制策略串联。
| 层次 | 隔离对象 | 关键技术 | 故障影响范围 |
|---|---|---|---|
| L1 基础设施 | 物理机、虚拟化、网络设备 | VPC、子网、安全组、裸金属 | 物理故障 → 整个租户 |
| L2 容器编排 | Pod、Namespace、节点 | K8s Namespace、NodeSelector、Taint/Toleration | 节点故障 → 部分工作负载 |
| L3 服务网格 | 服务间通信、流量策略 | Istio AuthorizationPolicy、mTLS、Sidecar | 服务故障 → 有限下游 |
| L4 数据与存储 | 数据库、缓存、对象存储 | Schema 隔离、Bucket 策略、加密密钥 | 数据泄露 → 合规风险 |
| L5 身份与审计 | 用户、角色、操作日志 | RBAC、OIDC、审计日志分片 | 权限滥用 → 全租户风险 |
蓝图设计原则：每一层都应当提供“默认拒绝”的基线策略，上层可以依赖下层的隔离能力，但不能假设下层一定安全。准入控制是贯穿五层的统一策略执行点。
1.4 准入控制：隔离蓝图的“守门人”
准入控制（Admission Control）是 Kubernetes 及云原生体系中，在资源创建、更新、删除操作持久化之前，拦截请求并执行策略校验的机制。它在租户隔离蓝图中的核心价值体现在三个方面：
- 策略前置：在资源进入 etcd 之前，拒绝违反隔离策略的请求，避免“事后补救”。
- 统一执行点：所有租户的操作都经过同一个准入控制链，确保策略一致性，消除配置漂移。
- 可审计：每一次准入决策都可以记录为审计事件，为合规提供证据链。
1.5 核心价值总结
常见误区：很多团队将租户隔离等同于“创建多个 Namespace”，忽略了网络策略、存储隔离、身份映射和准入控制。这种“半隔离”状态在故障发生时，往往比无隔离更危险——因为它制造了安全的假象。
本课程将围绕以下主线展开：
- 蓝图设计：如何根据业务场景选择隔离粒度，构建五层隔离架构。
- 准入控制实现：从原生 Admission Webhook 到 OPA/Kyverno 策略引擎的实战配置。
- 持续演进：隔离策略如何随架构演进（从单体到微服务、从单集群到多集群）保持有效。
通过本课程，你将掌握一套可落地、可审计、可演进的租户隔离方法论，以及与之配套的准入控制设计模式。