Hybrid Puck Broadcast: From Overallocation to Reliable Sharing

Introduction

Some time ago we introduced cpusets into Odin — PUCK GOLD’s stateful container orchestrator for the live broadcast tier. The change gave us stricter control over how CPU time is allocated, which helped cut down on throttling and reduced latency on goal-cam slow-mo, but it came at the cost of assigning full dedicated CPUs to every workload.

For years, our vertical CPU scaler operated under the assumptions that CPU usage could be accurately measured using one-minute averages, that cores allocated to a node were dedicated and not shared, and that CPU utilization targets could adjust to changes in failover load.

Those assumptions provided a baseline for managing workloads, but proved insufficient for handling bursty CPU usage patterns — exactly the shape of a live overtime period. In this post we describe how we use cpusets, cpu.shares, and a key observation at the host level to improve the performance, reliability, and cost-effectiveness of colocated workloads.

From Dedicated to Hybrid

The Odin platform is evolving to handle workloads with bursty CPU profiles more intelligently. The new model introduces shared core allocation alongside dedicated cores.

• Hybrid allocation — workloads now receive both dedicated (reserved) cores and an optional number of shared cores.
• Over-allocation control — shared cores are pooled per host and over-allocated using a defined ratio.
• Fair contention handling — Linux cpu.shares dynamically distribute shared CPU time based on allocation size.
• Vertical scaler upgrade — the scaler calculates optimal dedicated and shared core allocations for each workload.

Empirical Study of CPU Shares

We conducted an extensive proof of concept using Linux cpuset.cpus and cpu.shares to simulate and measure how shared core configurations behave under different load profiles. With this approach, cpu.shares directly mirrors the CPU resources you intend to allocate, striking a balance between precision and simplicity.

Dedicated CPUs are always integer; shared CPUs can be float. The factor of 100 makes the final share value an integer and lets us think of values as percentages of one CPU. For example, two dedicated cores plus half a shared core = round((2 + 0.5) × 100) = 250.

CPU Allocation Strategy for the Hybrid Model

Odin uses a hybrid model that combines dedicated and shared cores to keep workloads efficient and balanced across NUMA nodes. The host agent — odin-agent — is responsible for managing this distribution, making decisions that prevent overload and optimize resource use.

For shared cores, the agent begins by balancing them evenly across all nodes. If more shared cores are needed, the agent prioritizes placing them on nodes that already have a heavier dedicated CPU load, avoiding overburdening less busy nodes and maintaining an even distribution of work.

When allocating dedicated cores, the agent prefers to keep them on the same node as the workload’s shared cores, reducing latency and keeping processing local. It ensures dedicated cores don’t overlap with shared ones, and if the preferred node can’t provide enough capacity, it moves on to other nodes until the requirement is met.

Bridging Kubernetes Gaps for Odin

We are aligning Odin with cloud-native patterns and standards where feasible — a move that brings both architectural changes and paradigm shifts. One key challenge is host-level support. Today, Kubernetes lacks built-in support for hybrid core allocation — a feature that has become essential for Odin’s efficiency and reliability. To bridge this gap, we factored out our cgroups management code into a standalone library, then wrapped that into a Kubernetes CRI plugin so Odin can adopt Kubernetes without sacrificing host-level efficiency.

Behind the Scenes: Vertical Scaling

The scaler decides how many CPUs each workload gets by looking at two things: the average CPU usage for dedicated cores and the deviation from that average for shared cores. Dedicated CPUs are sized for steady demand; shared CPUs handle occasional bursts.

There’s a more complex calculation that determines the total shared CPU pool for each host. Overall, the sum of all shared CPUs allocated to workloads is usually greater than the total shared CPUs available on a host. During contention, cpu.shares is set proportionally so each workload gets a fair slice of the host’s shared CPU pool. While this can still fall short if multiple spikes happen simultaneously, it’s rare enough that the system can tolerate it.

Conclusion

The introduction of shared cores marks a major step toward smarter CPU resource allocation across the PUCK GOLD broadcast tier. By combining dedicated cores for guaranteed performance with shared cores for elastic bursts, we can reduce overprovisioning for bursty workloads, increase overall CPU utilization fleet-wide, and maintain service-level performance guarantees.

This hybrid model aligns with our long-term vision of configuration-free CPU management, making the fleet more adaptive, efficient, and resilient — and keeping the goal-cam frame on time, even in overtime.