DigitalOcean Kubernetes集群中WordPress持久化卷异常问题求助

一、先搞懂你遇到的错误到底是什么意思 #

你看到的几个错误是连锁反应，核心问题出在持久化卷（PV）损坏上：

• 0/2 nodes are available: 2 pod has unbound immediate PersistentVolumeClaims：K8s找不到能绑定PVC的可用PV，本质是PV对应的存储卷已经无法被节点识别
• AttachVolume.Attach failed + formatting disk failed：DigitalOcean的块存储卷无法挂载到节点，格式化命令找不到磁盘设备，说明卷的文件系统已经损坏，甚至底层存储设备出现异常
• Readiness probe failed: 404：这是前面存储问题的结果——WordPress Pod连存储都挂载不了，自然无法启动服务，探针就返回404了

二、为什么删除默认插件会触发这个？ #

Bitnami的WordPress Helm Chart默认把WordPress核心文件、插件、主题全部放在同一个持久化卷（默认是wp-data PVC）里。当你删除默认插件时，如果刚好遇到Pod重启、文件锁未释放，或者操作过程中存储卷出现IO异常，就可能导致文件系统损坏。DigitalOcean的块存储在检测到文件系统损坏时，会出现无法挂载、设备找不到的情况，进而触发K8s的PVC绑定失败。

这绝对不是正常行为，更可能是以下几个因素共同作用的结果：

1. Bitnami Chart默认的存储设计（单PV存放所有WP内容）增加了存储损坏的风险
2. 你使用的K8s 1.22.8版本较旧（已经停止维护），存在一些存储挂载相关的已知Bug
3. DigitalOcean块存储在处理文件系统错误时的异常表现

三、快速恢复网站的步骤 #

如果你的网站需要尽快恢复，可以按以下操作来：

1. 先备份现有数据（如果还能访问）：
   先启动一个调试Pod尝试挂载损坏的PVC，把数据复制出来：

   kubectl run debug-pod --image=ubuntu --command -- sleep 3600
   kubectl cp debug-pod:/bitnami/wordpress ./wp-site-backup
   

   如果PVC完全无法挂载，直接去DigitalOcean控制台找到对应的块存储卷，创建快照备份。

2. 删除损坏的PV/PVC，重新部署：

   # 删除WordPress的PVC（对应的PV会被自动删除）
   kubectl delete pvc wp-data-wordpress-0
   # 用Helm重新部署WordPress，会自动创建新的PVC和PV
   helm upgrade wordpress bitnami/wordpress --reuse-values
   

   注意：这一步会清空现有数据，所以一定要先完成备份！

3. 把备份数据恢复到新的存储卷：
   等新的WordPress Pod启动后，把备份的文件复制回去：

   kubectl cp ./wp-site-backup <your-new-wordpress-pod-name>:/bitnami/wordpress
   # 重启Pod让配置生效
   kubectl rollout restart deployment wordpress
   

四、长期避免这个问题的方案 #

1. 升级你的K8s集群：1.22.8是已经停止维护的旧版本，升级到1.24及以上版本可以修复很多存储相关的Bug，提升稳定性。
2. 调整Bitnami Chart的存储配置：
   • 考虑把插件、主题和WordPress核心文件分开存储，比如用单独的PVC存放插件，或者用emptyDir临时存储非核心插件，降低核心存储卷损坏的风险。
   • 在values.yaml里开启卷权限修复，避免文件权限问题导致的异常：

     wordpressVolumePermissions:
       enabled: true
     persistence:
       enabled: true
       # 条件允许的话，改用ReadWriteMany类型的存储（比如DO的NFS卷），减少单点故障
     

3. 安全删除插件的正确姿势：
   不要直接在后台删除插件，先停止Pod再操作，避免文件系统在读写过程中被破坏：

   # 先停止WordPress Pod
   kubectl scale deployment wordpress --replicas=0
   # 启动调试Pod挂载存储卷，删除目标插件
   kubectl run plugin-cleanup --image=ubuntu -v wp-data-wordpress-0:/bitnami/wordpress --command -- rm -rf /bitnami/wordpress/wp-content/plugins/<plugin-name>
   # 重新启动WordPress Pod
   kubectl scale deployment wordpress --replicas=2
   

五、这算不算Bug？ #

更准确地说，这是边缘场景下的兼容性问题，不是正常行为：

• Bitnami Chart默认的单PV设计虽然简单，但确实增加了存储损坏的风险
• 旧版K8s的存储挂载逻辑在处理文件系统错误时不够健壮
• DigitalOcean块存储在检测到损坏时的处理方式导致设备无法被K8s识别

你可以去Bitnami的GitHub仓库提交Issue，详细描述触发步骤（比如删除的是哪个默认插件、操作的具体流程），帮助他们优化这个场景下的兼容性。

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