AKS 1.21跨版本升级至1.25的潜在风险咨询

• 组件兼容性问题

  • 容器网络相关：AKS升级时会同步更新内置组件，但如果用了自定义CNI（比如特定版本的Calico），可能和1.25的kube-proxy、kubelet版本不兼容，导致网络不通、容器网络策略失效，或者Pod跨节点通信异常。
  • 存储驱动相关：老版本的CSI驱动（比如Azure Disk CSI旧版本）可能不支持1.25的存储特性或API逻辑，升级后可能出现PVC创建失败、已有存储卷挂载超时，甚至数据读写异常。

• 节点运行时环境变更

  • 容器运行时切换：AKS 1.24及之后默认用containerd，而1.21集群如果没手动切换过，大概率还在用Docker。直接跨版本升级会自动切到containerd，之前依赖Docker特定socket、路径或docker命令的应用（比如某些自定义init容器）会启动失败。
  • kubelet参数调整：1.21到1.25之间kubelet的默认参数有不少变化，比如资源阈值、镜像拉取策略的默认值，对资源敏感的应用可能突然出现OOM，或者镜像拉取超时导致Pod无法启动。

• 第三方插件/Operator适配问题

  • 监控、日志工具：旧版本的Prometheus Operator、Fluentd/Fluent Bit可能不兼容1.25的CRD规范或kubelet日志格式，升级后会出现监控指标断流、日志丢失或解析错误。
  • 自定义Operator：基于旧版本K8s SDK开发的自定义Operator，可能对1.25中API对象的字段变化（比如默认值、校验规则）不适应，导致Operator不断重启、无法同步资源。

• 集群核心组件行为变化

  • 调度逻辑改动：1.25的kube-scheduler新增了默认开启的调度策略，可能打乱原有Pod的调度分布，比如原本固定在某AZ的Pod被调度到其他区域，影响业务的就近访问性能。
  • 准入控制规则变化：PodSecurityPolicy在1.25中被彻底移除，如果之前依赖PSP但没切换到Pod Security Standards，升级后Pod创建会直接被拦截，导致业务无法扩容或部署新应用。
  • CoreDNS配置变化：升级时CoreDNS会同步更新版本，原有自定义的rewrite、转发规则可能和新版本不兼容，导致服务域名解析失败，应用无法访问依赖的服务。

• 升级过程中的稳定性风险

  • 节点通信异常：控制平面升级到1.25后，老版本（1.21）的kubelet可能无法和新API Server正常通信，导致节点进入NotReady状态，且这种状态可能持续到节点完成升级，期间业务Pod会被驱逐，影响可用性。
  • 控制平面资源过载：跨大版本升级时，kube-apiserver、etcd需要处理大量的版本转换请求，可能出现CPU、内存占用飙升，导致集群API响应变慢，甚至短时间内无法处理请求，影响业务的正常操作（比如扩容、部署）。

内容的提问来源于stack exchange，提问作者Vivek