StatefulSet默认禁止直接更新镜像字段，因有状态应用需保障数据一致性与稳定性；必须通过kubectl replace替换YAML并配合preStop钩子、版本兼容校验及PVC复用实现滚动替换。
不能直接滚动更新镜像，StatefulSet 默认禁止更新 spec.template.spec.containers[*].image 字段。 你执行 kubectl set image statefulset/mysql mysql=mysql:8.0.33 会失败，报错 Forbidden: updates to statefulset spec for fields other than 'replicas', 'ordinals', 'revisionHistoryLimit', 'minReadySeconds', 'template' are forbidden —— 注意，这里的 template 指的是整个 Pod 模板结构，但 Kubernetes 对 StatefulSet 的更新有更细粒度限制：镜像变更属于“不可变字段”，必须走替换式升级。
为什么 StatefulSet 不允许直接改镜像？
StatefulSet 的设计目标是保证有状态应用的稳定性：每个 Pod（如 mysql-0）绑定专属 PVC、固定网络标识、有序启停。如果允许就地更新镜像，可能触发以下风险：
- MySQL 8.0 启动时会自动执行
mysql_upgrade，若在原 Pod 上直接拉起新镜像，可能因数据字典不兼容导致启动失败甚至元数据损坏 - 旧进程未完全退出前新容器已写入
/var/lib/mysql，引发文件锁冲突或 InnoDB 崩溃 - 滚动更新过程中主从复制关系中断，
CHANGE MASTER TO配置残留，slave 同步位点错乱 - Operator 管理的集群（如 RadonDB）会检测到 Pod UID 变更，拒绝接管“非预期重建”的实例
正确做法：用滚动替换 + 数据兼容性兜底
核心思路是：让新 Pod 使用旧 PVC，但确保 MySQL 版本升级路径受控、可回退、不破坏数据一致性。
- 确认版本兼容性：MySQL 官方只保证
5.7 → 8.0单向升级，且要求先升级到5.7.34+再升 8.0；跳过中间小版本（如5.7.22 → 8.0.33）极大概率失败 - 备份 PVC 数据：升级前用
mysqldump --all-databases --single-transaction导出逻辑备份，并验证可恢复 - 修改 StatefulSet YAML 中的
image字段后，用kubectl replace -f mysql-sts.yaml替换资源（不是apply），强制重建 Pod - 添加
preStop生命周期钩子，优雅关闭 MySQL：lifecycle: preStop: exec: command: ["/bin/sh", "-c", "mysqladmin -uroot -p\"$MYSQL_ROOT_PASSWORD\" shutdown"] - 设置
podManagementPolicy: OrderedReady和revisionHistoryLimit: 2，确保旧 ReplicaSet 保留，便于快速回滚
升级后必须验证的三个关键点
镜像替换了不等于升级成功。以下检查项缺一不可：
- 进 Pod 执行
mysql --version和SELECT VERSION();，确认二进制与运行时版本一致 - 检查错误日志：
kubectl logs mysql-0 | grep -i "upgrade\|incompatible\|error"，特别关注Failed to open the bootstrap file或InnoDB: Upgrade is not supported - 验证复制状态（主从场景）：
SHOW SLAVE STATUS\G中Seconds_Behind_Master必须为0，且Slave_IO_Running和Slave_SQL_Running均为Yes
最易被忽略的是 MySQL 8.0 默认启用 caching_sha2_password 认证插件，而老客户端（如某些 JDBC 驱动）不支持。升级后应用连不上，不是网络或密码问题，而是认证协议不匹配 —— 必须在配置中显式加 default_authentication_plugin=mysql_native_password 或升级客户端驱动。
