Host n8n trên Kubernetes đúng cách

Kubernetes

Phùng Minh Châu

1711

01-11-2025

Dưới đây là một hướng dẫn thực tế, an toàn cho việc mở rộng n8n với worker, webhooks và các bản upgrade mà không gặp nhiều trở ngại.

Cùng khám phá cách host n8n trên Kubernetes, với queue mode, worker, Postgres, Redis, tự động mở rộng và bảo mật ingress - để có thể thực hiện horizontal scale up ổn định.

Bạn không cần đến một cụm 40 node để có khả năng của mức “enterprise”. Bạn chỉ cần một thiết lập n8n có thể chịu được lưu lượng truy cập tăng đột biến, các pod bị lỗi. Hãy cùng thử nghiệm với triển khai sau đây nhé.

Tại sao Kubernetes phù hợp với n8n?

n8n là sự lựa chọn hoàn hảo để automate công việc thực tế trên nhiều ứng dụng. Tuy nhiên, khi luồng công việc tăng lên, việc cài đặt một single container sẽ gây ra tình huống các job chạy chậm và lâu. Trong khi đó Kubernetes mang lại:

• Horizontal scale (bạn có thể nhân rộng các worker riêng biệt).
• Self-healing (khởi động lại pod, rolling updates).
• Persistent storage cho database và tệp nhị phân.
• Network policy & TLS tích hợp sẵn với ingress stack của bạn

“Scalable n8n” thực sự có ý nghĩa như thế nào?

Ở quy mô lớn, n8n nên chạy ở queue mode:

• Một main service sẽ serve UI, REST API và schedules executions.
• Các Webhook handlers chấp nhận nhanh các HTTP triggers đến và đưa công việc vào queue.
• Workers pull jobs từ queue và chạy các luồng song song.
• Redis cung cấp Bull queue.
• Postgres lưu trữ state, credentials, và executions.

“Scalable n8n” có nghĩa là scale các worker và bản sao webhook một cách độc lập, đồng thời giữ cho pod chính ổn định.

Bố cục Tham khảo 

Hãy nghĩ đến năm đơn vị có thể triển khai trong cụm của bạn:

1. Postgres: stateful với 1 PVC, backup hàng ngày.
2. Redis: stateless nhưng được replicated để đảm bảo tính khả dụng.
3. n8n-main: 1–2 replicas cho UI/API/scheduler.
4. n8n-webhook: multiple replicas phía sau ingress để đáp ứng lưu lượng đột biến.
5. n8n-worker: một autoscaled Deployment dựa trên mức sử dụng CPU hoặc độ dài queue.

Networking rất đơn giản: ingress → n8n-webhook và n8n-main; workers và main giao tiếp với Redis và Postgres thông qua các ClusterIP services.

Prereqs và Secrets

Tạo secrets ngay từ đầu. Bạn cần tối thiểu:

N8N_ENCRYPTION_KEY (32+ ký tự)

Thông tin đăng nhập database (DB_POSTGRESDB_*)

Kết nối Redis (QUEUE_BULL_REDIS_*)

N8N_HOST, N8N_PROTOCOL và WEBHOOK_URL (public URL)

Tùy chọn: Xác thực cơ bản để truy cập giao diện quản trị, cookie an toàn, SMTP

Ví dụ về Kubernetes:

Postgres và Redis (nhanh, phù hợp với môi trường production)

Mẹo về Postgres

Sử dụng StatefulSet với PVC (lớp SSD).

Kích hoạt base backups hàng ngày và lưu trữ WAL (tool cluster backup của bạn vẫn sử dụng được bình thường).

Hãy đặt giới hạn kết nối (max_connections) một cách hợp lý, vì n8n không sử dụng quá nhiều kết nối đến cơ sở dữ liệu.

Mẹo về Redis

Nếu hạ tầng cho phép, hãy thiết lập cluster hoặc replica để tăng tính sẵn sàng; nếu không, một máy chủ chính duy nhất có bật persistence cũng đủ cho giai đoạn MVP.

Giới hạn bộ nhớ và thêm chính sách loại bỏ (eviction policy); các jobs chỉ tồn tại trong thời gian ngắn.

Nếu bạn đã có managed Postgres/Redis, hãy trỏ n8n đến những máy chủ đó và tiếp tục.

Deploy n8n Main (UI/API/Scheduler)

Mở dịch vụ này ra bên ngoài bằng ClusterIP service và thiết lập ingress rule cho các đường dẫn / và /rest.

Triển khai các Webhook handler (hỗ trợ khi tải tăng cao đột biến).

Ingress nên được cấu hình để định tuyến các đường dẫn khớp với biểu thức ^/webhook.* và ^/webhook-test.* đến dịch vụ này, nhằm đảm bảo rằng các yêu cầu webhook đến (incoming triggers) không phải chờ đợi hoặc bị ảnh hưởng bởi các UI podsđang quá tải.

Deploy Workers (điều chỉnh khả năng mở rộng)

Việc scale dựa trên CPU là một bước khởi đầu đơn giản. Nếu bạn export độ dài Bull queue sang Prometheus, bạn có thể scale dựa trên "các job đang chờ", một giải pháp tối ưu cho workloads lớn.

