16.6.6 集群容量与资源配额

集群容量与资源配额是保障多团队共享集群稳定性与成本可控的关键。容量管理关注“集群能承载多少工作负载”，配额管理关注“每个命名空间/团队能使用多少资源”。两者共同决定了资源公平性、可预测性与弹性边界。

原理草图：容量评估与配额生效路径#

文章图片

容量评估关键指标与命令示例#

容量管理围绕 Allocatable、保留资源、负载画像、可用区冗余展开。

1) 查看节点可分配资源与保留 

# 查看节点 Allocatable、Capacity、系统保留等关键字段
kubectl describe node <node-name> | sed -n '/Capacity:/,/Non-terminated Pods/p'

# 解释：
# Capacity: 节点物理资源
# Allocatable: 扣除系统/平台保留后的可用资源
# Non-terminated Pods: 当前运行负载

2) 查看实时资源使用（需安装 metrics-server） 

# 安装 metrics-server（如集群未安装）
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 采集数据后查看节点/Pod使用率
kubectl top nodes
kubectl top pods -A | head

3) 评估资源碎片化（简单方式） 

# 汇总每个节点的可调度资源与已使用资源（示意）
kubectl get nodes -o jsonpath='{range .items[*]}{@.metadata.name}{"\t"}{@.status.allocatable.cpu}{"\t"}{@.status.allocatable.memory}{"\n"}{end}'

资源配额与限制策略：配置与效果#

ResourceQuota 控制命名空间总量，LimitRange 控制单个Pod/容器默认请求与上限。

1) ResourceQuota 示例（命名空间总量限制）#

# 文件：quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "12"
    limits.memory: 24Gi
    pods: "50"
    persistentvolumeclaims: "20"

应用与验证：

kubectl apply -f quota.yaml
kubectl describe quota -n team-a

# 解释：
# hard: 配额上限
# used: 当前已使用额度

2) LimitRange 示例（默认 requests/limits）#

# 文件：limitrange.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-defaults
  namespace: team-a
spec:
  limits:
  - type: Container
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    max:
      cpu: "2"
      memory: "2Gi"

应用与验证：

kubectl apply -f limitrange.yaml
kubectl describe limitrange -n team-a

3) 示例 Pod：不设置 requests/limits 的默认效果#

# 文件：nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
  namespace: team-a
spec:
  containers:
  - name: nginx
    image: nginx:1.25

部署与观察：

kubectl apply -f nginx-pod.yaml
kubectl get pod nginx-demo -n team-a -o yaml | sed -n '/resources:/,/image:/p'

# 预期：
# resources 会被 LimitRange 自动补齐 defaultRequest/default

配额相关排错与诊断#

1) Pod Pending：超出配额#

kubectl get pods -n team-a
kubectl describe pod <pod-name> -n team-a | sed -n '/Events:/,$p'

常见报错：
- exceeded quota: team-a-quota
- insufficient cpu/memory

处理思路：
- 调整 ResourceQuota/LimitRange
- 降低单个 Pod requests/limits
- 扩容节点或启用自动伸缩

2) 配额“账面占用”过高导致排队#

kubectl describe quota -n team-a

若 limits.cpu 高但实际使用低，说明 requests/limits 配置过大，建议回调 limits 或启用 VPA。

3) 存储配额不足导致 PVC Pending#

kubectl get pvc -n team-a
kubectl describe pvc <pvc-name> -n team-a

若配额不足，需调整 persistentvolumeclaims 或容量上限。

容量与配额实践建议#

  • 预留 20%~30% 容量冗余，应对故障与突发扩缩容。
  • 配合 QoS 与优先级实现“可抢占”分层。
  • 关键业务高配额，非核心业务严格配额与默认限制。
  • 定期复盘 used/hard 变化，按业务周期滚动调整。

练习#

1) 在 team-a 命名空间创建 ResourceQuota 与 LimitRange，验证未设置 requests 的 Pod 会被补齐默认值。
2) 将 requests.cpu 设置为小于 1 的值，观察 kubectl describe quota 中 used 的变化。
3) 故意超出 pods 配额，观察 Pod Pending 事件并给出处理方案。
4) 限制 PVC 数量为 1，尝试创建第 2 个 PVC 并排错。