Бэкенд-сервисы и функции без Kubernetes
Запускайте постоянные сервисы как контейнерные приложения из Dockerfile или готового образа — с Postgres и Redis из шаблонов, приватной сетью между сервисами, томами, релизами и откатом, — а HTTP-обработчики, задачи по расписанию и фоновую работу держите рядом в функциях и пайплайнах. Одно рабочее пространство и никакого Kubernetes в роли ежедневной панели управления.
Обновлено: 2026-06-28
Кратко
Суть ответа
Бэкенд-сервисы и функции без Kubernetes. Inquir запускает обе формы бэкенд-работы в одном рабочем пространстве. Сервисы, которые должны работать постоянно, разворачиваются как контейнерные приложения: Dockerfile или образ, релизы, закреплённые по digest и прошедшие вашу проверку работоспособности, откат, тома, Postgres или Redis из шаблона и приватный адрес у каждого приложения. Короткая работа разворачивается как функции за маршрутами шлюза и триггерами пайплайнов. Ни то, ни другое не требует Kubernetes-манифестов, а секреты, логи и история общие.
Когда подходит
- Нужна структура уже сейчас, без найма платформенной команды.
- Нагрузки естественно ложатся на обработчики без состояния с явным вводом-выводом или на контейнерные сервисы.
На что обратить внимание
- Кто-то должен владеть бэкапами etcd, причудами CNI и сертификатами ingress до первой возможности для клиента.
- GitOps и Helm сильны, но тяжелы для чтения, когда нужно просто «запускать эту функцию каждую ночь».
Нагрузка и где ломается
Почему команды ищут деплой без Kubernetes
Kubernetes — уважаемый ответ для «настоящей» инфраструктуры, но большинству продуктов в первую очередь нужны HTTP-входы, запуск по расписанию и место для фоновой работы. Поэтому команды и ищут способ развернуть функции без Kubernetes, пока сложность действительно не потребует кластера.
Прыжок сразу в кластер, пока эти основы не работают, тормозит раннюю команду, а полный отказ от структуры означает, что через полгода shell-скрипты придётся переписывать в микросервисы.
Компромиссы
Почему «сначала Kubernetes» тяжело для простых бэкендов
Кто-то должен владеть бэкапами etcd, причудами CNI и сертификатами ingress до первой возможности для клиента.
GitOps и Helm сильны, но тяжелы для чтения, когда нужно просто «запускать эту функцию каждую ночь».
Как помогает Inquir
Управляемая середина
Inquir запускает обе формы бэкенд-работы в одном рабочем пространстве. Сервисы, которые должны работать постоянно, разворачиваются как контейнерные приложения: Dockerfile или образ, релизы, закреплённые по digest и прошедшие вашу проверку работоспособности, откат, тома, Postgres или Redis из шаблона и приватный адрес у каждого приложения. Короткая работа разворачивается как функции за маршрутами шлюза и триггерами пайплайнов. Ни то, ни другое не требует Kubernetes-манифестов, а секреты, логи и история общие.
Если позже понадобится более крупный оркестратор, привычки небольших обработчиков и явных триггеров переносятся чище, чем монолит, нарезанный в спешке.
Что вы получаете
Что вы сохраняете без Kubernetes
Деплой функций из браузера
Правьте, сохраняйте и разворачивайте обработчики без локальной сборки Docker на каждое изменение.
API-шлюз для бэкенд-функций
Централизуйте авторизацию и правила путей для входящего HTTP на шлюзе, а не в каждом сервисе заново.
Задачи и пайплайны для фона
Моделируйте асинхронную работу явно — задачами и шагами пайплайна, а не форками процессов.
Контейнерные приложения без манифестов
inquir apps deploy собирает ваш Dockerfile на платформе или выпускает релиз из готового образа; проверка работоспособности, реплики, тома и порты — настройки релиза, а не YAML.
Что дальше
Как развернуть функции без Kubernetes
Разворачивайте без Kubernetes в роли ежедневной панели управления, когда маршрутов шлюза, функций и триггеров пайплайнов достаточно.
Код
Начните с шаблонов типичных HTTP-обработчиков и фоновых обработчиков и адаптируйте код под свою логику.
Настройка
Подключите маршруты шлюза или триггеры пайплайнов и привяжите секреты к функциям в продукте, а не в git.
Наблюдение
Используйте историю выполнения как обратную связь по надёжности: каждый вызов записан с логами и таймингом.
Пример кода
Фокус остаётся на обработчике
Единица деплоя — код плюс метаданные, а не Helm chart или Kubernetes-манифест на каждый эндпоинт. Обычные маршруты используют простую форму события (path); маршруты в стиле AWS — rawPath.
export async function handler(event) { const path = event.path ?? event.rawPath ?? ''; return { statusCode: 200, body: JSON.stringify({ path }), }; }
Когда подходит
Разумные ожидания
Когда это уместно
- Нужна структура уже сейчас, без найма платформенной команды.
- Нагрузки естественно ложатся на обработчики без состояния с явным вводом-выводом или на контейнерные сервисы.
Когда лучше выбрать другое
- Вы уже вложились в кластерные policy-движки и CRD как основной интерфейс.
Частые вопросы
Частые вопросы
Под капотом всё равно Kubernetes?
Вы работаете с интерфейсом и API Inquir; платформа исполняет ваш код в изолированных Docker-контейнерах. Чтобы развернуть функцию или приложение, не нужно вести Kubernetes-манифесты или чарты Helm.
Можно ли запустить полноценный контейнерный сервис?
Да. Разверните любой Dockerfile или образ как контейнерное приложение командой inquir apps deploy. У него будут релизы с проверкой работоспособности, откат, приватный адрес .apps.internal и тома по желанию — в том же рабочем пространстве, что и функции.
Как тестировать локально?
Следуйте документации по локальному вызову; держите паритет переменных окружения с продакшеном.