📚 课程目录第3章命名空间配额

3. 命名空间配额：Namespace 级别资源隔离、默认配额与硬性限制

在 Kubernetes 多租户或团队协作场景中，仅靠 Namespace 做逻辑隔离是不够的。如果没有资源配额约束，单个 Namespace 内的 Pod 可能耗尽集群所有 CPU 或内存，导致其他 Namespace 的服务不可用。ResourceQuota 对象正是为此而生——它在 Namespace 级别设置聚合资源上限，实现硬性隔离与公平调度。

3.1 核心概念与隔离模型

ResourceQuota 作用于 Namespace 内所有 Pod 的 资源请求（requests） 和 资源限制（limits） 之和。一旦 Namespace 内累计资源超过配额，Kubernetes 将拒绝创建新的 Pod（即使 Pod 本身未超出 LimitRange）。

维度	作用对象	示例字段	说明
计算资源	Pod 的 requests/limits	`requests.cpu`, `limits.memory`	Namespace 内所有 Pod 的 CPU/Memory 总和上限
存储资源	PVC 的 requests.storage	`requests.storage`, `persistentvolumeclaims`	限制 PVC 总容量和数量
对象数量	K8s 资源实例数	`count/deployments.apps`, `count/services`	限制 Namespace 内 Deployment、Service 等对象个数
扩展资源	自定义资源（如 GPU）	`requests.nvidia.com/gpu`	限制 GPU、FPGA 等特殊硬件总量

  关键隔离原则： ResourceQuota 是 Namespace 级别的聚合硬限制，不关心单个 Pod 的规格。若需限制单个 Pod 的资源范围，必须配合 LimitRange 使用。

3.2 默认配额与硬性限制配置

以下 YAML 展示一个典型的 ResourceQuota 对象，同时设置了计算资源硬限制和对象数量硬限制：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    requests.storage: "50Gi"
    persistentvolumeclaims: "10"
    count/deployments.apps: "5"
    count/services: "10"
    count/secrets: "20"

当 Namespace team-a 内所有 Pod 的 requests.cpu 总和达到 4 核时，任何新的 Pod 创建请求都会被 API Server 拒绝，并返回 403 Forbidden 错误。

3.3 配额生效流程与冲突处理

下图展示了 ResourceQuota 在 Pod 创建阶段的拦截与校验流程：

最佳实践： 建议为每个 Namespace 创建至少一个 ResourceQuota，即使只设置 requests.cpu 和 requests.memory。这可以防止“吵闹邻居”问题，并让团队提前感知资源上限。

3.4 配额查询与监控

管理员和开发者可以通过以下命令查看当前 Namespace 的配额使用情况：

# 查看配额定义
kubectl get resourcequota -n team-a

# 查看配额使用详情（包含当前使用量）
kubectl describe resourcequota team-a-quota -n team-a

# 输出示例（部分字段）：
# Name:            team-a-quota
# Namespace:       team-a
# Resource         Used  Hard
# --------         ---   ---
# requests.cpu     2     4
# requests.memory  4Gi   8Gi
# limits.cpu       3     8
# limits.memory    6Gi   16Gi
# count/deployments.apps  2  5

当 Used 接近 Hard 时，应提前扩容集群或调整配额。若 Used 超过 Hard（通常不会发生，除非手动修改配额），新 Pod 将无法创建。

3.5 多租户配额规划示例

下表展示了一个典型的多团队集群配额分配方案：

Namespace	团队	requests.cpu	requests.memory	limits.cpu	limits.memory	最大 Deployment 数
team-a	支付团队	4	8Gi	8	16Gi	5
team-b	搜索团队	6	16Gi	12	32Gi	8
team-c	日志团队	2	4Gi	4	8Gi	3
system	系统组件	8	16Gi	16	32Gi	10

注意： ResourceQuota 的 hard 值总和不应超过集群总容量。建议预留 20%-30% 的缓冲资源，用于突发扩容或系统组件。同时，不要在 kube-system Namespace 设置过于严格的配额，以免影响核心组件运行。

3.6 默认配额与 LimitRange 协同

ResourceQuota 只控制 Namespace 级别的总量，不限制单个 Pod 的资源范围。若希望每个 Pod 必须设置 requests 和 limits，且不能超过某个上限，需要配合 LimitRange 使用：

apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    type: Container

这样，team-a 内的每个容器都必须满足：

CPU 在 100m ~ 2 之间
内存 128Mi ~ 4Gi 之间
若未显式设置，自动注入 default 值

而 ResourceQuota 则确保所有容器的 requests 总和不超过 4 核 CPU 和 8Gi 内存。两者结合，实现了从单个容器到整个 Namespace 的完整资源管控。