Netflix перенёс большую часть batch-нагрузок на Kueue, чтобы заменить собственное решение для Kubernetes-native job scheduling. Главный смысл этой миграции не в смене инструмента, а в том, как сохранить API parity, throughput и управляемость при переходе с вендорного внутреннего слоя на open-source платформу.
Инженерная проблема здесь была не в нехватке функций как таковых. Внутренний Compute Managed Batch со временем разросся, но новые возможности стало сложнее развивать, потому что решение не было так тесно связано с Kubernetes, как Kueue. Параллельно в экосистеме Kubernetes уже появились open-source компоненты, которые закрывали значительную часть прежней функциональности. Для платформенной команды это типичный момент, когда собственный стек начинает проигрывать не по идее, а по стоимости изменений.
Выбор Kueue выглядит прагматично. Netflix сопоставил возможности, которые раньше были реализованы внутри компании, с функциями Kueue, а затем добрался до того, чего в homegrown-решении было бы дорого достраивать. Здесь важен компромисс: компания отказалась от полного контроля над самописной реализацией, но получила более широкие возможности, гибкость, распространённость и темп развития Kubernetes-native экосистемы. Для batch job management это часто означает меньшую цену сопровождения при сопоставимом уровне управляемости.
Ключевой риск любой такой миграции — не функциональная, а операционная совместимость. Netflix сделал переход прозрачным для существующих пользователей CMB. Команда опиралась на API parity, чтобы снизить риск и сохранить прежний пользовательский опыт. Это важный архитектурный приём: если внешний контракт не меняется, можно заменить внутреннюю реализацию поэтапно, не ломая потребителей и не превращая миграцию в одномоментный cutover.
Реализация шла через прямое отображение старой модели на новую. Внутренние tenants из CMB были сопоставлены с Cohors в Kueue, а leaf tenants — с парой ClusterQueue и LocalQueue. Для конфигурации capacity requirements использовали ResourceFlavors и nominal quotas. Такой перевод модели управления ресурсами показывает, что миграция была не простым переносом, а аккуратной трансляцией понятий между двумя системами. Это обычно и есть самый сложный слой: не код, а семантика.
Отдельно команда учитывала производственные ограничения. Переход должен был поддерживать нужную скорость запуска контейнеров и максимальный throughput с самого начала. Миграция также была tenant-bound, а значит, сбой у одного сегмента не должен был расползаться по всей системе. Возможность easy rollback добавляла ещё один слой защиты. В архитектуре больших платформ это не роскошь, а обязательная часть плана изменения.
Сейчас Netflix управляет миллионами batch workloads в production через Kueue, но миграция ещё не завершена. При этом уже отмечено улучшение average resource utilization за счёт preemption-based fair sharing. Здесь виден важный trade-off: система сохраняет reservation semantics для одних tenants, но использует простаивающую мощность для других. Это не просто оптимизация ёмкости, а более плотное использование инфраструктуры без отказа от принципов справедливого распределения ресурсов.
Команда также зафиксировала несколько практических выводов. Самый сложный use case не стоит откладывать на конец, и Netflix сознательно начал с крупнейшего и наиболее сложного customer. Это позволило раньше проверить пределы системы и снизило риск для последующих этапов. Дополнительно load tests в non-prod среде помогли подогнать performance-related configuration под требуемый throughput. В таких миграциях результат обычно измеряется не только метриками, но и качеством перехода: если пользователи не заметили смену платформы, значит архитектурный контракт был выбран верно.