Kubernetes复用已有PV重部署MySQL 8.0出现root@localhost访问拒绝

• 官方mysql/mysql-server:8.0镜像的初始化逻辑限制：仅首次启动（/var/lib/mysql数据目录为空）时，才会读取MYSQL_ROOT_PASSWORD等环境变量完成账号创建、数据库初始化操作。复用已有PV时数据目录非空，入口点不会重新执行初始化流程，新部署的Secret中存储的密码和旧PV内MySQL系统表里存储的账号密码不匹配，直接导致登录失败、存活探测报错。
• 配置冲突：你的my.cnf中指定了user=mysql，但Deployment的securityContext设置了runAsUser=1001，而官方mysql镜像内默认mysql用户的UID为27不是1001，所以会出现日志中的「Ignoring user change to '1001'」警告，也会带来权限隐患。

场景1：需要保留PV内已有数据 #

1. 临时修改Deployment配置，注释掉存活/就绪探针、删除MYSQL_ROOT_PASSWORD等环境变量，先启动容器。
2. 执行kubectl exec -it <mysql-pod名> bash进入容器，使用旧的root密码登录MySQL；如果忘记旧密码，可先停止MySQL进程，加--skip-grant-tables参数启动后重置密码。
3. 执行SQL将root密码更新为新Secret中配置的密码：

ALTER USER 'root'@'localhost' IDENTIFIED BY '你的新root密码';
FLUSH PRIVILEGES;

4. 恢复Deployment的探针、环境变量配置，重启Pod即可正常运行。

场景2：不需要保留PV数据/首次部署避免后续复用出错 #

1. 修复配置冲突：将Deployment的securityContext中runAsUser和fsGroup的值改为27（官方镜像mysql用户的默认UID），可以删掉注释的权限修改initContainer，fsGroup会自动处理PV目录权限问题。
2. 跨节点迁移PV前保证MySQL Pod正常停止，避免硬删Pod导致数据损坏，迁移后启动时不要修改MySQL相关Secret配置，保持root密码和初始化时一致即可。
3. 可选优化：将探针命令替换为无需密码的版本，避免密码变更导致探针失效：

command: ["sh", "-c", "mysqladmin ping || exit 1"]

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