📚 课程目录第2章集群升级基础

2. 集群升级基础：Kubernetes集群版本升级策略、滚动升级原理、升级对工作负载的影响

在Serverless事件驱动场景下，集群升级不再是单纯的版本变更，而是涉及资源调度、Pod生命周期管理与事件流连续性的系统工程。本节将系统梳理Kubernetes集群升级的核心策略、滚动升级的底层机制，以及升级操作对运行中工作负载的具体影响。

2.1 Kubernetes版本升级策略

Kubernetes社区推荐采用小版本持续升级策略，避免跨多个大版本跳跃。根据集群规模和风险容忍度，主流升级策略分为以下三种：

策略类型	适用场景	升级速度	风险等级	回滚复杂度
原地升级（In-Place）	单控制面、开发测试集群	快	高	低（需快照）
节点池滚动升级（Node Pool Rolling）	生产集群、托管Kubernetes服务	中	中	中
蓝绿升级（Blue-Green）	关键业务、Serverless事件驱动集群	慢	低	高（流量切换）

Serverless场景建议： 优先采用节点池滚动升级或蓝绿升级。原地升级在控制面组件重启期间可能导致事件处理延迟或Webhook调用失败，对Serverless工作负载影响较大。

升级路径必须遵循Kubernetes版本号规则：v1.x.y 中，x 为次版本号，y 为补丁版本号。升级时只能逐次版本递增（如 v1.27 → v1.28），禁止跨次版本升级。补丁版本可跨多个版本升级（如 v1.27.3 → v1.27.6）。

2.2 滚动升级原理

滚动升级（Rolling Update）是Kubernetes默认的Pod更新策略，其核心思想是逐步替换旧版本Pod，确保在整个过程中始终有足够数量的Pod提供服务。滚动升级由Deployment、StatefulSet等控制器驱动，通过ReplicaSet版本管理实现。

  关键参数：
  maxSurge：升级期间允许超出期望副本数的最大Pod数（百分比或值）。
maxUnavailable：升级期间允许不可用Pod的最大数量（百分比或值）。

滚动升级的详细执行步骤：

创建新ReplicaSet： Deployment控制器根据新版本镜像创建新的ReplicaSet，初始副本数为0。
逐步扩容新RS： 按照maxSurge参数，逐步增加新RS的副本数。例如，maxSurge=25%时，新Pod数量最多超出期望副本数的25%。
逐步缩容旧RS： 在新Pod进入Ready状态后，按照maxUnavailable参数，逐步删除旧RS中的Pod。
健康检查验证： 每个新Pod必须通过Readiness Probe和Startup Probe后，才会继续下一批替换。
完成升级： 当旧RS副本数降为0，新RS副本数达到期望值，升级完成。

2.3 升级对工作负载的影响

集群升级对工作负载的影响主要体现在Pod重建、API兼容性和资源调度三个维度。在Serverless事件驱动场景下，这些影响会被事件流的连续性要求放大。

影响维度	具体表现	Serverless场景风险	缓解措施
Pod重建	节点升级导致Pod被驱逐，Pod IP变更	事件源连接中断，消息积压	使用Service名称访问，配置PodDisruptionBudget
API兼容性	废弃API版本在升级后不可用	Knative/Eventing CRD版本不匹配	升级前使用 `kubectl convert` 检查API版本
资源调度	节点资源被升级占用，调度延迟	新事件触发时无可用节点	预留缓冲节点，设置Pod优先级
控制面组件重启	kube-apiserver、kube-controller-manager重启	Webhook调用失败，事件处理中断	多副本控制面，配置优雅终止

关键风险提示： 在Serverless事件驱动架构中，Knative Serving和Eventing组件的CRD（如Service、Trigger、Broker）对Kubernetes API版本敏感。升级前必须验证目标版本是否支持当前使用的CRD版本，否则可能导致事件路由失效。

2.4 PodDisruptionBudget（PDB）配置

PDB是保护Serverless工作负载在集群升级期间不被过度中断的关键资源。通过定义minAvailable或maxUnavailable，PDB确保在主动驱逐（如节点升级）时，始终有指定数量的Pod可用。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: knative-service-pdb
  namespace: serverless-apps
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-event-processor

  PDB配置要点：
  minAvailable：指定最少可用Pod数量，适用于有状态服务或需要固定处理能力的场景。
maxUnavailable：指定最多不可用Pod数量，适用于无状态服务或弹性伸缩场景。
在Serverless场景中，建议将PDB与HPA（水平Pod自动伸缩）配合使用，确保升级期间有足够的Pod处理事件。

2.5 升级前检查清单

在Serverless事件驱动集群中执行升级前，必须完成以下检查项：

API版本兼容性： 使用 kubectl convert 检查所有CRD和自定义资源是否兼容目标版本。
事件源状态： 确认所有事件源（如Kafka、S3、Cloud Pub/Sub）的连接状态正常，无积压消息。
PDB配置： 确保所有关键Serverless服务已配置PDB，且minAvailable值合理。
节点资源预留： 预留至少20%的节点资源用于升级期间的Pod重建和事件处理。
回滚方案： 准备集群快照或备份，确保在升级失败时能快速回滚到上一版本。

通过深入理解集群升级策略、滚动升级原理及其对工作负载的影响，可以为Serverless事件驱动场景制定更稳健的升级方案，确保事件流的连续性和服务的可用性。