---
title: "n8n в Kubernetes и Helm: values.yaml, ingress — Nodbot"
source_url: "https://nodbot.ru/hosting/kubernetes-helm/"
canonical_url: "https://nodbot.ru/hosting/kubernetes-helm/"
language: "ru"
content_type: "HostingGuide"
section: "hosting"
generated_at: "2026-05-30"
word_count_source: 1055
---

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

## AI summary

Доскональный разбор n8n в Kubernetes: когда нужен Helm, values.yaml, Postgres/Redis, ingress, storage, workers, task runners, secrets, upgrade и rollback.

## Best used for

Страница объясняет «n8n в Kubernetes и Helm: values.yaml, ingress — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Когда Kubernetes оправдан
- Базовая production-архитектура
- Минимальный values.yaml: что обязательно продумать
- Secrets: что нельзя хранить в открытом values.yaml
- Ingress и webhooks
- Обновление и rollback
- Типовые ошибки Kubernetes-деплоя
- Когда не надо ставить n8n в Kubernetes

## Source outline

# 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 оправдан

- Признак | Docker Compose | Kubernetes/Helm
- Один сервер | лучше | часто избыточно
- Несколько окружений | сложно поддерживать | нормально через namespaces/values
- Много долгих workflow | queue mode вручную | workers масштабируются отдельно
- Центральные секреты и ingress | нужны внешние решения | обычно уже есть в кластере

## Базовая 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
```
Названия полей зависят от конкретного 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

- Сделайте backup PostgreSQL и зафиксируйте текущую версию chart/image.
- Прогоните helm diff , если он используется в вашей команде.
- Обновляйте через helm upgrade с явным values-файлом.
- Проверьте UI, webhook, worker, schedule trigger и credentials.
- Если ошибка критична — helm rollback и восстановление БД только при необходимости.
```
helm upgrade n8n ./chart -n automation -f values.production.yaml
helm history n8n -n automation
helm rollback n8n 12 -n automation
```

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

- Симптом | Причина | Проверка
- pods стартуют, но credentials сломаны | разный или потерянный encryption key | kubectl get secret , сравнить env main/worker
- executions висят queued | workers не подключены к Redis | логи worker pod, Redis host/secret
- webhook возвращает 404/502 | ingress/service/WEBHOOK_URL не совпали | описание ingress, service port, n8n production URL
- Python/Code node нестабилен | task runners не изолированы или не включены | проверить runner mode и sidecar

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

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

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

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

## Операционный runbook для self-hosted

Для темы «n8n в Kubernetes и Helm» важно разделять настройку и эксплуатацию. Настройка отвечает на вопрос “запустилось ли”, эксплуатация — “сможем ли мы восстановиться, обновиться и расследовать инцидент без потери credentials и execution history”.

Перед изменениями проверьте бэкап базы, значение N8N_ENCRYPTION_KEY, состояние volume, логи web-процесса и worker-процесса. Главный риск — поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key.

- Слой | Что зафиксировать | Зачем
- Вход | состояние контейнеров, очередь, переменные окружения, volume и последние строки логов | позволяет повторить проблему без доступа к production-секретам
- Контроль | restart_count, memory_usage, queue_depth, worker_concurrency, failed_executions | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «n8n в Kubernetes и Helm» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
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
```

### Критерий готовности

- есть свежий backup базы и проверено значение N8N_ENCRYPTION_KEY
- web, worker, queue и database используют согласованные переменные окружения
- после изменения проверены логи, healthcheck и запуск критичных workflow
- записан rollback-план с командами и ответственным

## Эксплуатационный контекст для self-hosted n8n

Страницу «n8n в Kubernetes и Helm: values.yaml, ingress, workers, secrets и обновления» лучше читать как часть production-карты self-hosted n8n. Любое изменение инфраструктуры должно иметь владельца, план проверки, понятный rollback и наблюдаемость. Перед применением на VPS или в Kubernetes зафиксируйте текущую версию n8n, способ запуска, путь к данным, переменные окружения и место хранения backup.

Главный риск self-hosted установки — исправить один симптом и не заметить побочный эффект: потерю credentials, рост execution data, недоступность webhooks, ошибку reverse proxy или зависшие workers. Поэтому после изменений проверяйте не только UI, но и healthcheck, production webhook URL, очередь, базу данных, логи контейнера и успешный тестовый execution.

### Ops-чеклист перед изменением

- Сделайте backup базы, файлового хранилища и критичных env-переменных.
- Проверьте, что есть понятный rollback и окно обслуживания.
- Сравните логи до и после изменения: 4xx/5xx, latency, memory, disk, stalled jobs.
- Проведите тест webhook, scheduled workflow и ручного запуска.
Для команды полезно хранить эту проверку рядом с runbook: что изменяли, кто подтвердил результат, какие метрики смотрели и какое условие считается неуспешным релизом.

### Связанные материалы для эксплуатации

- Self-hosted n8n — открыть связанный материал для проверки контекста.
- Логи и мониторинг — открыть связанный материал для проверки контекста.
- Backup и update — открыть связанный материал для проверки контекста.
- Launch checklist — открыть связанный материал для проверки контекста.

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.