故障隔离在多租户环境中核心是限制单租户问题影响范围，kubernetes通过命名空间构建逻辑故障域，配合resourcequota强制限制cpu、内存、pod数等资源上限，再叠加limitrange和networkpolicy可实现资源、配置与网络的三层隔离。

故障隔离在多租户环境中，核心是让一个租户的问题（如资源耗尽、配置错误、异常流量）不波及其它租户。Kubernetes 命名空间配合资源配额（ResourceQuota）是实现这一目标最直接、最轻量的手段——它不依赖网络插件或额外组件，开箱即用。

命名空间作为故障边界

命名空间本身不提供网络或进程级隔离，但它构成了逻辑故障域：一个命名空间内的 Pod 崩溃、OOMKilled、无限重启，不会直接影响其他命名空间的调度和运行。Kubernetes 调度器、控制器管理器、API Server 都以命名空间为粒度做资源归属判断和状态维护。

例如，某租户误部署了一个内存泄漏的 Deployment，其 Pod 持续申请内存。若该租户未设配额，它可能挤占节点资源，导致同节点上其他租户的 Pod 被驱逐；而一旦绑定命名空间，问题就被限定在该命名空间内部，便于快速定位和处置。

资源配额强制限制资源消耗上限

仅靠命名空间不够——它不阻止租户无节制创建资源。ResourceQuota 是关键补丁，它在命名空间级别设置硬性上限，从源头防止“噪声邻居”效应：

• CPU 和内存请求/限制总量：如 requests.cpu: "4" 和 limits.memory: 16Gi，确保该租户所有 Pod 的资源总和不会突破阈值
• 对象数量上限：如 pods: "20"、services: "10"，避免因误操作或脚本失控导致海量对象堆积，拖慢 API Server
• 存储类资源约束：如 persistentvolumeclaims: "5"，防止 PVC 泛滥占用底层存储配额

注意：启用 ResourceQuota 后，该命名空间内新建 Pod 必须显式声明 resources.requests 和 resources.limits，否则会被拒绝——这倒逼租户规范资源配置，也避免了“默认不限制”带来的隐性风险。

组合使用提升隔离鲁棒性

单独用命名空间或单独用配额都存在短板。二者结合才能形成有效故障隔离链：

• 命名空间 + ResourceQuota → 防止资源过载引发的跨租户干扰（如 OOM 驱逐、API Server 延迟升高）
• 再叠加 LimitRange → 为该命名空间自动注入默认 limits/requests，降低用户配置门槛，避免漏设
• 再叠加 NetworkPolicy → 禁止跨命名空间通信，阻断横向攻击路径，让故障真正“出不去”

比如生产环境租户 tenant-prod 配置了 CPU 请求上限 8 核、Pod 数上限 50，并禁止访问 tenant-dev 命名空间的服务。即使其某应用突发流量打满自身配额，也不会抢走开发环境资源，也无法扫描或调用开发环境服务。

实际运维建议

要让这套机制真正起效，需注意几个实操细节：

• 每个租户独占一个命名空间，不混用；命名空间名称带租户标识（如 tenant-001），标签统一加 tenant: "001"，方便审计和策略匹配
• ResourceQuota 的数值不能拍脑袋定——应基于历史监控数据（如 Prometheus 中过去 7 天的 CPU/Mem P95 使用峰值）上浮 20%～30% 设置
• 定期检查配额使用率：kubectl describe quota -n tenant-001，对长期接近 90% 的租户主动沟通扩容或优化
• 删除命名空间前确认无残留外部依赖（如跨 ns 的 ServiceEntry、IngressRoute），避免误删引发连锁故障