📚 课程目录第2章 Kubernetes 资源配额基础

2. Kubernetes 资源配额基础：Resource Quota 定义、LimitRange 作用、命名空间级别资源管控

在 Argo CD 滚动升级场景中，资源配额（Resource Quota）与限制范围（LimitRange）是保障集群稳定性、防止资源争抢的核心机制。本章将系统讲解 Kubernetes 原生资源管控体系，为后续“滚动升级资源校准”奠定理论基础。

2.1 Resource Quota：命名空间资源硬边界

Resource Quota 是 Kubernetes 内置的准入控制机制，作用于命名空间级别，用于限制该命名空间内所有 Pod、Service、PVC 等对象可消耗的资源总量。一旦配额耗尽，后续创建请求将被拒绝（返回 403 Forbidden）。

资源类型	配额字段	说明
CPU	`requests.cpu` / `limits.cpu`	所有 Pod 的 CPU 请求/上限总和
内存	`requests.memory` / `limits.memory`	所有 Pod 的内存请求/上限总和
存储	`requests.storage`	所有 PVC 的存储请求总和
对象数量	`count/pods` / `count/services` / `count/configmaps`	命名空间内各类对象的最大数量

  关键原则：Resource Quota 只限制总量，不限制单个 Pod 的规格。若未设置 LimitRange，单个 Pod 可能占用全部配额，导致其他 Pod 无法调度。

2.1.1 典型 Resource Quota 定义示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-team-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    count/pods: "20"
    count/services: "10"
    count/configmaps: "30"

上述配额限制 dev 命名空间内所有 Pod 的 CPU 请求总和不超过 4 核，内存请求不超过 8Gi，Pod 总数不超过 20 个。超出任一硬限制，Kubernetes API Server 将拒绝创建新资源。

2.2 LimitRange：Pod 与容器的资源约束

LimitRange 与 Resource Quota 配合使用，为命名空间内的 Pod 或容器设置默认请求/限制以及最小/最大约束。它解决了两个关键问题：

默认值注入：若 Pod 未显式设置资源请求/限制，LimitRange 自动注入默认值。
边界控制：防止单个 Pod 请求过大或过小，避免资源碎片或配额滥用。

LimitRange 类型	作用范围	常用字段
`Container`	单个容器	`min` / `max` / `default` / `defaultRequest`
`Pod`	Pod 内所有容器总和	`min` / `max`
`PersistentVolumeClaim`	PVC 存储请求	`min` / `max`

2.2.1 LimitRange 配置示例

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limits
  namespace: dev
spec:
  limits:
  - type: Container
    min:
      cpu: "50m"
      memory: "64Mi"
    max:
      cpu: "2"
      memory: "4Gi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
  - type: PersistentVolumeClaim
    min:
      storage: "1Gi"
    max:
      storage: "100Gi"

最佳实践：在 Argo CD 管理的命名空间中，始终同时部署 Resource Quota 和 LimitRange。LimitRange 确保每个 Pod 有合理的资源声明，Resource Quota 控制总量上限，两者形成“上下夹击”的管控闭环。

2.3 命名空间级别资源管控架构

下图展示了 Resource Quota 与 LimitRange 在命名空间内的协同工作流程：

2.4 资源配额与滚动升级的关联

在 Argo CD 滚动升级过程中，Resource Quota 和 LimitRange 直接影响升级的成功率与速度：

蓝绿部署：新版本 Pod 创建时，若配额不足，升级将卡在 Pending 状态，导致流量切换失败。
金丝雀发布：金丝雀 Pod 需要额外资源配额，若未预留，金丝雀可能无法启动。
回滚场景：回滚时旧版本 Pod 重新创建，同样受配额限制，配额不足将导致回滚失败。

常见陷阱：许多团队只设置 Resource Quota 而忽略 LimitRange，导致部分 Pod 未设置资源限制，在滚动升级时意外占用全部配额，引发级联故障。务必同时部署两者。

2.5 资源配额校验命令速查

操作	命令
查看命名空间配额	`kubectl get resourcequota -n <namespace>`
查看配额使用详情	`kubectl describe resourcequota <name> -n <namespace>`
查看 LimitRange	`kubectl get limitrange -n <namespace>`
模拟创建 Pod 检查配额	`kubectl apply --dry-run=server -f pod.yaml`

2.6 本章小结

Resource Quota 定义命名空间资源总量硬边界，防止资源滥用。
LimitRange 约束单个 Pod/容器的资源范围，并注入默认值。
两者配合形成上下双层管控，是滚动升级资源校准的前提条件。
在 Argo CD 部署前，必须确认目标命名空间的配额是否满足新版本 Pod 的资源需求。