1.1 多租户隔离概述
1.1.1 什么是多租户
多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例能够同时为多个独立用户群体（租户）提供服务，且每个租户在逻辑上彼此隔离。在容器化环境中，每个租户可以是一个团队、一个项目、一个客户或一个业务线，它们共享同一套 Docker 主机或集群资源，但拥有独立的镜像、容器、网络和存储空间。
核心特征： 资源共享 + 逻辑隔离。租户之间“看不见、摸不着、不影响”，但底层基础设施是共用的。
| 维度 | 单租户架构 | 多租户架构 |
|---|---|---|
| 资源利用率 | 低（资源独占） | 高（资源共享） |
| 运维成本 | 高（每租户独立部署） | 低（统一管理） |
| 隔离强度 | 物理隔离（最强） | 逻辑隔离（可控） |
| 扩展灵活性 | 差（需重复建设） | 好（按需分配） |
1.1.2 为什么需要隔离
没有隔离的多租户环境如同“合租公寓不设房门”——任何租户的失误或恶意行为都可能波及全局。隔离的必要性体现在以下四个关键层面：
- 安全性： 防止租户 A 通过容器逃逸、网络嗅探或镜像篡改访问租户 B 的数据。
- 稳定性： 避免某个租户的容器耗尽 CPU/内存/磁盘 IO，导致其他租户的服务降级或中断。
- 合规性： 满足 GDPR、HIPAA、等保等法规对数据隔离和访问审计的硬性要求。
- 可审计性： 每个租户的操作行为可追溯、可分离，便于故障定责和成本核算。
常见事故场景： 某团队在共享 Docker 主机上运行了一个未限制内存的 Java 容器，触发 OOM Killer，导致同一主机上其他 5 个租户的数据库容器被内核强制杀死——这就是缺乏资源隔离的典型代价。
1.1.3 Docker 在隔离中的角色
Docker 本身并非为多租户而生，但它提供的内核级虚拟化机制构成了多租户隔离的基石。Docker 通过以下技术栈实现“轻量级隔离”：
- Namespace（命名空间）： 隔离进程、网络、挂载点、用户 ID、主机名等视图，让每个容器“以为”自己独占操作系统。
- Cgroups（控制组）： 限制和监控容器的 CPU、内存、磁盘 IO、网络带宽等资源使用量，防止“吵闹邻居”效应。
- UnionFS（联合文件系统）： 实现镜像分层与写时复制，使不同租户可以共享基础层镜像，同时拥有独立的可写层。
- 镜像仓库访问控制： 通过 Registry 的认证与授权机制，限制租户只能拉取/推送自己命名空间下的镜像。
1.1.4 隔离的层次与挑战
Docker 提供的隔离并非“银弹”，在实际生产环境中，多租户隔离需要从多个层次综合设计：
| 隔离层次 | Docker 原生能力 | 常见挑战 |
|---|---|---|
| 镜像隔离 | 镜像命名空间 + 仓库权限 | 基础镜像共享导致漏洞扩散；镜像大小膨胀 |
| 容器隔离 | Namespace + Cgroups | 内核漏洞可导致逃逸；资源争抢难以完全避免 |
| 网络隔离 | 自定义网络 + 网络策略 | 跨租户网络通信配置复杂；DNS 解析冲突 |
| 存储隔离 | 数据卷 + 挂载命名空间 | 共享存储卷的权限控制；磁盘 IO 隔离不足 |
| 安全隔离 | Seccomp / AppArmor / Capabilities | 安全策略维护成本高；兼容性问题 |
实战建议： 不要依赖单一隔离机制。推荐采用“纵深防御”策略：镜像层做访问控制 + 容器层做资源限制 + 网络层做策略隔离 + 主机层做内核安全加固。本课程后续章节将逐一拆解这些技术的落地方法。