Встановлення на Kubernetes за допомогою Helm

Чарт запускає той самий образ, що й Compose, з тими самими змінними середовища.

Секрети насамперед. Чарт ніколи не записує секрет: ви створюєте секрет логінів бази даних (а зі вбудованим Postgres — і його суперкористувача) перед встановленням, і посилаєтесь на необов’язкові (ключі, S3, облікові дані резервної копії, SMTP, токен метрик) за назвою у значеннях.
Postgres: вбудований StatefulSet на тому самому зафіксованому образі pgvector, що й у Compose, для швидкого старту, або ваш власний PostgreSQL 18. З секретом суперкористувача бази даних (або адміністратора провайдера) Job створює ролі та розширення Kept; без нього запустіть керований SQL для Postgres самостійно.
Міграції виконуються в hook Job з логіном власника, тому нова версія не починає роботу, доки міграції не застосовані. Якщо налаштовано ціль резервного копіювання, цей Job спочатку робить знімок перед оновленням. З вбудованим Postgres Job першого встановлення запускається після встановлення, тому не передавайте --wait до першого helm install.
Локально збережені файли розташовуються на томі ReadWriteOnce, тому Deployment використовує стратегію Recreate: під час оновлення старий под зупиняється перед запуском нового. Оновлення без перерв доступні лише зі S3-сховищем файлів і ключами в секреті.
Резервні копіювання виконуються у worker, ніколи не в CronJob: та сама нічна задача, що й у Compose, налаштовується в Admin → Backups або фіксується значеннями чарта.
Розділені Deployments вебу та worker є варіантом; worker працює як одна репліка.
Томи зберігаються під час helm uninstall; видаліть claims самостійно, щоб видалити дані.
helm test запитує запущений Kept за /readyz і /version.

Версія чарта збігається з версією Kept: випуск 1.0.1 публікує чарт 1.0.1. Його публікують як підписаний OCI-артефакт поряд з образом у кожному випуску; див. перевірка випуску.