Multi Tenancy

2 posts

netflix3 min readCurated summary

How Netflix Simplified Batch Compute with Kueue

Netflix replaced much of its custom Compute Managed Batch (CMB) queuing and scheduling logic with Kubernetes-native Kueue. The migration preserved the existing user experience while enabling features such as preemption, fair sharing, all-or-nothing scheduling, and topology-aware placement. Kueue now manages millions of batch workloads across Netflix’s Titus-based infrastructure. ## CMB and Titus Architecture - CMB manages workloads that run to completion using: - Hierarchical tenants - Priority-based ordering - Per-tenant capacity management - Workloads ultimately run on Titus, Netflix’s container platform. - Titus provides federation across multiple Kubernetes cells and shared capacity reservations, allowing CMB to interact with a unified endpoint. - CMB tenants are either: - **Internal tenants**, which organize child tenants but do not accept jobs - **Leaf tenants**, which accept jobs through associated queues - Capacity includes: - **Reserved capacity**, providing predictable resources within a tenant hierarchy - **Shared capacity**, a global pool that tenants can burst into - CMB enforced fair sharing only at admission time because it lacked preemption; admitted jobs ran to completion even when demand changed. ## Why Netflix Chose Kueue - CMB was developed before many Kubernetes batch features became available in open source. - Kueue provided capabilities Netflix had previously built or wanted to build, including: - Fair sharing - Hierarchical tenancy - Capacity management - Priority queues - Preemption - Unlike schedulers such as YuniKorn and Volcano, Kueue works with the existing Kubernetes scheduler rather than replacing it. - This allowed Netflix to retain Titus scheduling profiles and avoid inefficient job placement. - Kueue also supports: - Multi-tenant quotas across heterogeneous hardware - Native Kubernetes objects such as `Pod` and `Job` - Higher-level workloads such as `RayJob` and `RayCluster` - All-or-nothing admission and topology-aware scheduling ## Migrating CMB Workloads - The migration, called **Netflix Batch**, was designed to: - Require no changes from CMB users - Avoid regressions in launch rates and maximum throughput - Move queuing and scheduling responsibilities to Kueue - Kueue runs in enabled Titus cells, while a custom router and Titus federation direct workloads to the appropriate cell. - Tenant enrollment was exposed as a simple operator action in Netflix’s UI, making rollout and rollback straightforward. - Internally, the migration mapped: - CMB internal tenants to Kueue **Cohorts** - Leaf tenants to **ClusterQueues** and **LocalQueues** - Capacity configurations to Kueue **resource flavors** and **nominal quotas** ## Lessons from the Rollout - Maintaining API compatibility reduced customer disruption and allowed Netflix to replace backend components incrementally. - Migrating the largest and most complex customer early exposed problems sooner and increased confidence in the broader rollout. - The production migration took approximately four weeks. - Kueue required substantially higher QPS, burst, and `groupKindConcurrency` settings than its defaults. - Netflix validated these settings early through load tests in an environment modeled on Titus. ## Kueue in Production - Kueue is fully deployed at Netflix and manages millions of batch workloads. - Netflix is extending its use to additional Titus batch workloads. - Fair sharing and preemption are being expanded to improve utilization of reserved capacity. - Netflix’s experience is also informing other internal Kubernetes-native systems, including training infrastructure. Netflix’s migration demonstrates that a batch platform can adopt Kubernetes-native scheduling incrementally without forcing users to change APIs or abandoning existing placement infrastructure. For organizations with mature custom systems, preserving the external contract while delegating queueing and admission to Kueue offers a lower-risk path to modern features and simpler long-term operations.

Read original(opens in new tab)
datadog3 min readCurated summary

How we built reliable log delivery to thousands of unpredictable endpoints

Datadog’s Log Forwarding system resembles a package delivery network: it must move large volumes of data efficiently and reliably to many unpredictable destinations. Kafka provides ordered transport, but its FIFO behavior creates difficult tradeoffs when endpoints are slow or unavailable. The central challenge is preserving delivery guarantees without losing logs, creating duplicates, blocking unrelated destinations, or overwhelming customer infrastructure. ## What Log Forwarding Does - Datadog forwards processed, enriched logs as schemaless JSON records. - Destinations can include: - Elasticsearch - Splunk - Generic HTTP endpoints accepting JSON `POST` requests - The system must support thousands of tenants and external endpoints with widely varying reliability and performance. ## Kafka as the Distribution Network - Logs move through Datadog on Kafka topics, analogous to packages traveling on conveyor belts. - Each Kafka partition provides strict FIFO ordering: - Records are read in the order they were written. - Kafka offsets must be committed in that same order. - Logs for different destinations are spread across multiple partitions, so records for a single destination may need to be regrouped during delivery. - Assigning a dedicated Kafka partition to every destination would be simple conceptually but infeasible at scale. ## Reliability Challenges - External endpoints may be: - Temporarily unavailable - Slow or unstable - Unreachable for hours or days - The system must avoid: - Losing customer logs - Sending duplicate logs - Delaying all destinations because one endpoint is unhealthy - Excessive resource usage - Overwhelming or effectively DDoSing a customer endpoint - Sending one HTTP request per log would be inefficient, so logs should be buffered and delivered in batches, much like packages going to the same address. ## Kafka Ordering and Blocked Progress - Waiting for each forwarding request to succeed before reading more Kafka data protects against data loss but can halt progress. - Continuing to read and acknowledge Kafka records before successful delivery risks losing logs. - Because offsets must be committed in order, one unavailable destination can block later records in the same partition—even if those records belong to healthy destinations. - This makes coordination between Kafka consumption, retries, batching, and concurrent delivery especially complex in a multi-tenant system. ## Lessons from Log Archives - Datadog had prior experience with similar delivery problems in its Log Archives feature. - Archiving was easier because: - Cloud object storage endpoints are generally more reliable. - Archiving has lower latency requirements. - Those lessons helped the team anticipate reliability and ordering pitfalls in Log Forwarding. ## Dedicated Kafka Topics per Destination - A possible solution would be to assign one or more Kafka partitions to each destination. - This would isolate destinations so that one slow endpoint could not block others. - However, the approach would require an impractically large number of Kafka topics or partitions as the number of customers and destinations grows.

Read original(opens in new tab)