DevZero делает ставку на checkpoint-restore для оптимизации K8s без перезапусков

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

Что произошло

В четверг, как сообщил IT Brief UK, базирующийся в Сиэтле DevZero запустил автономную платформу оптимизации инфраструктуры для рабочих нагрузок Kubernetes, которая изменяет размер ресурсов в реальном времени без перезапусков. Посыл прост: прекратить избыточное выделение ресурсов, прекратить платить за простаивающие мощности и прекратить перезапускать поды для этого.

Компания была основана в 2022 году бывшими инженерами Uber Дебо Реем и Робом Флетчером — изначально как облачная платформа разработки, направленная на повышение продуктивности инженеров. Основатели сами запускали этот сервис на Kubernetes, столкнулись с теми же неэффективностями, что и все остальные, и создали инструменты для их устранения. Теперь эти инструменты стали основным продуктом.

Это ставит DevZero на курс столкновения с Cast.ai и ScaleOps — двумя именами, которые большинство руководителей платформ уже держат в списке вендоров, когда их финансовый директор начинает задавать неудобные вопросы о расходах на EC2. Ключевое отличие, на которое опирается DevZero, — технология checkpoint-restore, которая, по утверждению компании, обеспечивает живую миграцию рабочих нагрузок при изменении спроса или сбоях инфраструктуры.

В публикуемый список клиентов входят DataBahn, Dentira, Starburst, OpenObserve и Outerbounds — заметно ориентированный на AI и платформы данных. Инвесторы — Anthos Capital, Foundation Capital и Madrona.

DevZero заявляет, что в среднем клиенты до внедрения платформы переплачивали за вычислительные ресурсы на 53%, а пользователи обычно сокращают счета на 30–60%. Компания сама оговаривается, что эти цифры снижения не были независимо проверены — что как минимум честно. Причина, по которой они считают рынок готовым: опрос Cloud Native Computing Foundation показал, что 66% организаций, размещающих генеративные AI-модели, используют Kubernetes для управления частью или всеми своими инференс-нагрузками, а исследование Datadog выявило, что 83% затрат на контейнеры уходит на простаивающие ресурсы, причём 54% — на избыточно выделенную кластерную инфраструктуру.

Техническая анатомия

Интересна именно механика, а не панель управления. DevZero работает на уровнях кластера, узла и рабочей нагрузки, профилирует потребление ресурсов и корректирует выделение CPU, памяти и GPU по мере изменения использования. Это уже базовый функционал. Cast.ai и ScaleOps делают то же самое. Скучная часть одинакова у всех вендоров: сбор метрик, моделирование спроса, выбор типов инстансов, планирование.

Интригующая часть — checkpoint-restore. Любой, кто пытался вертикально масштабировать stateful-под на ванильном Kubernetes, знает этот танец: изменение ресурсов на месте всё ещё развивается, VerticalPodAutoscaler исторически хотел вытеснить под, а «вытеснить под» на инженерном языке означает «перезапустить рабочую нагрузку и молиться, что пул соединений восстановится». Checkpoint-restore (из того же семейства технологий, что CRIU, вокруг которого проекты CNCF ходят уже годами) делает снимок состояния запущенного процесса и возобновляет его в другом месте. Без холодного старта. Без налога на прогрев JVM. Без потери кэша в памяти.

Это важно в двух конкретных случаях. Первый — AI-инференс. Большая модель, загруженная в память GPU, дорого обходится при вытеснении. Если её можно перенести в реальном времени на правильно подобранный GPU-узел, вы избегаете и задержки холодного старта, и соблазна избыточно выделять GPU-мощности «на всякий случай». Второй — сбой зоны доступности. Михир Найр из DataBahn, руководитель отдела архитектуры, сказал: «Во время недавнего сбоя зоны доступности DevZero прозрачно мигрировал наши рабочие нагрузки в реальном времени, не потребовав ни единого перезапуска или операционного вмешательства со стороны нашей команды».

Платформа также работает в AWS, Azure, GCP, OCI и OpenShift, и DevZero утверждает, что анализирует более 3 000 типов инстансов, 69 000 ценовых точек, 23 модели GPU и более 80 регионов для принятия решений о размещении. Комбинаторное пространство облачных SKU годами было тихой катастрофой для платформенных команд, и перекладывание этого решения на solver — откровенно говоря, единственный разумный шаг в данный момент. Более сложный инженерный вопрос — выдержит ли заявление о живой миграции по-настоящему сложные рабочие нагрузки: с TCP-сессиями, буферами, отображёнными в память GPU, зависимостями от модулей ядра. Маркетинг говорит «да». Судьёй будет пейджер в три часа ночи.

Кому придётся несладко

