3. 瓶颈识别方法论：升级前资源审计的步骤、关键指标（CPU、内存、Pod数量、PVC存储）的采集与分析

集群升级前，资源审计是识别瓶颈、规避升级失败的核心前置动作。缺乏审计的升级如同“盲飞”——你可能在升级过程中遭遇 Pod 驱逐失败、节点压力超限、控制面组件 OOM 等连锁故障。本节将系统化拆解审计步骤与关键指标采集方法。

3.1 资源审计四步法

审计不是一次性快照，而是一个从“全局扫描”到“风险定位”的递进过程。推荐按以下四个步骤执行：

1. 步骤一：集群级容量摸底 —— 获取集群总可分配资源（Allocatable）与当前请求量（Requests）的比值，判断整体水位。
2. 步骤二：节点级压力扫描 —— 逐节点检查 CPU/Memory 的 Allocatable - Requests - Reserved 余量，标记压力节点。
3. 步骤三：工作负载级细粒度分析 —— 按 Namespace/Deployment/StatefulSet 统计资源使用率与 Limit 配置，识别“资源黑洞”。
4. 步骤四：存储与对象计数审计 —— 检查 PVC 容量、PV 绑定状态、Pod 总数与 Endpoint 数量，避免控制面过载。

3.2 关键指标采集与分析方法

审计的核心是四个维度的指标：CPU、内存、Pod 数量、PVC 存储。每个维度都有其独特的采集命令、阈值判断逻辑和风险模式。

3.2.1 CPU 指标

3.2.2 内存指标

3.2.3 Pod 数量指标

3.2.4 PVC 存储指标

3.3 审计脚本示例

以下是一个简化的 Bash 审计脚本片段，用于快速采集节点级 CPU 和内存分配率：

#!/bin/bash
# cluster-audit.sh — 升级前资源审计快速扫描
echo "=== 节点资源分配率审计 ==="
kubectl get nodes --no-headers | awk '{print $1}' | while read node; do
  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 "Node: $node | CPU Alloc: $alloc_cpu | CPU Req: $req_cpu | Mem Alloc: $alloc_mem | Mem Req: $req_mem"
done

echo ""
echo "=== Pod 数量统计 ==="
kubectl get pods -A --no-headers | wc -l
echo "=== PVC 状态检查 ==="
kubectl get pvc -A | grep -v "Bound"

3.4 审计结果解读与瓶颈判定

采集到指标后，需要根据以下规则判定瓶颈等级：

• 红色瓶颈（必须修复）： 节点 CPU/Memory 分配率 > 90%，或 Pod 数量达到节点 maxPods 的 95%，或 PVC 使用率 > 90%。升级前必须扩容或迁移。
• 橙色瓶颈（建议修复）： 节点 CPU/Memory 分配率 80%~90%，或内存 Limit 超配比 > 4 倍，或集群 Pod 总数接近 CIDR 容量的 80%。建议在升级窗口前优化。
• 黄色关注（持续监控）： 节点分配率 70%~80%，或存在少量 Pending PVC。升级期间需重点观察，但不必阻塞升级。