2. K8s集群升级基础概念：控制面升级、节点升级、工作负载迁移、滚动更新策略

K8s集群升级并非单一操作，而是由多个独立但相互依赖的阶段组成。理解每个阶段的目标、风险与操作方式，是制定容量规划的前提。本章将拆解升级过程中的四个核心概念：控制面升级、节点升级、工作负载迁移与滚动更新策略。

2.1 控制面升级（Control Plane Upgrade）

控制面是集群的大脑，包含 kube-apiserver、kube-controller-manager、kube-scheduler 以及 etcd。升级顺序必须严格遵循：先升级控制面组件，再升级节点。控制面升级期间，API Server 可能短暂不可用，但已运行的 Pod 不会中断。

2.2 节点升级（Node Upgrade）

节点升级通常采用“逐节点”或“滚动节点”方式。每个节点在升级前需要执行 drain（排空）操作，将节点上的 Pod 优雅驱逐到其他可用节点。节点升级完成后，再执行 uncordon（取消隔离）使其重新加入调度池。

# 节点排空命令示例
kubectl drain node-01 --ignore-daemonsets --delete-emptydir-data

# 节点升级完成后取消隔离
kubectl uncordon node-01

节点升级期间，集群总可用容量会暂时减少。假设集群有 N 个节点，每次升级 1 个节点，则可用节点数为 N-1。如果集群资源利用率已经接近 80%，排空一个节点可能导致剩余节点资源过载。

2.3 工作负载迁移（Workload Migration）

工作负载迁移是指将 Pod 从正在升级的节点上安全地转移到其他节点的过程。K8s 通过 PodDisruptionBudget（PDB） 控制迁移速率，确保业务可用性不受影响。

PDB 定义了一个工作负载在自愿中断（如节点 drain）期间允许的最大不可用 Pod 数量或比例。

# PDB 示例：确保 my-app 至少有 2 个副本可用
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

迁移过程中，调度器会将新 Pod 分配到剩余节点。如果剩余节点资源不足，Pod 将处于 Pending 状态，直到有节点释放资源或扩容完成。

2.4 滚动更新策略（Rolling Update Strategy）

滚动更新是工作负载自身版本升级的机制，与集群节点升级不同。它通过逐步替换旧版本 Pod 为新版本 Pod 来实现零停机发布。滚动更新策略由 Deployment 或 StatefulSet 的 spec.strategy.rollingUpdate 字段控制。

滚动更新与节点升级可能同时发生，形成“双重资源消耗”：节点升级 drain 旧 Pod，同时滚动更新创建新 Pod。如果两者叠加，集群资源压力会急剧上升。

# Deployment 滚动更新策略示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
      maxSurge: 3
  template:
    spec:
      containers:
      - name: web
        image: nginx:1.25

2.5 升级流程关系图

下图展示了集群升级过程中，控制面升级、节点升级、工作负载迁移与滚动更新之间的时序与依赖关系。

2.6 升级阶段资源消耗对比

不同升级阶段对集群资源的影响差异显著。下表总结了各阶段的关键资源消耗特征，用于指导容量预留计算。