Cast.ai и ScaleOps — очевидные конкуренты, которые смотрят на этот запуск. Оба выстроили сильные позиции в области оптимизации затрат K8s, и теперь обоим придётся объяснить, почему их подход к rightsizing — как правило, через замену подов — приемлем для AI-инференса и долгоживущих stateful-сервисов. Ждите страниц с упоминанием checkpoint-restore в течение квартала. Именно так движется этот рынок.

Более широкая группа пострадавших — молчаливое большинство платформенных команд, которые последние два года писали внутренние страницы в Confluence с заголовком «Дорожная карта оптимизации затрат Kubernetes» без единого реализованного шага. Их финансовый директор теперь прочитал статистику Datadog о том, что 83% затрат на контейнеры уходит на простаивающие ресурсы. Время для ответа «мы изучаем Karpenter и настройку HPA» стремительно истекает.

AI-инференс-команды столкнутся с проблемой иначе. Если вы запускаете LLM-инференс на зарезервированных GPU-мощностях, рассчитанных на пиковую нагрузку, ваша юнит-экономика тихо ужасна. Цифра в 66% использования Kubernetes для инференса из опроса CNCF говорит о том, что субстрат достаточно стандартизирован, чтобы такие вендоры, как DevZero, могли напрямую нацелиться на него. Команды, создавшие кастомные инференс-стеки на raw EC2, скоро обнаружат, что их история с затратами хуже, чем у K8s-нативных решений, над которыми они раньше насмехались.

Наконец, облачные провайдеры получают небольшой укол. Каждый доллар, который платформа rightsizing экономит клиенту, — это доллар, снятый со счёта AWS, Azure или GCP. Гиперскейлеры терпят это, потому что альтернатива (уход клиентов) хуже, но заметьте: их собственный нативный инструментарий (Compute Optimizer, Azure Advisor) удобно останавливается до агрессивного живого rightsizing. Любопытно.

План действий для инженерных команд

Если вы управляете платформой Kubernetes, вот три вещи, которые стоит сделать на этой неделе. Во-первых, реально измерьте свой коэффициент простоя. Сравните запросы CPU и памяти контейнеров с фактическим использованием за окно в 14 дней. Если вы приблизитесь к цифре 83% простоя, у вас есть история затрат уровня совета директоров, нравится вам это или нет. Метрики OpenTelemetry, поданные в то, что вы уже используете, вполне достаточны; вам не нужен новый вендор, чтобы выяснить, что у вас есть проблема.

Во-вторых, разделите рабочие нагрузки, которые могут переносить вытеснение, от тех, которые не могут. Stateless HTTP-сервисы: нормально, HPA и VPA справятся с большей частью работы. Stateful-сервисы, долгоживущие gRPC-потоки, GPU-loaded инференс-поды, всё с существенным прогревом — вот рабочие нагрузки, где checkpoint-restore действительно оправдывает себя. Знание своего разделения позволяет честно оценивать DevZero, Cast.ai, ScaleOps или собственную реализацию.

В-третьих, запустите пилот на одном некритичном кластере, прежде чем верить какой-либо цифре экономии в 30–60%. DevZero сам отмечает, что эти данные не были независимо проверены, и ваш микс рабочих нагрузок — не средний по больнице. Проведите четырёхнедельное сравнительное тестирование с реальным трафиком, имитирующим продакшн. Измеряйте не только разницу в затратах, но и задержку p99, количество перезапусков и вмешательства операторов. Собственная формулировка Рея звучала как «автономная оптимизация, которой можно доверять в три часа ночи». Проверьте это в три часа ночи. В воскресенье. С синтетическим сбоем зоны доступности. Если выдержит — у вас что-то стоящее. Если нет — у вас очень дорогостоящая панель управления.

Ключевые выводы

• Запуск DevZero ставит checkpoint-restore в центр разговора о K8s FinOps, вынуждая Cast.ai и ScaleOps отвечать на вопрос о живой миграции.
• Цифра в 83% затрат на контейнеры, уходящих на простаивающие ресурсы (Datadog), плюс 66% GenAI-инференса, работающего на K8s, означают, что rightsizing теперь — статья расходов, видимая финансовому директору, а не хобби платформенной команды.
• AI-инференс и stateful-нагрузки — именно там автоскейлеры на основе вытеснения дают сбой, и именно там живая миграция меняет экономику.
• Заявление DevZero об экономии 30–60% предоставлено самой компанией и не верифицировано; рассматривайте его как гипотезу для проверки, а не цифру для слайда совета директоров.
• Возвращаясь к пабу: побеждает тот хозяин, который может переставлять бочки в разгар вечера, не пролив ни капли. Все остальные продолжают закупать с запасом. На это и делает ставку DevZero — и ставка вполне разумная.