n8n 在 EKS 從社群 Helm chart 遷到官方 chart：main pod 不再需要磁碟
CNCF Blog（Fairwinds，Husne Ozmen） · 2026-10-16
在 EKS 上跑生產環境的 n8n，從社群 Helm chart 換成官方 Helm chart，不能用 in-place Helm upgrade，只能整個 cutover。原因是 main pod 的工作負載模型從 StatefulSet 變成 Deployment，磁碟掛載方式也跟著變。
Fairwinds 的團隊先用社群 chart 跑了約一年，再把 Helm release 換掉，同時保留資料庫、佇列、物件儲存、IAM role 與 secrets。
原本的問題
n8n 單一容器加 SQLite 只適合試用。生產環境需要 worker、webhook processor、PostgreSQL、Redis、物件儲存、外部 secrets、ingress 路由，還要有能保留 workflow 歷史的升級計畫。
社群 chart 支援 queue mode、額外的 ingress 設定，以及以 StatefulSet 部署的 main pod，符合當時的架構需求。但跑了約一年後，維護不受支援的功能與本地 patch 愈來愈難說服自己，所以改用有持續維護的官方 chart。
他們的部署架構
- queue mode：main 管理 workflow 資訊與觸發，worker 從 Redis 佇列取工作執行。
- 專用的 webhook processor 處理生產 webhook，ingress 依流量分流：公開 webhook 走 internet-facing 負載平衡器，內部 webhook 走私有 hostname。
- PostgreSQL 存 workflow 與執行資料，Redis 存佇列，S3 存二進位檔案。
- 多 replica 的 main pod 屬於 Enterprise 授權功能，所以共用設定與加密金鑰放在 AWS Secrets Manager，再用 External Secrets Operator（ESO）同步成 Kubernetes Secrets。
為什麼無法 in-place 升級
社群 chart 讓 main 以 StatefulSet 執行，每個 replica 一個 PV，這樣在 AWS gp3 的 ReadWriteOnce（RWO）EBS 磁碟上跑多個 main pod 才不會遇到 multi-attach 問題。官方 chart 在他們的設定中，則是把 main 當 Deployment，並依賴單一共用 PVC。
| 社群 chart | 官方 chart（他們的設定） | |
|---|---|---|
| main 工作負載 | StatefulSet | Deployment |
| main 儲存 | 每個 replica 一個 PV | 單一共用 PVC |
| gp3 RWO 的影響 | 各自掛載，無衝突 | 無法同時掛到跨節點的多個 main pod |
因此 in-place Helm upgrade 不適用，團隊把遷移視為完整 cutover。
關鍵決策：關掉 main 的 persistence
共用 PVC 是主要設計問題。團隊先盤點 main pod 磁碟上到底存了什麼：PostgreSQL 有 workflow 與執行資料，Redis 有佇列任務，S3 有檔案，Secrets Manager 有加密金鑰與應用程式 secrets。磁碟上沒有任何需要保留的東西。
既然狀態都在外部，替換的 main pod 啟動後重新連線即可，不必依賴 pod 專屬磁碟。所以他們在官方 chart 部署中完全關閉 main persistence，同時也繞開了 RWO 的限制。
切換流量的做法
被替換的只有 Helm release，PostgreSQL、Redis、S3、IAM 與 secrets 都沒動，其餘資源由新 chart 的 values 重建。正式遷移前，他們做了四件事：
- 在非生產環境測試 rollback。
- 替資料庫做 snapshot。
- 把 secrets 存一份到另一個位置。
- 不更動 n8n image 版本：版本升級可能觸發資料庫 migration，他們要把資料庫排除在 cutover 之外。
非生產環境用還原的資料庫 snapshot 驗證：pod 健康、已知 workflow 能跑完、必要的端點可連線，並確認 rollback 可行，才碰生產流量。
影響範圍
正在用社群 chart 跑 n8n 的團隊，若打算換官方 chart，要先檢查兩件事：main pod 磁碟上有沒有真正需要保留的資料，以及你的 StorageClass 是不是 RWO。若狀態都已在外部服務，可以照這條路關掉 persistence，用 cutover 取代 in-place 升級。
文章未公布遷移的停機時間或實際切換耗時，也沒有提供效能數據。作者另在 n8n-sample 公開了官方 chart 的 values 範例，涵蓋外部 Postgres/Redis、queue mode 加 HPA、資源、ingress/webhook 與選用的 task runner。
原始來源：CNCF Blog、n8n-sample