3. 容量规划基础：K8s集群容量规划的核心指标

在Kubernetes集群升级场景中，临时资源预留的本质是在有限的时间窗口内，为升级操作腾出安全余量。要精准计算这个余量，必须先掌握容量规划的四个核心指标：CPU、内存、Pod密度、节点余量。这四个指标构成了从微观资源到宏观集群的完整度量体系。

3.1 核心指标全景图

下图展示了四个核心指标在集群容量规划中的层级关系与数据流向：

3.2 CPU 与内存：资源请求与限制

CPU 和内存是容量规划最基础的可量化资源。在 K8s 中，每个 Pod 都通过 resources.requests 和 resources.limits 声明资源需求。升级临时预留的核心关注点是 requests，因为调度器基于 requests 做决策。

3.3 Pod 密度：集群的“人口密度”

Pod 密度指单个节点上可调度的最大 Pod 数量。它受限于两个因素：节点 IP 地址数量（CNI 插件决定）和 Kubelet 的 --max-pods 参数。在升级场景中，Pod 密度直接影响迁移流量和调度压力。

• 高密度集群（>50 Pods/节点）：升级时需逐节点迁移大量 Pod，控制面 API Server 和 etcd 压力剧增。
• 低密度集群（<20 Pods/节点）：迁移成本低，但节点数量多，升级总时长增加。
• 最佳实践：建议将 Pod 密度控制在 30~50 Pods/节点，平衡迁移效率与控制面负载。

3.4 节点余量：安全垫与成本平衡

节点余量（Node Headroom）是容量规划中最容易被忽视但成本影响最大的指标。它指节点上未被任何 Pod 请求占用的可分配资源。在升级场景中，节点余量决定了是否需要额外预留节点。

3.5 四指标联动：升级临时预留计算模型

在升级临时资源预留成本优化中，四个指标不是孤立的，而是通过以下模型联动：

3.6 实战：如何获取这些指标

在升级前，通过以下命令和工具快速获取四个核心指标：

# 1. 查看节点可分配资源与已分配资源
kubectl describe node <node-name> | grep -A 5 "Capacity"
kubectl describe node <node-name> | grep -A 5 "Allocatable"

# 2. 查看节点当前 Pod 数量
kubectl get pods --all-namespaces --field-selector spec.nodeName=<node-name> --no-headers | wc -l

# 3. 计算节点余量（示例脚本）
NODE="<node-name>"
ALLOC_CPU=$(kubectl describe node $NODE | grep "cpu" | head -1 | awk '{print $2}')
ALLOC_MEM=$(kubectl describe node $NODE | grep "memory" | head -1 | awk '{print $2}')
REQ_CPU=$(kubectl describe node $NODE | grep "cpu" | tail -1 | awk '{print $2}')
REQ_MEM=$(kubectl describe node $NODE | grep "memory" | tail -1 | awk '{print $2}')
echo "节点余量 CPU: $((ALLOC_CPU - REQ_CPU))m, 内存: $((ALLOC_MEM - REQ_MEM))Mi"

# 4. 使用 PromQL 查询集群维度指标
# CPU 余量: sum(kube_node_status_allocatable{resource="cpu"}) - sum(kube_pod_resource_request{resource="cpu"})
# 内存余量: sum(kube_node_status_allocatable{resource="memory"}) - sum(kube_pod_resource_request{resource="memory"})

3.7 指标驱动的升级成本优化策略

基于四个核心指标，可以制定以下升级成本优化策略：

1. 低节点余量集群（<10%）：升级前先扩容 1~2 个节点，升级完成后缩容。虽然增加了临时成本，但避免了 Pod 驱逐导致的 SLA 损失。
2. 高 Pod 密度集群（>50 Pods/节点）：采用分批升级 + 控制面限流策略，每批次升级不超过集群 Pod 总数的 10%，避免 API Server 过载。
3. CPU 与内存余量不均衡：如果 CPU 余量充足但内存余量不足，考虑临时调整 Pod 的 Request（需业务方配合），或优先升级内存密集型节点。
4. 利用 Cluster Autoscaler：在升级期间启用 Cluster Autoscaler，让集群自动扩缩容来吸收临时资源波动，避免人工预留过多资源。