1. 前言
尽管我平时不在这里写文章（严格上这文章在这里跑题了），但鉴于这次对于架构的变更有点大（而且整个site down了快两个星期），最终还是决定在这里描述一下站点的新架构与迁移的时候遇到的事情，本文也可兼作功能测试。
2. 关于之前的架构
站点之前运行在一个非常典型的配置上，Nginx-PHP-FPM-MySQL的经典结构。但在版本演进及升级过程中遇到了一定的问题，例如MySQL 5.7-8.0的不兼容升级，PHP 7.4的新特性等等问题（本质还是WordPress太emmmm了），也由于之前的站点运行Arch Linux，各种组件的更新都比WordPress动作快一些。种种问题决定了维护成本相对较高，容器化的计划也是一直在路上（咕）。
3. 新架构 – Kubernetes容器化
站点的真正迁移始于下线，因为需要在原来的托管商处测试新内容，运行站点的VM被扩容到了一个不太好接受的价格。既然删除已经不可避，迁移计划也自然的从咕咕咕项目变成了一口需要立即动手的锅。
3.1 备份及下线
WordPress并不支持SQLite3数据库，而MySQL数据库不同版本间备份唯一合适的方案是导出既有库，恢复到新数据库内。WordPress自身数据则存储于 wp_content 目录下，该目录及整个Webroot也一并进行了备份。之后VM被回收，站点正式进入了望不到头的Downtime。
3.2 容器化
利用新服务商的基础设施，我们可以通过更低的成本实现存储及网络的方案。一个船新的、基于Kubernetes容器集群的架构在两周后1变成了可部署的YAML。WordPress和MySQL位于两个不同的Deployment中，通过Service互相连接，最后通过Ingress导出到外部。数据库的数据目录及WordPress的上传、插件、主题目录作为Persistent Volume，由外部的存储服务提供。导入后服务正常上线。
3.3 备份恢复
容器中的数据是易失的，因此Persistent Volume（PV）解决了由于容器重建等原因导致的数据丢失。但因此恢复备份需要通过容器对PV内的数据进行操作。将备份拷贝进容器后按照相同的步骤进行数据库导入、文件夹替换等操作即可。
4. 总结及故障排查
0202年了，WordPress依然不能良好的支持位于TLS Terminator后的配置，需要通过修改配置文件的方式强行指定。附图作为现在架构的参考。
5. 注释
1: 那时的运维还没有找到在上班期间摸鱼的合适方案