直接回答：K8s 官方只支持最近三个小版本，且版本偏差有硬约束：kubelet 不能比 apiserver 新（最多旧三个小版本）、kubectl 前后差一个版本。因此升级必须逐小版本跳跃（1.30→1.31→1.32，不能跨级），顺序固定为：先升控制面（逐台滚动，保持 etcd quorum），再升节点池（逐节点 cordon、drain、升级、uncordon），最后升插件（CNI、CoreDNS、metrics-server）与客户端。

展开解析：升级前的功课：读 CHANGELOG 的 Urgent Upgrade Notes 与废弃 API（deprecation guide），用 kubent、pluto 或 kubectl 的 discovery 扫描集群里是否还有使用将被移除 API 的资源（如 1.22 移除 Ingress v1beta1），先在低版本切到新 API。备份 etcd 快照与关键资源清单。升级窗口内 freeze 发布，避免控制器与升级互相干扰。节点升级用节点池/云厂商的滚动策略，配置 maxUnavailable 控制节奏，PDB 保证业务副本数；drain 卡住时先看 PDB 与 StatefulSet，别直接 force。灰度思想同样适用：多集群按“边缘集群→预发→生产”的顺序推进，每步观察核心 SLO 至少半天。回滚预案：控制面一般不回滚，靠快照兜底；节点池回滚即重新拉起旧版本节点。频率建议跟住每四个月一个版本的节奏，欠账超过三个版本升级风险成倍上升。

追问方向：升级中 etcd 要不要升？蓝绿集群升级（整体换新集群切流）适合什么场景？

（约 500 字）