2. 集群升级生命周期管理：升级前检查、升级中监控、升级后验证的三阶段模型

Kubernetes 集群升级是风险最高的运维操作之一。一次失控的升级可能导致控制面瘫痪、工作负载中断、存储卷丢失甚至数据损坏。为了将升级风险降至最低，必须将升级视为一个可观测的、可审计的、可回滚的生命周期过程，而非一次性的命令执行。

本章提出的三阶段模型——升级前检查（Pre-Upgrade Check）、升级中监控（In-Upgrade Monitor）、升级后验证（Post-Upgrade Validation）——将升级过程拆解为三个可观测、可度量的阶段，每个阶段都有明确的检查清单、监控指标和验证标准。

2.1 三阶段模型总览

下表对比了三个阶段的核心目标、关键活动与可观测性产出物：

2.2 升级前检查（Pre-Upgrade Check）

升级前检查是升级安全的第一道防线。该阶段的目标是在升级操作执行之前，发现所有可能影响升级成功或导致集群不可用的问题。检查结果必须形成结构化的报告，并作为升级审批的依据。

2.2.1 检查清单与自动化执行

以下是一个标准化的升级前检查清单，建议使用自动化工具（如 cluster-upgrade-checker 或自定义 Operator）逐项执行：

2.2.2 检查报告示例

以下是一个简化版的 PreCheckReport 结构，展示了检查结果的标准化输出：

{
  "clusterName": "prod-east-1",
  "upgradeFrom": "v1.27.3",
  "upgradeTo": "v1.28.0",
  "checkTimestamp": "2025-03-15T08:00:00Z",
  "overallStatus": "PASS",
  "riskLevel": "LOW",
  "checkItems": [
    {
      "category": "VERSION_COMPATIBILITY",
      "name": "API Deprecation Check",
      "status": "PASS",
      "detail": "No deprecated APIs found in current manifests."
    },
    {
      "category": "RESOURCE_HEALTH",
      "name": "Control Plane Components",
      "status": "PASS",
      "detail": "All 3 master nodes healthy."
    },
    {
      "category": "BACKUP_VALIDATION",
      "name": "etcd Snapshot Integrity",
      "status": "PASS",
      "detail": "Snapshot size: 2.3GB, hash verified."
    },
    {
      "category": "TENANT_ISOLATION",
      "name": "NetworkPolicy Coverage",
      "status": "WARN",
      "detail": "Namespace 'dev-team-b' has no default deny policy."
    }
  ],
  "recommendations": [
    "Apply default deny NetworkPolicy to namespace 'dev-team-b' before upgrade."
  ]
}

2.3 升级中监控（In-Upgrade Monitor）

升级中监控是升级生命周期的实时感知层。当升级操作开始执行后，运维团队需要实时了解升级进度、组件状态变化以及异常事件，以便在问题发生时快速决策（继续、暂停或回滚）。

2.3.1 监控维度与关键指标

升级过程中的监控应覆盖以下四个维度：

• 控制面维度：API Server 响应延迟、etcd 领导者变更次数、Controller Manager 队列深度、Scheduler 调度速率。
• 节点维度：节点升级进度（已升级/总数）、节点 NotReady 持续时间、节点上 Pod 驱逐速率。
• 工作负载维度：Pod 重调度成功率、Pending Pod 数量、工作负载可用副本数（Available Replicas）。
• 事件维度：Warning 级别事件频率、升级相关 Event 的 Reason 分布（如 NodeUpgradeStarted、PodEvictionFailed）。

以下是一个升级中监控仪表盘的关键指标表格：

2.3.2 升级中异常处理策略

当监控系统检测到异常时，升级 Operator 或运维人员应根据异常等级采取不同策略：

• 低风险异常（如单个节点升级超时）：自动重试 2 次，若仍失败则跳过该节点，继续升级其他节点，并在升级报告中标记。
• 中风险异常（如 API Server 延迟飙升）：暂停节点池滚动，等待控制面恢复稳定（通常 5-10 分钟），然后继续。
• 高风险异常（如 etcd 集群失联、多个节点同时 NotReady）：立即触发升级回滚流程，恢复至升级前状态。

2.4 升级后验证（Post-Upgrade Validation）

升级后验证是升级生命周期的质量门禁。只有当所有验证项通过后，升级才能被标记为“成功”，集群才能恢复对外提供完整服务。验证结果也是后续审计和合规审查的核心依据。

2.4.1 验证清单与自动化执行

升级后验证应覆盖功能、性能、安全三个维度：

2.4.2 验证报告与回滚决策

升级后验证报告（PostCheckReport）是决定升级是否成功的最终依据。报告应包含：

• 总体结论：PASS / FAIL / PARTIAL_PASS（部分通过，需人工介入）。
• 逐项验证结果：每个验证项的详细状态、耗时、对比基线。
• 性能对比数据：升级前后关键性能指标的对比图表（如 API Server 延迟分布、Pod 启动时间分布）。
• 回滚建议：如果验证失败，报告应明确指出失败项是否影响核心业务，并给出回滚建议。

2.5 三阶段模型与租户审计的关联

三阶段模型不仅是技术操作流程，更是租户审计数据的重要来源。每个阶段产生的报告和事件记录，都应包含租户维度的标签（如 tenant-id、namespace），以便审计系统能够按租户维度查询升级影响。

下表展示了三阶段模型如何与租户审计数据关联：