Kubernetes 相关组件升级：先检查版本偏差与资源定义
Kubernetes 环境中的升级通常牵动多个层次：集群版本、节点运行时、命令行工具、工作负载清单、控制器和扩展组件。真正的难点不是记住某个编号，而是确认各层之间允许的版本偏差和资源定义兼容性。本文采用风险分层方式帮助阅读和测试。支持窗口、偏差规则与弃用资源会随版本调整，实施时必须查阅当前维护材料和集群提供方说明。
先画出组件关系图
列出控制面、节点、核心附加组件、入口控制器、存储驱动、网络组件、监控采集器和应用工作负载。每项记录实际版本、部署方式和依赖关系。没有这张图时，升级后出现异常很难区分是集群行为、扩展组件还是应用清单导致。图不需要复杂，但应反映真实运行状态，而不是理想架构。
检查弃用资源与清单语义
资源版本弃用常在升级后导致清单无法提交或控制器行为不同。应扫描部署清单、图表模板和自动化脚本中的资源版本、字段名称和默认值，并在目标环境的校验工具中验证。字段仍被接受不代表语义没有变化，因此还要检查生成的最终对象和控制器日志。对无法确认的自定义资源，应先验证对应控制器是否支持目标集群版本。
按层次安排升级与验证
一般应先遵循集群维护方给出的支持顺序，再安排扩展组件与应用工作负载。每一层完成后验证节点状态、调度、服务发现、存储挂载、网络连通与日志采集。不要同时更换大量控制器，否则异常时难以定位。若存在多集群，可先在代表性但可隔离的环境完成完整路径演练。
关注工作负载的运行差异
升级可能影响安全上下文、资源限制、探针时序、卷挂载、域名解析或调度行为。应用层应验证启动、滚动替换、扩缩容、配置更新和故障恢复。重点不是追求全部指标相同，而是确认关键服务目标没有出现无法解释的持续偏离。出现问题时，保存事件、对象定义和节点信息再进行判断。
准备跨层回退策略
部分集群层操作不适合直接回退，因此在实施前要明确哪些层可恢复、哪些只能通过修复前进。工作负载清单和扩展组件可保留旧版本，但数据卷与控制面状态需要单独评估。将这些限制写进计划，避免在紧急时做出不受支持的切换。