多租户

概述 某次大促前夜，测试环境的 Pod 集体卡在 Pending。kubectl top nodes 显示节点 CPU 使用率才 35%，内存也只用了不到一半。翻 Deployment YAML，requests 和 limits 设置都合理。问题出在哪？——不是资源不够，是"账本"被算爆了。某个命名空间的 ResourceQuota 已经触顶，后续所有 Pod 创建请求被 admission controller 直接拒绝。 这件事让我重新审视了 K8s 命名空间级资源治理的完整链路。很多人以为设了 LimitRange 就万事大吉，或者觉得 ResourceQuota 只是"给开发组限个额度"的简单操作。实际上，ResourceQuota、LimitRange 和 QoS 三者之间的协同关系，直接决定了多租户集群的资源公平性和稳定性。 本文围绕 4 个生产级决策展开：LimitRange 与 ResourceQuota 必须成对出现、配额维度要覆盖算力+对象+存储三层、用 ScopeSelector 做精细化分流、配额耗尽的告警与自动治理。每个决策都附带了完整可复制的 YAML 模板和真实踩坑数据。如果你正在管理一个多团队共享的 K8s 集群，这些配置能帮你避开大部分资源争抢的坑。 ResourceQuota 和 LimitRange 到底在管什么 先说人话。K8s 的资源管理分两个层次： Pod 级：requests 和 limits，管的是单个容器能用多少资源。调度器根据 requests 决定 Pod 放到哪个节点，运行时根据 limits 做限流和 OOM Kill。这部分在 相关文章：Kubernetes 资源管理：Requests 与 Limits 里有详细讲解。 命名空间级：ResourceQuota 和 LimitRange，管的是整个命名空间能吃多少集群资源。 打个比方。LimitRange 是"采购审批员"——每个容器提交资源申请时，它检查你的 requests/limits 是否在合理范围内，不合理直接驳回。ResourceQuota 是"财务审计员"——它盯着整个命名空间的资源消耗总量，一旦超标，新的 Pod 直接不让创建。...