Batch compute refers to workloads that:
Example batch workloads:
├── Data processing jobs
├── ML training runs
├── Report generation
└── ETL pipelines
Built in 2018, CMB provided:
| Feature | Description |
|---|---|
| Tenant hierarchy | Grouping mechanism for organizations |
| Priority queuing | Ordered execution |
| Capacity management | Per-tenant resource allocation |
| Titus integration | Runs on Netflix's container platform |
Think of tenants like a company org chart:
Organization (Internal Tenant)
├── Team A (Internal Tenant)
│ ├── App 1 (Leaf Tenant) ← actually runs jobs
│ └── App 2 (Leaf Tenant)
└── Team B (Internal Tenant)
└── App 3 (Leaf Tenant)
Key Rule: Only leaf tenants submit actual jobs. Internal tenants organize and share capacity downward.
┌─────────────────────────────────────┐
│ Reserved Capacity │
│ │
│ Internal Tenant → shared across │
│ all subtree leaf tenants │
│ │
│ Leaf Tenant → exclusively yours, │
│ NOT shared with others │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Global Shared Capacity Pool │
│ │
│ • Any tenant can "burst" into it │
│ • No reservation required │
│ • Fair-shared at admission time │
│ • ⚠️ No preemption in old CMB │
└─────────────────────────────────────┘
Critical Limitation of CMB: Once a job was admitted, it ran to completion — even if fair-share demand shifted dramatically. This caused poor resource utilization.
Problem 1: Built before modern Kubernetes ecosystem matured
→ Open-source tools now offer what CMB built custom
Problem 2: Feature development was difficult
→ CMB was too far removed from underlying Kubernetes clusters
→ Adding preemption was especially cumbersome
Problem 3: No preemption
→ Resources couldn't be reclaimed once allocated
→ Lower-priority jobs could block higher-priority ones
Modern tools provide out-of-the-box:
Kueue is a cloud-native job queueing system for Kubernetes batch workloads.
| CMB Concept | Kueue Equivalent | Purpose |
|---|---|---|
| Internal Tenant | Cohort | Groups ClusterQueues, enables resource sharing |
| Leaf Tenant | ClusterQueue + LocalQueue | Actual job admission and queuing |
| Capacity Configuration | Resource Flavors + Nominal Quotas | Defines available resources |
CMB Structure → Kueue Structure
─────────────────────────────────────────────
Internal Tenant → Cohort
└── Leaf Tenant → ClusterQueue
└── Jobs → LocalQueue → Workloads
OLD FLOW (CMB):
User → CMB Queue → CMB Scheduler → Titus Cell
NEW FLOW (Netflix Batch / Kueue):
User → Titus Endpoint → Kueue Router → Kueue-enabled Cell
↑
(Kueue handles
queuing & scheduling)
Netflix uses Titus federation — a single endpoint that routes jobs across multiple Kubernetes clusters (cells). The Kueue router directs jobs to the appropriate Kueue-enabled cell.
The migration was designed to be:
Click "Enable Kueue" on tenant
↓
Internal Tenants → converted to Cohorts
Leaf Tenants → converted to ClusterQueue + LocalQueue
Capacity Config → converted to Resource Flavors + Nominal Quotas
Scenario: Team A has reserved capacity but isn't using it
↓
Kueue allows Team B to borrow that idle capacity
↓
When Team A needs it back → Team B's jobs are PREEMPTED
↓
Team A reclaims its reserved resources
This is fundamentally different from CMB where borrowed resources could never be reclaimed.
apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
name: "team-a-cq" # This team's ClusterQueue
spec:
preemption:
reclaimWithinCohort: Any # Can reclaim from ANY tenant in cohort
withinClusterQueue: LowerPriority # Can preempt lower-priority jobs within own queue
Breaking down the preemption rules:
| Setting | Value | Meaning |
|---|---|---|
reclaimWithinCohort | Any | Reclaim reserved capacity from any borrowing tenant |
withinClusterQueue | LowerPriority | Higher-priority jobs can bump lower-priority ones |
For Tenants:
├── Use more idle capacity from other reservations
├── Submit more jobs without risk of starvation
└── Faster turnaround for business-critical (high-priority) workloads
For Netflix Platform:
└── Significant increase in average resource utilization
Before (CMB) After (Kueue)
─────────────────────────────────────────────────
Custom-built scheduling → Kubernetes-native
No preemption → Priority preemption
Static resource allocation → Dynamic fair sharing
Hard to extend → Ecosystem-backed
Poor utilization → Significantly higher utilization
Test yourself with these questions:
What is the difference between a leaf tenant and an internal tenant?
Leaf tenants submit actual jobs; internal tenants organize hierarchy and share capacity downward
Why was preemption impossible in CMB?
Once admitted, jobs ran to completion regardless of changing fair-share demand
What does reclaimWithinCohort: Any mean in practice?
A tenant can reclaim its reserved capacity from any other tenant currently borrowing it
What Kueue object replaces a CMB internal tenant?
A Cohort
What is the key utilization benefit of preemption-based fair sharing?
Idle reserved capacity can be lent out and reclaimed, preventing waste while maintaining guarantees