在 EKS 上部署、维护和迁移生产环境 n8n
内容提要
Fairwinds 将 n8n 从社区 Helm chart 迁移到官方 chart。n8n 生产环境需要队列模式、PostgreSQL、Redis、S3 和密钥管理。官方 chart 将主节点改为 Deployment 并依赖共享 PVC，与原有 StatefulSet 不兼容，因此采用整体切换。由于状态都存储在数据库、Redis、S3 和 Secrets Manager 中，他们禁用了主节点持久化，保留数据与密钥，先测试回滚再迁移。
延伸解读
迁移决策的关键：存储与工作负载模型
从社区 chart 迁移到官方 chart 的核心障碍是主节点工作负载模型的变化。社区 chart 使用 StatefulSet 并为每个副本分配独立持久卷，而官方 chart 将主节点改为 Deployment 并依赖单个共享 PVC。在 AWS gp3 RWO 卷上，共享 PVC 无法跨节点挂载到多个主 Pod，因此原地 Helm 升级不可行，只能整体切换。这提醒我们，迁移前必须确认存储访问模式与目标 chart 的兼容性。
状态外置让主节点无状态化成为可能
文章指出，n8n 生产环境的关键状态并不在主节点磁盘上：PostgreSQL 保存工作流与执行数据，Redis 保存队列任务，S3 保存二进制文件，AWS Secrets Manager 保存加密密钥和应用密钥。因此团队在官方 chart 部署中直接禁用了主节点持久化。这一判断基于对磁盘内容的实际检查，而非假设。对于类似的有状态应用，先梳理状态分布，再决定是否保留持久卷，是降低迁移复杂度的有效方法。
安全迁移的验证步骤与风险控制
迁移前，团队在非生产环境用恢复的数据库快照进行了完整测试，验证了 Pod 健康、已知工作流完成和端点可达，并提前测试了回滚。同时，他们保留了数据库、对象存储、IAM 角色和密钥，只重建了 Helm 发布。特别值得注意的是，他们没有变更 n8n 镜像版本，以避免触发数据库迁移，从而将数据库排除在切换风险之外。这些步骤为类似迁移提供了可复用的检查清单。
Q&A
n8n 生产环境需要哪些组件？
需要 workers、webhook 处理器、PostgreSQL、Redis、对象存储、外部密钥管理、入口路由，以及能保留工作流历史的升级方案。
为什么 Fairwinds 从社区 Helm chart 迁移到官方 chart？
社区 chart 曾帮助他们进入生产，但维护不支持的功能和本地补丁变得难以证明其合理性。官方 chart 提供持续维护和活跃社区支持，为未来升级提供更清晰的路径。
官方 chart 与社区 chart 在主要工作负载模型上有何不同？
社区 chart 将主 Pod 作为 StatefulSet 运行，每个副本一个持久卷；官方 chart 将主节点作为 Deployment，并依赖单个共享 PVC 进行持久化。
迁移过程中如何确保状态不丢失？
他们检查了磁盘上的存储：PostgreSQL 保存工作流和执行数据，Redis 保存队列作业，S3 保存文件，AWS Secrets Manager 保存加密密钥和应用密钥。主 Pod 卷上没有需要持久化的内容，因此禁用了主节点持久化，并保留了数据库、Redis、S3 和 Secrets Manager 中的状态。
迁移前做了哪些安全准备？
在非生产环境测试回滚、拍摄数据库快照、将密钥保存到次要位置，并且不更改 n8n 镜像版本以避免触发数据库迁移。
迁移后哪些组件保持不变？
PostgreSQL、Redis、S3、IAM 角色和密钥保持不变，Helm release 发生了变化。
