Kubernetes环境下WordPress共享卷场景无停机升级的疑问

嘿，我完全懂你现在的头疼点——当新旧WordPress Pod共用同一个存储卷时，核心代码版本不一致肯定会出各种奇怪的问题，毕竟WP的文件结构和依赖会随着版本变化。下面给你几个经过实践验证的解决方案，按需选择：

方案一：双存储卷+蓝绿部署（零风险，适合对稳定性要求高的场景） #

这种方法通过隔离新旧版本的代码存储，彻底避免冲突：

• 首先创建一个新的PersistentVolumeClaim（PVC），专门用来存放WordPress 4.9的核心代码和配置。你可以用一个临时Pod挂载这个新PVC，把WP 4.9的代码同步进去（比如通过kubectl cp或者在临时Pod里用wget下载官方包解压）
• 基于新PVC创建一个全新的Deployment，使用WordPress:4.9-apache镜像，挂载这个新存储卷
• 验证新Deployment的Pod正常运行后，通过Service或者Ingress逐步切换流量到新实例：
  • 如果用Service，直接修改它的selector字段，把旧Deployment的标签换成新的，或者用流量分割逻辑设置权重
  • 如果用Ingress，可以配置多个后端服务，调整权重逐步把流量切过去
• 确认新版本完全稳定后，再删除旧的4.8版本Deployment和对应的PVC

方案二：重构为无状态架构，核心代码打包进镜像（最简洁，长期维护友好） #

你现在的架构是把WP核心代码放在共享卷里，其实可以把核心代码打包进自定义镜像，共享卷只保留用户生成的内容（比如uploads、自定义主题/插件），这样升级时就不会有代码冲突：

• 构建自定义WordPress镜像：

  FROM wordpress:4.9-apache
  # 复制你的自定义主题、插件到镜像中（可选）
  COPY ./your-theme /var/www/html/wp-content/themes/your-theme
  COPY ./your-plugin /var/www/html/wp-content/plugins/your-plugin
  

• 修改现有Deployment：移除原来挂载WP核心代码的卷配置，只保留挂载wp-content/uploads的卷（可以用subPath指定挂载路径，避免覆盖镜像里的核心代码）
• 执行滚动升级：

  kubectl set image deployment/your-wordpress-deployment wordpress=your-custom-wp-image:4.9
  

  Kubernetes会自动逐个替换旧Pod，旧Pod运行4.8镜像（核心代码在镜像内），新Pod运行4.9镜像，共享卷只存用户数据，完全不会冲突
• 注意：如果之前共享卷里已经存了WP核心代码，升级前要清理掉这些文件，避免卷里的旧代码覆盖镜像里的新代码

关键注意事项 #

• 备份优先：无论用哪种方案，升级前一定要备份共享卷里的所有数据！可以用kubectl cp把Pod内的卷内容复制到本地，或者利用Kubernetes的存储快照功能生成快照
• 数据库升级：WordPress升级到新版本后，第一次启动会提示升级数据库。你可以手动访问WP后台完成升级，或者在自定义镜像里加入脚本自动执行这个步骤
• 兼容性验证：升级前要确认你的自定义主题、插件是否兼容WordPress 4.9，避免升级后出现功能异常

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