📚 课程目录第3章集群升级前的资源审计

3. 集群升级前的资源基线建立

在集群升级前，必须建立准确的资源基线。基线数据用于校准升级后的资源配额、识别异常负载、并为性能调优提供对比基准。本章将详细讲解如何通过 Prometheus 和 Metrics Server 采集当前集群的 CPU/内存使用率、请求量（Requests）和限制量（Limits）的基线数据。

3.1 基线采集的核心指标与数据源

资源基线需要覆盖以下三个维度：

维度	指标名称（Prometheus）	数据来源	说明
使用率（Usage）	`container_cpu_usage_seconds_total` `container_memory_working_set_bytes`	cAdvisor（内嵌于 kubelet）	实际消耗的物理资源，用于判断 Pod 的真实负载
请求量（Requests）	`kube_pod_resource_request`	kube-state-metrics	调度时预留的资源量，决定 Pod 能否被调度到节点
限制量（Limits）	`kube_pod_resource_limit`	kube-state-metrics	资源使用的硬上限，超过后会被 OOM Kill 或 CPU 节流

基线采集原则： 使用率基线应采集至少 7 天的数据（包含业务高峰和低谷），Requests/Limits 基线则直接读取当前集群中所有运行 Pod 的资源配置。升级后，将新集群的使用率与基线对比，可快速发现资源泄漏或调度异常。

3.2 使用 Metrics Server 采集实时快照

Metrics Server 提供集群资源的实时快照，适合快速查看当前资源状态，但不支持历史数据查询。以下是采集节点和 Pod 资源基线的命令：

# 获取所有节点的 CPU 和内存使用率（实时）
kubectl top nodes

# 获取所有 Pod 的 CPU 和内存使用率（实时）
kubectl top pods --all-namespaces

# 获取指定命名空间下 Pod 的资源请求与限制
kubectl get pods -n <namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].resources.requests.cpu}{"\t"}{.spec.containers[*].resources.requests.memory}{"\t"}{.spec.containers[*].resources.limits.cpu}{"\t"}{.spec.containers[*].resources.limits.memory}{"\n"}{end}'

注意： Metrics Server 的数据保留时间默认为 5 分钟，仅用于实时监控。对于基线建立，必须结合 Prometheus 进行持久化存储和历史数据聚合。

3.3 使用 Prometheus 采集历史基线

Prometheus 通过 cAdvisor 和 kube-state-metrics 采集详细的资源指标，并支持长时间范围内的聚合查询。以下是建立基线所需的 PromQL 查询语句：

3.3.1 CPU 使用率基线（7 天平均）

# 计算每个 Pod 的 CPU 使用率（核数），按 7 天平均
avg by (namespace, pod, container) (
  rate(container_cpu_usage_seconds_total{container!=""}[5m])
) * on (namespace, pod, container) group_left(label_k8s_app)
  avg_over_time(
    avg by (namespace, pod, container) (
      rate(container_cpu_usage_seconds_total{container!=""}[5m])
    )[7d:]
  )

3.3.2 内存使用率基线（7 天 P95）

# 计算每个 Pod 的内存使用率（字节），取 7 天内的 P95 值
quantile_over_time(0.95,
  avg by (namespace, pod, container) (
    container_memory_working_set_bytes{container!=""}
  )[7d:]
)

3.3.3 Requests/Limits 基线（当前配置）

# 获取所有 Pod 的 CPU Requests 和 Limits
kube_pod_resource_request{resource="cpu"}
kube_pod_resource_limit{resource="cpu"}

# 获取所有 Pod 的内存 Requests 和 Limits
kube_pod_resource_request{resource="memory"}
kube_pod_resource_limit{resource="memory"}

  基线输出示例（CSV 格式）：

  namespace,pod,container,cpu_usage_avg_7d,mem_usage_p95_7d,cpu_requests,cpu_limits,mem_requests,mem_limits

  production,web-7f9c8b6d4c-abc12,nginx,0.23,256Mi,0.5,1.0,512Mi,1Gi

3.4 基线数据采集架构

下图展示了 Prometheus 与 Metrics Server 在基线采集中的协作关系：

3.5 基线数据导出与格式化

将 Prometheus 查询结果导出为结构化文件，便于升级后对比分析。推荐使用以下命令导出 CSV 格式：

# 使用 promtool 或 curl 导出 Prometheus 查询结果
curl -G 'http://prometheus-server:9090/api/v1/query' \
  --data-urlencode 'query=avg by (namespace, pod, container) (rate(container_cpu_usage_seconds_total{container!=""}[5m]))' \
  | jq -r '.data.result[] | [.metric.namespace, .metric.pod, .metric.container, .value[1]] | @csv' \
  > cpu_usage_baseline.csv

# 导出内存使用率 P95 基线
curl -G 'http://prometheus-server:9090/api/v1/query' \
  --data-urlencode 'query=quantile_over_time(0.95, avg by (namespace, pod, container) (container_memory_working_set_bytes{container!=""})[7d:])' \
  | jq -r '.data.result[] | [.metric.namespace, .metric.pod, .metric.container, .value[1]] | @csv' \
  > mem_usage_baseline.csv

基线文件管理： 将导出的 CSV 文件与集群版本、导出时间一并记录，作为升级前的基准快照。建议同时导出 Prometheus 的原始配置文件（prometheus.yml）和 recording rules，确保升级后可以复现相同的查询逻辑。

3.6 基线验证与异常检测

在建立基线后，需要验证数据的完整性和合理性。以下是一个基线验证清单：

验证项	检查方法	预期结果
数据完整性	统计每个命名空间下的 Pod 数量，与 `kubectl get pods` 对比	数量一致，无缺失 Pod
使用率范围	检查 CPU 使用率是否在 0 到 Limits 之间	无超过 Limits 的记录（说明未发生节流）
Requests 合理性	检查 Requests 是否小于等于 Limits	所有 Pod 均满足 Requests ≤ Limits
内存 P95 稳定性	对比每日 P95 值，波动应小于 20%	无突增或突降，业务负载稳定

常见问题： 如果发现某个 Pod 的 CPU 使用率长期接近 Limits（>90%），说明该 Pod 可能处于资源瓶颈状态，升级前应评估是否需要调整 Limits 或进行水平扩展。同样，内存使用率接近 Limits 的 Pod 存在 OOM 风险，需优先处理。

3.7 基线数据在升级后的应用

升级完成后，立即执行相同的 PromQL 查询，将新集群的使用率与基线对比。对比结果可用于：

资源配额校准： 如果新集群的 Pod 使用率明显高于基线（>20%），说明升级可能引入了资源泄漏或配置变更，需要回滚或调整。
性能回归检测： 对比升级前后的 P95 延迟和资源使用率，判断升级是否导致性能下降。
自动扩缩容策略调整： 根据基线数据更新 HPA（Horizontal Pod Autoscaler）的目标利用率，避免升级后扩缩容策略失效。

通过以上步骤，你可以在集群升级前建立一份准确、可复用的资源基线，为后续的资源配额校准和性能调优提供坚实的数据基础。