问命名空间 ResourceQuota 用满后 HPA 扩不出副本，容量预警应该做在哪一层？

在给测试集群设计多团队共享命名空间的资源治理方案，遇到一个分层设计上的取舍，想听听有落地的同学怎么做。 可复现的最小配置（数值是示例）： ```yaml apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources namespace: team-a spec: hard: requests.cpu: "8" requests.memory: 16Gi pods: "40" --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web namespace: team-a spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 ``` 我的理解是：HPA 只按 `实际用量 / requests.cpu` 算期望副本数，并不知道 ResourceQuota 还剩多少；一旦 `pods` 或 `requests.cpu` 的 Hard 用满，`desiredReplicas` 会一直大于 `currentReplicas`，但 ReplicaSet 建 Pod 时被 admission 拒绝，表现为「HPA 想扩、扩不出来」。此时 `kubectl describe hpa` 不一定直接给出配额原因，需要再去翻 ReplicaSet 的事件。 想请教三点： 1. **预警放哪一层最有效**：是在 Prometheus 里用 `kube_resourcequota{type="used"}` / `{type="hard"}` 算使用率做分级告警，还是用 `kube_horizontalpodautoscaler_status_desired_replicas != current_replicas` 持续时长来兜底，或者干脆在准入层加一个校验/策略（如 Gatekeeper、Kyverno）提前拦？三者各自的盲区是什么？ 2. **maxReplicas 怎么和配额联动**：是人工按「剩余 pods 配额 / 单副本 requests」算一个静态上限，还是有比较稳的自动同步做法？如果同一命名空间跑多个带 HPA 的 Deployment，静态分配很容易互相挤占。 3. **配额该不该包含 limits 项**：包含之后所有 Pod 必须显式写 limits（或靠 LimitRange 注入），治理更严格但灰度期报错更多；只包含 requests 更平滑，但会失去对突发上限的约束。生产里一般怎么取舍？ 不需要泛泛谈"做好监控"，希望能给具体的告警表达式、判定阈值思路，或者是踩过坑之后调整过的分层方案。谢谢。