n8n в Kubernetes и Helm: values.yaml, ingress, workers, secrets и обновления ¶

Обновлено: 2026-05-29

Kubernetes для n8n нужен не всем. Если у вас один VPS и несколько workflow, Docker Compose проще, дешевле и предсказуемее. Kubernetes оправдан, когда уже есть кластер, несколько окружений, централизованные ingress/secrets/monitoring, отдельная команда эксплуатации и требование масштабировать workers независимо от main instance.

Главная ошибка — переносить хаотичный compose в Kubernetes без архитектуры. Сначала решите, где живут PostgreSQL, Redis, файловое хранилище, secrets, ingress и backup. Только после этого пишите values.yaml.

Когда Kubernetes оправдан ¶

Базовая production-архитектура ¶

Ingress Controller → n8n main pod → PostgreSQL
                         │
                         ├→ Redis queue
                         ├→ n8n worker pods
                         └→ task runner sidecar/external runners

PostgreSQL и Redis лучше держать как managed-сервисы или отдельные stateful-компоненты с backup. Не стоит хранить критичные данные только в ephemeral volume pod.

Минимальный values.yaml: что обязательно продумать ¶

main:
  replicaCount: 1

worker:
  enabled: true
  replicaCount: 2

config:
  executionsMode: queue
  webhookUrl: https://n8n.example.ru/
  genericTimezone: Europe/Moscow

externalPostgresql:
  host: postgres.example.internal
  database: n8n
  user: n8n
  existingSecret: n8n-postgres-secret

externalRedis:
  host: redis.example.internal
  existingSecret: n8n-redis-secret

ingress:
  enabled: true
  className: nginx
  hosts:
    - host: n8n.example.ru
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: n8n-tls
      hosts: [n8n.example.ru]

secret:
  existingSecret: n8n-app-secret

Названия полей зависят от конкретного Helm chart, поэтому используйте этот пример как чеклист, а не как универсальный values-файл. Важна не строка сама по себе, а то, что у вас явно заданы: внешний URL, БД, Redis, encryption key, ingress, secrets и workers.

Secrets: что нельзя хранить в открытом values.yaml ¶

• N8N_ENCRYPTION_KEY
• пароль PostgreSQL
• пароль Redis, если включён auth
• SMTP/API токены
• OAuth client secret

Секреты храните в Kubernetes Secret, sealed-secrets, External Secrets Operator или корпоративном vault. Сам values.yaml должен ссылаться на secret, а не содержать секретные значения.

Ingress и webhooks ¶

Для n8n в Kubernetes особенно важно, чтобы внешний адрес совпадал с тем, что видят webhook-провайдеры. После деплоя откройте Webhook node: production URL должен быть https://n8n.example.ru/webhook/.... Если внутри отображается service name, cluster.local или http, значит неправильно заданы WEBHOOK_URL, forwarded headers или ingress.

curl -I https://n8n.example.ru
curl -X POST https://n8n.example.ru/webhook/k8s-smoke-test \
  -H 'Content-Type: application/json' \
  -d '{"platform":"kubernetes","check":"webhook"}'

Обновление и rollback ¶

1. Сделайте backup PostgreSQL и зафиксируйте текущую версию chart/image.
2. Прогоните helm diff, если он используется в вашей команде.
3. Обновляйте через helm upgrade с явным values-файлом.
4. Проверьте UI, webhook, worker, schedule trigger и credentials.
5. Если ошибка критична — helm rollback и восстановление БД только при необходимости.

helm upgrade n8n ./chart -n automation -f values.production.yaml
helm history n8n -n automation
helm rollback n8n 12 -n automation

Типовые ошибки Kubernetes-деплоя ¶

Когда не надо ставить n8n в Kubernetes ¶

Если у вас нет мониторинга кластера, процесса обновлений, backup PostgreSQL и человека, который понимает ingress/secrets/storage, Kubernetes не сделает n8n надёжнее. Он просто перенесёт ошибки из compose в более сложную среду.

Связанные инструкции ¶

• Queue mode и workers
• Task runners для Code node
• External secrets
• Production release checklist

docker compose ps
docker compose logs --tail=200 n8n
docker compose logs --tail=200 n8n-worker
printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_'
# перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY