GPU в Kubernetes и сервер на 2 ГБ: почему малому бизнесу хватает Docker Compose

На неделе CNCF и Netflix опубликовали четыре технических разбора о Kubernetes: как делить GPU между арендаторами, почему автоскейлер и планировщик спорят о форме узла, как Netflix автоматически ужимает контейнеры и как Kyverno переезжает в ядро Linux. Всё это решает задачи компаний с сотнями команд. Владельцу небольшого бизнеса из этого полезно другое: понять, какие из этих проблем у него вообще есть, и не платить за решение остальных.

Что вышло

CNCF 23 октября показала лабораторию из двух открытых проектов. Kamaji запускает управляющий слой Kubernetes каждого арендатора как поды внутри одного общего кластера, HAMi позволяет поду просить кусок GPU, память в мегабайтах и долю вычислений в процентах. Проблему автор описывает в первом абзаце: Kubernetes выдаёт GPU целиком, и под, которому нужно 4 ГБ из 80, занимает всю карту. Автор собрал всё на одной машине без физического GPU, через mock-плагин HAMi, на 4 ядрах и 8 ГБ памяти.

CNCF 19 октября объяснила, почему под с GPU может висеть в ожидании, когда ёмкость в регионе есть. Планировщик ставит под на существующий узел, автоскейлер добавляет узлы, и десять лет этим двум циклам не нужно было договариваться. С ускорителями автоскейлер добавляет узел не той формы, и планировщик на него под не ставит. Ответ сообщества называется Dynamic Resource Allocation: вместо числа «нужно 2 GPU» под описывает структурированную заявку.

Netflix 14 октября рассказал о Stratum Resource Tuner. Платформа обработки видео запускает сотни тысяч контейнеров в день, а лимиты каждой функции владельцы задают в YAML: 8 CPU, 18 000 МБ памяти, 50 000 МБ диска. Эти цифры обычно копируют из соседней функции и завышают на всякий случай. Тюнер собирает фактическое потребление, выдаёт рекомендацию, проверяет её экспериментом, применяет или отклоняет и дальше наблюдает за функцией. Начали с нагрузок, которым не страшна задержка: они дают 70–80 % потребления.

CNCF 15 октября описала Nirmata Runtime для Kyverno. Обычный Kyverno проверяет манифест на входе: правильно ли описан под. Новая часть работает в ядре через eBPF и LSM и отвечает на другой вопрос: делает ли под то, что обещал. Каждая политика сначала работает в режиме наблюдения и показывает, что бы она запретила. Пример в статье как раз про агентов: поду разрешён только внутренний шлюз к модели, а чтение файлов с учётными данными запрещено, и промпт-инъекция внутри агента этот запрет не обойдёт, потому что он живёт не в процессе агента.

Какие из этих проблем есть у малого бизнеса

Возьмём компанию по аренде автомобилей. У неё сайт с бронированием, бэкенд с интеграцией в CRM и приложение для менеджеров: три-четыре контейнера и одна команда из одного-двух разработчиков. Арендаторов, которым нужно изолировать управляющий слой, нет. GPU нет. Автоскейлер не нужен, потому что нагрузка известна: десятки броней в день.

Из четырёх статей к такой компании относятся две мысли. Первая, из Netflix: лимиты контейнеров ставят «с запасом» и больше не трогают, а потом память заканчивается в самый неудобный момент. Вторая, из Nirmata: контейнер должен видеть только то, что ему положено, и это правило не зависит от размера. Остальное решает проблемы, которых у трёх контейнеров нет, а Kubernetes при этом добавляет управляющий слой, который кто-то должен обновлять и чинить.

Как это устроено у меня

Сервис «Кофе вместе», который я спроектировал и сделал в сентябре и октябре 2026 года, и мой сайт kononov.dev живут на общем сервере с 2 ГБ памяти в Docker за Nginx. Сервер маленький, поэтому у контейнеров жёсткие лимиты памяти, а при обновлении старый экземпляр останавливается до запуска нового. Если сборке не хватает памяти, образ собирается вне сервера и загружается готовым. Сервис экономит сотрудникам и администраторам больше 100 часов в месяц, и оркестратор для этого не понадобился.

У PDR-компании в США задача крупнее: с 2022 года на своём сервере на Debian в Google Cloud работают MariaDB, API, сайт и телефония на собственной PBX, в компании больше 30 человек. Kubernetes в этом стеке нет, а серьёзных сбоев с восстановлением с 2022 года не было. На таком масштабе ресурсы проще распределить вручную, автоматический тюнер здесь не нужен.

Что я бы сделал

Посчитать контейнеры и команды. Одна команда и меньше десятка сервисов: один сервер, Docker Compose или похожий простой запуск за Nginx. Переход к Kubernetes обсуждать, когда появятся несколько команд с разными правами, GPU или нагрузка, которая меняется в разы за день.

Выставить лимит памяти каждому контейнеру и проверить под нагрузкой. Через полгода пересмотреть: это ручная версия тюнера Netflix.

Решить, что происходит при обновлении. На маленьком сервере два экземпляра не поместятся, значит, старый останавливается до запуска нового, и это надо знать заранее.

Собирать образ на другой машине, если на сервере мало памяти.

Ограничить контейнеру сеть и секреты по принципу из статьи Nirmata: только те адреса и файлы, которые нужны для работы. Для этого не нужен eBPF, хватает сети Docker и переменных окружения.

Связанные материалы

О сервере как центре системы я писал в статье Сервер: данные, доступ и выполнение процесса. Направление: инфраструктура, которую можно выпускать и восстанавливать. Кейсы: сервис общего заказа кофе на сервере с 2 ГБ и технический партнёр PDR-компании с 2021 года. Из других обзоров: когда бэкенду лучше на своём сервере, zero trust для компании из 30 человек и сколько наблюдаемости нужно системе на одном сервере. Раньше я писал про общий GPU-пул и очередь на него. Если вам предлагают Kubernetes для трёх контейнеров, расскажите, что у вас работает сейчас и сколько людей это сопровождает. Обсудить задачу.