这是一篇关于作者在 2025 年 3 月 18 日进行的一次临时灾难恢复的经历的文章，主要内容如下：

• 背景：作者在寻找自托管项目管理解决方案时，发现 Teamhood 不错但有订阅限制，于是决定自我托管。作者熟悉自我托管，其集群运行 k3s，包含自定义 CDN 和内部服务等。
• 如何在 k3s 上部署东西：在 k3s 上部署的最直接方式是使用kubectl，但作者不喜欢这种方式，因为它会导致 YAML 清单与 Kubernetes 服务器中的资源状态脱节。作者最终使用rsync来同步文件，实现部署。
• k3s 协调器：k3s 协调器会读取并处理所有.yaml文件，将整个文件集与 k8s 中的现有资源进行比较，并执行必要的 CRUD 操作。但它没有中间的“确认计划”步骤或 dry-run 选项，这使得在处理大规模部署时可能会出现问题。
• 重新格式化：作者更改代码编辑器设置后，使用yq命令重新格式化 YAML 文件，但命令的行为与预期不符，导致所有文件被合并到第一个文件中，引发了一系列问题。
• 后果：k3s 协调器开始创建重复的资源，导致删除操作和服务故障。作者不得不进行灾难恢复，包括备份数据、重新安装系统、设置新的 k3s 集群等。
• 后续工作：在恢复过程中，作者重新部署了各种服务，包括 Traefik、Cert-manager、Minio、k8up 和 Reflector 等，并解决了一些相关的问题，如 CA 证书哈希不匹配、持久卷恢复等。
• 零停机时间部署：作者展示了如何通过 beardist 工具实现零停机时间部署，包括识别引用的镜像、轮询 Forgejo 实例以获取新版本、更新 manifest 并部署到 k3s 集群等。

总的来说，这次灾难恢复过程虽然经历了一些波折，但最终作者成功地恢复了服务，并且没有丢失任何数据。作者也意识到需要一个更好的持续部署解决方案，并表示将更加小心地处理基础设施相关的工作。