Ingress và TLS

Định tuyến lưu lượng theo đường dẫn:

/ and /rest → n8n-main

/webhook and /webhook-test → n8n-webhook

Hãy cấu hình hệ thống sao cho việc mã hoá TLS được xử lý tại ingress controller. Đặt N8N_PROTOCOL=https để n8n biết rằng kết nối là an toàn, gán N8N_HOST bằng hostname public của bạn, và đặt WEBHOOK_URL giống với cùng base URL để các đường dẫn callback được tạo ra đúng định dạng.

Persistence và Backups

Postgres: PVC với snapshots + logical backups.

Dữ liệu nhị phân: Nếu bạn tải tệp lên các workflows, hãy trỏ n8n object storage (S3-compatible)  thông qua các environment variables để các worker không cần phải shared disks.

Workflow exports: Sau mỗi lần thay đổi, hãy xuất (export) các định nghĩa workflow ra kho lưu trữ mã nguồn (repository) hoặc artifact store để có thể rollback khi cần.

Observability dành cho cả người không chuyên 

Bật N8N_METRICS=true và thu thập dữ liệu thông qua Prometheus của bạn.

Chuyển logs vào logging stack; gắn tag cho pod theo role.

Thêm workflow “run log” đơn giản để ghi lỗi vào một trang tính hoặc bảng ở chế độ chia sẻ và gửi ping đến kênh Slack bằng tiếng Anh đơn giản. Mọi người cũng có thể sẽ đọc.

Áp dụng PodDisruptionBudget cho các pod chính (main) và pod webhook, để đảm bảo việc triển khai (rollout) diễn ra ổn định, có kiểm soát, không làm gián đoạn dịch vụ đang chạy.

Điều chỉnh Throughput 

Worker concurrency (N8N_CONCURRENCY): bắt đầu từ 3–5, đo memory, tăng dần.

Chia nhỏ các job nặng: Đối với các bước ngốn CPU (ví dụ: chuyển đổi CSV lớn), hãy tạo một dedicated n8n-worker-highcpu Deployment với giới hạn lớn hơn và một queue riêng (mô hình nâng cao).

Webhook replicas: Duy trì một vài bản sao webhook đang hoạt động (“hot replicas”) ngay cả khi lưu lượng thấp.

Database pragmatism: N8N nhẹ về đọc; nhờ đó Postgres IO nhanh và latency thấp. Điều này khắc phục hiệu quả các lỗi execution chậm "ngẫu nhiên" hơn bất kỳ tối ưu nào khác.

Rolling updates: Sử dụng maxUnavailable=0 cho webhook và main để không bao giờ bỏ lỡ các triggers trong quá trình deploy.

Các sự cố phổ biến và biện pháp khắc phục

Webhooks 404 sau khi deploy → WEBHOOK_URL không khớp hoặc ingress path đến sai dịch vụ.

Duplicate executions → thiếu các idempotency keys trong workflows; bổ sung một bước kiểm tra định danh duy nhất (fingerprint validation) trước khi chạy job chính, nhằm xác minh xem một bản ghi có đặc điểm trùng lặp (ví dụ: cùng ID, email hoặc timestamp) đã tồn tại trong hệ thống hay chưa. Nếu phát hiện trùng, workflow sẽ tự động bỏ qua hoặc ghi nhận trạng thái “đã xử lý”.

Worker không hoạt động → DNS Redis sai hoặc network policy bị chặn; xác minh QUEUE_BULL_REDIS_* đã được giải quyết trong các pod worker.

Random OOM → một workload phải xử lý payload quá lớn; có thể giới hạn kích thước payload được phép xử lý hoặc chuyển bước đó sang object storage.

Lời kết: Xây nền tảng vững chắc cho hệ thống automation bền vững

Có thể bạn sẽ băn khoăn: “Liệu việc thiết lập hạ tầng bài bản như vậy có quá mức cần thiết cho một nhóm nhỏ hay không?” Câu trả lời là không hề quá — mà ngược lại, đây chính là bước đi giúp bạn tránh được rất nhiều rủi ro trong tương lai.

Bản hướng dẫn ở trên không chỉ giúp nhóm vận hành có được một quy trình triển khai ổn định và dễ lặp lại, mà còn mở ra lộ trình mở rộng linh hoạt khi nhu cầu tăng lên. Khi hệ thống được xây dựng trên một nền tảng rõ ràng và có tổ chức, bạn sẽ không cần phải loay hoay tái cấu trúc hay “chữa cháy” mỗi khi lưu lượng tăng đột biến.

Hãy bắt đầu từ những bước nhỏ: triển khai một node pool, một vài worker, cùng với kế hoạch sao lưu an toàn. Khi khối lượng công việc hoặc lưu lượng người dùng tăng, bạn chỉ cần mở rộng dần — quy trình vẫn giữ được sự ổn định, không cần đến các biện pháp tạm thời.

Cuối cùng, đây không chỉ là câu chuyện về kỹ thuật, mà còn là tư duy xây dựng hệ thống bền vững: bắt đầu đơn giản, duy trì nhất quán và sẵn sàng phát triển khi thời điểm đến.

Tham khảo: Medium