关键在于计算、网络、存储三类隔离机制协同生效：网络用独立bridge网桥实现硬隔离，计算靠cgroups限制cpu/内存/i/o配额，存储通过独立pv、非root运行及安全上下文加固，辅以租户标签监控与自动熔断。
同一节点上跑多个租户的容器，关键不是“能不能共存”，而是“会不会互相拖垮”。真正起作用的不是单一技术，而是计算、网络、存储三类隔离机制协同生效——缺一不可。
网络层面：用命名空间+自定义网桥硬隔离
默认的 docker0 网桥会让所有容器互通，这等于把不同租户关进同一间没门的屋子。必须改用独立 bridge 网络：
- 为每个租户创建专属网络：
docker network create tenant-a-net - 启动容器时显式指定：
docker run --network tenant-a-net ... - 两个租户网络之间默认无路由、无 DNS、无 IP 可达性，连 ping 都不通
- 如需有限互通（比如监控服务访问各租户），再通过 iptables 或 NetworkPolicy 显式放行，不默认开通
计算资源：靠 cgroups 限制 CPU 和内存上限
容器共享宿主机内核，一个租户跑满 CPU 或吃光内存，其他租户立刻卡顿。必须设硬性配额：
- 启动时限制 CPU 使用率：
--cpus=1.5或按权重分配：--cpu-shares=512 - 限制内存上限并启用 OOM 控制：
--memory=2g --memory-swap=2g - 对 I/O 密集型租户加磁盘限速：
--device-read-bps /dev/sda:10mb --device-write-bps /dev/sda:5mb - 在 Kubernetes 中，则通过 ResourceQuota + LimitRange 强制所有命名空间遵守配额
存储与运行时：卷隔离 + 安全上下文加固
数据混放或权限过大，容易引发越权读写或横向逃逸：
- 每个租户使用独立的 PersistentVolume 或绑定挂载路径，禁止跨租户共享 hostPath
- 容器以非 root 用户运行：
--user 1001:1001，并在 Dockerfile 中用USER指令固化 - 禁用危险能力：
--cap-drop=ALL --security-opt=no-new-privileges - 启用只读根文件系统：
--read-only，临时写入走 tmpfs 或明确声明的 volume
最后一道防线：租户感知的监控与熔断
隔离机制防得住正常行为，但挡不住异常负载。需要实时感知和干预：
- 采集带租户标签的指标（如 Prometheus 的
tenant_idlabel），识别哪个租户触发了 CPU >90% 或内存持续增长 - 配置自动限流：当某租户容器连续 3 分钟内存使用超配额 120%，自动触发
docker update --memory=1.5g - 数据库等有状态组件额外启用租户级查询熔断（如 MySQL 8.0 的 RESOURCE GROUP + query timeout）
- 日志统一打标，确保审计时能准确追溯到具体租户行为，而非“某个容器”
