Netflix migrated most of its batch workloads to Kueue to replace its proprietary solution for Kubernetes-native job scheduling. The main point of this migration is not the tool change itself, but how to maintain API parity, throughput, and manageability while transitioning from a vendor-specific internal layer to an open-source platform.
The engineering challenge here was not a lack of features per se. The internal Compute Managed Batch had grown over time, but developing new capabilities became more complex because the solution was not as tightly integrated with Kubernetes as Kueue. Meanwhile, open-source components had already emerged in the Kubernetes ecosystem that covered a significant portion of the previous functionality. For the platform team, this is a typical moment when a proprietary stack begins to lose out not on the idea, but on the cost of changes.
The choice of Kueue appears pragmatic. Netflix compared the capabilities that were previously implemented in-house with the features of Kueue, and then identified what would be costly to build out in a homegrown solution. Here, the compromise is important: the company relinquished full control over its custom implementation but gained broader capabilities, flexibility, prevalence, and the pace of development of the Kubernetes-native ecosystem. For batch job management, this often means a lower maintenance cost at a comparable level of manageability.
The key risk of any such migration is not functional but operational compatibility. Netflix made the transition seamless for existing CMB users. The team relied on API parity to mitigate risk and preserve the previous user experience. This is an important architectural technique: if the external contract does not change, the internal implementation can be replaced incrementally without breaking consumers and turning the migration into a one-time cutover.
The implementation proceeded through a direct mapping of the old model to the new one. Internal tenants from CMB were mapped to Cohors in Kueue, and leaf tenants were mapped to a pair of ClusterQueue and LocalQueue. For configuring capacity requirements, ResourceFlavors and nominal quotas were used. This translation of the resource management model shows that the migration was not a simple transfer but a careful translation of concepts between the two systems. This is usually the most complex layer: not code, but semantics.
The team also considered production constraints. The transition needed to support the required container launch speed and maximum throughput from the outset. The migration was also tenant-bound, meaning that a failure in one segment should not propagate throughout the system. The possibility of easy rollback added another layer of protection. In the architecture of large platforms, this is not a luxury but a mandatory part of the change plan.
Currently, Netflix manages millions of batch workloads in production through Kueue, but the migration is not yet complete. However, improvements in average resource utilization have already been noted due to preemption-based fair sharing. Here, an important trade-off is visible: the system retains reservation semantics for some tenants but utilizes idle capacity for others. This is not just a capacity optimization but a denser use of infrastructure without abandoning the principles of fair resource distribution.
The team also documented several practical takeaways. The most complex use case should not be postponed until the end, and Netflix consciously started with the largest and most complex customer. This allowed for earlier testing of the system’s limits and reduced risk for subsequent phases. Additionally, load tests in a non-prod environment helped fine-tune performance-related configuration to meet the required throughput. In such migrations, the outcome is typically measured not only by metrics but also by the quality of the transition: if users did not notice the platform change, it means the architectural contract was chosen correctly.