VPS, PaaS или Kubernetes: где разместить небольшой парк сервисов

У команды есть API, несколько ботов, база данных и ночные задачи. На одном VPS всё помещается, но обновления системы и ручные перезапуски отвлекают от продукта. Возникает вопрос: переходить на PaaS или сразу собирать Kubernetes?

Количество сервисов само по себе не даёт ответа. Важнее требования к сети, способ хранения данных, цена простоя и время команды на сопровождение. Разберём выбор на примере небольшого парка приложений без предположения, что более сложная инфраструктура обязательно лучше.

Сначала опишите нагрузку

Для каждого сервиса запишите команду запуска, потребление памяти, характер CPU-нагрузки, входящие порты, внешние зависимости и постоянные данные. Отдельно отметьте, что произойдёт при перезапуске и можно ли одновременно запустить две копии.

WebSocket начинается с HTTP-соединения, но успешный обычный HTTP-запрос не проверяет долгоживущий канал. Протестируйте upgrade, idle timeout, переподключение и выпуск новой версии во время активного соединения.

Когда разумно остаться на VPS

VPS подходит, если важны контроль над ОС, свои правила сети и нестандартные демоны. Небольшие процессы можно плотно разместить на одной машине, используя systemd или контейнеры. При этом именно команда отвечает за обновления, firewall, сертификаты, заполнение диска и восстановление после отказа хоста.

Стоимость сравнивайте вместе с эксплуатацией. Внутренняя оценка может выглядеть как «аренда + резервное хранилище + часы сопровождения × стоимость часа». Не обязательно переводить каждый час в деньги, но полезно знать, сколько вечеров в месяц уходит на инфраструктуру.

Одна машина остаётся одной зоной отказа. Резервная копия на том же диске не решает потерю этого диска. Перед любым переносом проведите восстановление базы в отдельное окружение и измерьте, сколько оно занимает.

Когда PaaS снимает достаточно работы

PaaS полезна, когда команда готова описать запуск приложения в стандартном формате и передать провайдеру часть эксплуатации. Удобство обычно проявляется в сборке, релизах, маршрутизации, логах и управлении переменными. Набор возможностей зависит от продукта: наличие PostgreSQL-шаблона не означает наличие managed database с проверенными бэкапами и автоматическим восстановлением.

Проверяйте модель оплаты на своём списке сервисов. Тариф может ограничивать общий пул ресурсов, отдельно каждое приложение, число реплик или объём диска. Это разные ограничения. В Inquir тариф описывает доступный пул, но перед переносом нужно сопоставить его с настройками приложений и актуальными условиями на странице тарифов.

Иллюстрация: 16 сервисов с лимитом памяти по 128 МиБ — это 2048 МиБ, то есть 2 ГиБ суммарных лимитов. Это не доказательство, что весь проект поместится в 2 ГиБ: отдельно нужны ресурсы базы, кеша, инфраструктуры и запас для обновления. Фактическое потребление и резервируемый платформой ресурс тоже могут различаться.

Публичный произвольный TCP нельзя считать стандартной функцией любой PaaS. На момент публикации Inquir не предоставляет общий публичный TCP-ingress для приложений; приватные TCP-связи внутри проекта не заменяют эту возможность. Если проект зависит от своего TLS на нестандартном порту, такой перенос нужно сначала проверить на уровне сетевых требований.

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

Kubernetes имеет смысл, когда нужны собственные правила размещения, несколько узлов, управление большим количеством нагрузок и расширения через операторы — и есть люди, которые будут поддерживать эту систему. Официальное описание Kubernetes рассматривает его как платформу управления контейнерными нагрузками, а не готовое решение всех задач эксплуатации.

Кластер не избавляет от проектирования доступа, обновлений, наблюдаемости и восстановления данных. База в StatefulSet не получает резервные копии просто от факта запуска в Kubernetes. Оператор способен автоматизировать часть процедур, но его настройки и сценарий восстановления всё равно нужно проверять.

Для трёх небольших приложений кластер может добавить больше работы, чем убрать. Для команды с готовой платформенной экспертизой он, наоборот, способен обеспечить единый способ эксплуатации десятков проектов. Решение зависит от уже имеющихся компетенций и требований, а не от желаемого количества YAML-файлов.

Как проверить PaaS без переноса всего проекта

Выберите одно приложение без локального состояния. Подготовьте контейнерный образ, список переменных и health endpoint. Используйте тестовые данные, проверьте логи, выпуск новой версии и возврат к предыдущему релизу. Сравните задержки и потребление памяти под характерной нагрузкой.

Для HTTP-сервиса можно заранее проверить новый адрес с нужным доменом, а затем переключить DNS. Но DNS не обеспечивает мгновенный откат: кеши сохраняются до истечения TTL, а существующие соединения продолжают жить. Обе стороны должны выдерживать переходный период.

Базу, фоновых потребителей и задания по расписанию переносите отдельным планом. Две одновременно работающие копии cron-задачи могут отправить два отчёта, а переключение DNS не синхронизирует данные. Сначала определите источник истины и момент остановки старого обработчика.

Контейнерный образ, явная команда запуска и миграции базы уменьшают стоимость обратного переезда. Полезно сохранить их в своём репозитории вместе с инструкцией восстановления. Начать проверку Inquir можно с документации приложений: перенос одного сервиса даст более полезный ответ, чем сравнение абстрактных списков возможностей.