📚 课程目录第4章集群升级挑战

4. 集群升级挑战：Kubernetes集群升级的常见风险、Pod滚动更新对长连接的影响、优雅下线与流量排空

Kubernetes 集群升级是运维中风险最高的操作之一，尤其在承载 Envoy 网关的生产环境中，控制面与数据面的任何中断都可能导致全局流量受损。本章聚焦升级过程中的三大核心挑战：集群升级的常见风险、Pod 滚动更新对长连接的影响以及优雅下线与流量排空机制，为后续节点池巡检与流量迁移策略奠定理论基础。

4.1 集群升级的常见风险与故障模式

Kubernetes 集群升级（包括控制面升级与节点升级）并非简单的版本替换，而是一个涉及多个组件的协同过程。以下表格总结了升级过程中最常见的风险类型及其典型表现：

风险类别	典型场景	影响范围	严重等级
API 版本废弃	升级后旧版 API 被移除，导致自定义资源或控制器无法正常工作	控制面 + 数据面	严重
kubelet 版本不匹配	节点 kubelet 版本落后于控制面，导致节点状态异常或 Pod 调度失败	节点级	高
CNI 插件兼容性	升级后 CNI 插件未适配新内核或新 API，导致 Pod 网络不通	数据面	严重
etcd 数据迁移	etcd 版本跳跃过大或快照恢复失败，导致集群状态丢失	控制面	灾难
节点资源耗尽	升级过程中节点被封锁，剩余节点负载过高引发级联故障	数据面	高
Envoy 配置兼容性	新集群版本引入的 xDS 协议变更导致 Envoy 无法解析控制面推送的配置	数据面	严重

⚠️ 关键提示： 在升级前必须使用 kubectl convert 或 kube-no-trouble 等工具扫描集群中已废弃的 API 资源。Envoy 网关依赖的 networking.k8s.io/v1 和 gateway.networking.k8s.io 版本变更尤其需要提前验证。

4.2 Pod 滚动更新对长连接的影响

Envoy 作为数据面代理，其 Pod 在滚动更新过程中会经历 Terminating → 排空 → 删除 的生命周期。对于维持长连接的微服务架构（如 gRPC 流、WebSocket、TCP 透传），滚动更新可能导致以下问题：

连接中断：旧 Pod 被直接删除时，尚未处理完的请求被强制断开，客户端收到 RST 或 GOAWAY。
流量倾斜：新 Pod 启动后立即接收流量，但内部缓存或连接池尚未预热，导致部分请求超时。
连接泄漏：客户端未实现重连机制，旧连接断开后无法自动切换到新 Pod。
Envoy 热重启冲突：Envoy 的 --drain-time-s 与 Kubernetes 的 terminationGracePeriodSeconds 不匹配，导致排空未完成即被杀死。

  📊 关键指标： 滚动更新期间，Envoy 网关的 cluster.upstream_cx_active 和 listener.downstream_cx_active 指标应保持平稳下降，不应出现断崖式归零。若出现 upstream_rq_503 突增，说明排空策略失效。

4.3 优雅下线与流量排空机制

优雅下线（Graceful Shutdown）是解决滚动更新中断长连接的核心手段。其本质是在 Pod 被删除前，先将其从 Service 的 Endpoint 列表中移除，并等待现有连接处理完毕后再终止进程。Envoy 网关的流量排空需要 Kubernetes 与 Envoy 自身机制协同工作。

4.3.1 优雅下线的三层协作模型

Kubernetes 控制面层：通过 preStop 钩子触发排空逻辑，并设置合理的 terminationGracePeriodSeconds。
Envoy 数据面层：调用 Envoy 管理接口 /healthcheck/fail 标记自身不健康，同时启动 --drain-time-s 排空计时器。
负载均衡器层：云厂商 LB 或内部负载均衡器检测到 Endpoint 不健康后，停止向该 Pod 转发新连接。

💡 最佳实践： 建议将 terminationGracePeriodSeconds 设置为 --drain-time-s + 10s 的缓冲值。例如 Envoy 排空时间设为 60s，则 Pod 的 terminationGracePeriodSeconds 应设为 70s，确保排空完成前不会被 SIGKILL。

4.3.2 Envoy 排空配置示例

以下是一个典型的 Envoy 启动参数与 Kubernetes Pod 配置的配合示例：

# Envoy 启动参数（容器 entrypoint）
envoy -c /etc/envoy/envoy.yaml \
  --drain-time-s 60 \
  --drain-strategy immediate \
  --file-flush-interval-msec 1000

# Kubernetes Pod 配置片段
apiVersion: v1
kind: Pod
metadata:
  name: envoy-gateway-pod
spec:
  terminationGracePeriodSeconds: 70
  containers:
  - name: envoy
    image: envoyproxy/envoy:v1.28-latest
    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sh
          - -c
          - |
            curl -X POST http://127.0.0.1:15000/healthcheck/fail
            sleep 5
            envoy --drain-time-s 60 --drain-strategy immediate
    ports:
    - containerPort: 8080
    - containerPort: 15000

  🔧 验证命令： 在滚动更新期间，使用 kubectl get endpoints <service-name> -w 观察 Endpoint 变化；使用 envoyadmin stats | grep drain 查看 Envoy 排空状态。

4.4 节点池巡检中的流量排空策略

在集群升级的节点池巡检场景中，流量排空策略需要根据节点池的角色差异化配置：

节点池类型	排空策略	Envoy 配置要点	巡检指标
系统节点池	先排空系统组件，再排空 Envoy 网关	设置较长的 drain-time-s（≥120s）	node.kubernetes.io/unschedulable 状态
业务节点池	逐台排空，每台排空完成后等待确认	启用 drain-strategy immediate	envoy_cluster_upstream_rq_active 归零
GPU 节点池	排空前需等待 GPU 任务完成	结合 PodDisruptionBudget 控制并发	nvidia.com/gpu 资源使用率
边缘节点池	优先排空本地流量，保留跨区域连接	使用 locality-weighted 负载均衡	envoy_cluster_membership_healthy

⚠️ 巡检红线： 在节点池巡检过程中，如果发现 envoy_cluster_upstream_rq_5xx 在排空期间超过 1% 的阈值，应立即停止后续节点的排空操作，回滚升级并检查排空配置。