ResourceQuota是命名空间级资源“保险丝”，在API Server准入阶段校验CPU/内存请求与限制、Pod及对象数量，防止失控；必须配合LimitRange设置默认值和范围才生效，且需按环境差异化配置并验证USED实时性。
故障隔离的关键不是等出问题再救火，而是提前用资源配额把命名空间“圈住”。Kubernetes 的 ResourceQuota 不是性能优化工具，而是防止一个命名空间拖垮整个集群的保险丝。它在 Pod 创建的最早阶段（API Server 准入控制）就做校验，而不是等容器跑起来吃光内存才报警。
明确要限制哪几类资源
ResourceQuota 支持三类核心约束，选对才能真正隔离故障：
-
CPU 和内存总量：用
requests.cpu、requests.memory控制调度资源底限；用limits.cpu、limits.memory控制资源使用天花板 -
Pod 数量上限：用
pods字段防止单个命名空间起几百个 Pod 压垮 API Server 或节点 kubelet -
其他对象数量：比如
services、configmaps、secrets，避免元数据爆炸影响 etcd 性能
必须搭配 LimitRange 才能生效
只设 ResourceQuota 不够。如果用户创建 Pod 时没写 resources.requests 和 limits，配额检查会跳过——因为没东西可累加。所以得同步配置 LimitRange：
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 为容器设置默认值：
default（limits）、defaultRequest（requests） - 设定允许范围：
min和max，防止有人写requests.memory: "1Ki"或limits.memory: "100Gi" - 示例：LimitRange 要求每个容器至少申请 256Mi 内存、最多限制 2Gi，这样 ResourceQuota 统计才有意义
配额策略要分环境落地
不同环境容忍度不同，配额不能一刀切：
-
开发/测试环境：侧重防误操作，比如限制
pods: "5"+requests.memory: "2Gi"，避免脚本错配导致集群雪崩 -
生产环境：按服务等级协议（SLA）分配，比如核心服务命名空间给
requests.memory: "16Gi"，边缘服务只给"4Gi" -
CI/CD 命名空间：限制
jobs和pod数量，防止流水线并发构建撑爆资源
验证和排障要点
配额不是设完就完事，得确认它真在起作用：
- 查状态：
kubectl get resourcequota -n <ns> -o wide看USED是否实时更新 - 模拟超限：
kubectl run test-pod --image=nginx --replicas=10 -n <ns>，观察是否报exceeded quota - 常见失败原因：没配 LimitRange、Pod YAML 里写了
resources但值为0、配额对象命名空间写错、用了旧版字段如memory而非requests.memory
