Container Orchestration

3 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)
meta3 min readCurated summary

Lights Out, Systems On: Validating Instant Power Loss Readiness

Meta’s Instantaneous PowerLoss Storm is a disaster-readiness testing program designed to prepare data centers for sudden, zero-notice power loss. It extends existing fault-tolerance mechanisms across facilities, servers, storage, compute, and the Twine orchestrator, while addressing region-wide failures and autonomous recovery. Through incremental testing and carefully defined tradeoffs, Meta aims to make losing an entire region as manageable as losing a smaller fault domain. ## Defense-in-Depth for Instant Failures - Power-loss tolerance was built into the full data-center stack, including mechanical and electrical systems, server racks, storage, compute, and Twine. - Batteries and Power Loss Siren (PLS) preserve in-memory data when racks lose power. - Twine services use region-wide asynchronous unavailability events (UEs) to coordinate shutdown and recovery. - Existing mechanisms had been tested against smaller fault domains, but region-wide failures introduced new challenges involving scale, replica placement, and autonomous startup. ## Solving Region Bootstrap Problems - Restarting a region may require millions of services to start simultaneously and discover their dependencies. - Circular dependencies among Twine control-plane services—such as Scheduler, Allocator, Broker, and Zelos—could prevent the orchestrator from starting itself. - Belljar CI/CD tests continuously identify critical startup dependencies before deployment. - A Twine recovery kit, supported by Belljar and Twrko, provides a manual “jumpstart” mechanism for breaking unexpected dependency cycles. - Meta also encountered a “boomerang” problem in which UEs shut down the control-plane services responsible for generating and distributing those signals. - The simpler solution was to let control-plane services ignore power-related shutdown UEs, preventing orphaned services that could not be reaped or recovered. ## Balancing Reliability and Engineering Velocity - Absolute tolerance to instant power loss could require costly or overly complex infrastructure and might create false positives during normal operations. - Meta defined unacceptable impacts as: - Storage or database data loss - Permanent damage to data-center facilities - Sustained disruption beyond one region - The company accepted bounded risks such as transient service errors, limited rack failures, and temporary staleness in routing or region-availability information. - Issues were considered tolerable when they could be remediated after the incident within a reasonable mean time to respond (MTTR). ## Incremental Validation Through PowerLoss Storms - Because testing a full region carried significant risk, Meta validated readiness progressively: - Dependency tests in new and pre-production regions - Exercises in shadow regions that mirror production - Tests in small production regions - Full tests in large regions supporting storage, AI, and data-warehouse workloads - During a Storm, Meta injects a power-supply fault to immediately de-energize an entire region. - After a short, realistic MTTR, remedial drain actions isolate the region from global controllers and schedulers. - The tests avoid preemptive preparation so they accurately represent an unexpected power failure. - Repeated exercises train both systems and engineers to handle regional loss with the resilience normally expected from smaller fault domains. Meta’s approach is to expand disaster readiness gradually: define unacceptable consequences, build layered recovery mechanisms, test at increasing scale, and use each exercise to improve both architecture and operational practice.

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

How we scaled fast, reliable configuration distribution to thousands of workload containers

Datadog’s seemingly simple tenant-configuration CRUD system must propagate updates rapidly and reliably to thousands of containers processing millions of logs per second. Loading configuration on every log is too expensive, while periodic caching introduces stale data and delayed updates. Datadog initially used database-backed caches invalidated through Kafka, but growing scale exposed reliability and resilience problems tied to repeated workload access to the central database. ## The Challenge of Propagating Context Data - Datadog calls tenant-specific settings—such as log parsing rules, Sensitive Data Scanner settings, and storage quotas—“context data.” - Configuration changes are expected to take effect almost immediately, including in Live Tail. - The same context data may be consumed by thousands of containers handling traffic for many tenants. - Because configuration directly affects customer-data processing, propagation must be both low-latency and highly reliable. - The system must assume that failures can occur anywhere in a large distributed environment. ## Why On-Demand Fetching and Simple Caching Fail - Fetching configuration from a database for every incoming log would create an impractical read load. - Large tenants can generate hundreds of thousands of logs per second. - Each processing instance could require thousands of database reads per second. - Multiplying this across many instances would require extensive, highly performant database replicas. - Caching configuration in each workload container reduces reads but does not eliminate the scaling problem. - Many workload instances still cache data for a high number of tenants. - Increasing the cache interval reduces database load but delays configuration updates. - With periodic invalidation, the average propagation delay is roughly half the cache interval. ## Context Loading v1: Database-Backed Caches and Kafka Datadog’s first successful architecture kept tenant configuration in a central durable database while allowing workload containers to cache entries indefinitely. - A user changes a log-processing configuration. - The central context database stores the update. - Kafka publishes an invalidation message after the database write. - Every workload container receives the notification. - Each container reloads the affected tenant’s configuration from the database. - This minimized routine database reads while preserving low-latency updates. ## Why the Initial Architecture Needed Reconsideration - The design required every workload instance to reach the central context database whenever a configuration changed. - As Datadog added more workloads and containers, update-related database traffic grew substantially. - Internal game days and production incidents showed that problems affecting the context database could spread to downstream processing workloads. - Database failures could prevent configuration updates from propagating and potentially make it impossible for new workload containers to initialize their context. - These reliability concerns demonstrated that Kafka-based invalidation alone did not sufficiently isolate workload processing from context-database failures. Datadog’s experience shows that configuration propagation at large scale requires more than a durable database and cache invalidation. The system must also reduce dependency on the central database during updates and startup, while continuing to provide near-immediate, reliable propagation.

Read original(opens in new tab)