Container Orchestration: Pod Scheduler & Cluster Autoscaler

Scheduling Policy

Workload

Spawn interval 1.2s

Cluster

Cluster State

Nodes alive

Pods running

Pending queue

Cluster load

CPU used

Memory used

Cluster ready.

How it works

Each pod requests two resources — CPU and memory — out of a node's fixed capacity. A node can host a pod only if it has enough headroom in both dimensions:

fits(node, pod) = cpuFree(node) ≥ cpu(pod)  AND  memFree(node) ≥ mem(pod)

This is 2-D bin packing, exactly what the Kubernetes scheduler's filter+score pipeline solves for every pod. Three classic packing policies are simulated here:

First-Fit:  first node (in cluster order) where fits() is true
Best-Fit:   node minimising leftover = (cpuFree-cpu)+(memFree-mem)
            → tightest pack, least wasted capacity
Worst-Fit:  node maximising that same leftover
            → spreads load, more headroom per node

A node's load is its dominant resource — whichever of CPU or memory is closer to full:

util(node) = max( cpuUsed/cpuCap, memUsed/memCap )
clusterLoad = average util(node) over all live nodes

The Cluster Autoscaler reacts to that number every simulated tick, the same policy real cloud autoscalers use: scale out when the cluster is under pressure, scale in only once a node has sat idle:

clusterLoad > 75%           → add a node (up to the cluster cap)
node empty ≥ 5s AND
clusterLoad < 30%           → remove that node (above the floor)

Pods also have a finite lifetime — like real workloads finishing a job — which frees their resources and is what lets the cluster ever scale back down. Kill Random Node simulates hardware/AZ failure: every pod on that node is evicted back into the pending queue and the scheduler immediately retries placing them elsewhere, the same reconciliation loop that makes Kubernetes self-healing.

Node capacity envelope Pod (pending in queue) Pod (running, colour = memory share)

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.