故障隔离的关键是让单租户故障不影响其他租户，需通过基础设施层物理/虚拟硬隔离、运行时层容器命名空间与cgroups约束、数据库层Resource Group与读写分离、网络层Service Mesh管控、存储层独立PV与物理分区实现全链路资源隔离。
故障隔离不是靠“一刀切”关掉某个租户，而是让一个租户出问题时，其他租户完全感知不到——就像同一栋楼里某户跳闸，不影响隔壁的空调和电梯。要实现资源层面的彻底隔离，关键在架构分层控制，而不是只靠数据库或容器单点设限。
基础设施层：物理或虚拟资源硬隔离
这是最底层、也最有效的防线。采用虚拟机（KVM/VMware）或轻量级虚拟化（如Firecracker）为每个租户分配独占的CPU核、内存页和I/O设备。即使租户A触发内核panic或OOM Killer，宿主机也不会波及租户B的进程空间。云厂商的“专属主机”或Kubernetes的“节点亲和+污点容忍”组合，也能将高敏感租户锁定在物理隔离的节点池中。
运行时层：容器与命名空间的细粒度约束
在共享节点上运行多租户服务时，必须启用完整的Linux命名空间（PID、NET、MNT、USER等）并配合cgroups v2做硬性配额。例如：
- CPU：用cpu.max限制租户容器可使用的最大CPU时间片，避免“CPU霸占”
- 内存：设置memory.high为软限、memory.max为硬限，超限时直接OOM而非抢占其他容器内存
- IO：通过io.weight或io.max对块设备读写带宽分级限流，防止单租户刷盘拖垮整个节点存储响应
数据库层：从连接到执行的全链路隔离
共享数据库实例不等于共享执行环境。KingbaseES V9的Resource Group机制可为每个租户绑定独立资源组，不仅限制连接数、活跃会话数，还能对SQL执行施加CPU时间片配额和内存上限。更进一步，结合逻辑复制+只读副本，把报表类租户路由到专用只读集群，交易类租户走主库+读写分离代理，天然切断故障传播路径。
网络与存储：避免隐性共享通道
很多故障蔓延源于被忽略的共享面：
- 网络：禁用默认命名空间互通，强制租户间通信走Service Mesh（如Istio），通过策略限速、熔断、重试阈值控制横向影响
- 存储：不共用NFS或Ceph RBD镜像；每个租户挂载独立PV，且后端存储池按租户划分物理SSD分区或LUN，杜绝IO争抢导致的延迟毛刺
不复杂但容易忽略。真正彻底的故障隔离，是让每个租户在资源视角下“以为自己独占整套系统”。
