Airbnb moved nearly all online services from hand-scaled EC2 machines onto thousands of Kubernetes nodes across a hundred-plus clusters, then had to teach the autoscaler Airbnb-specific business logic to keep it efficient.

Before Kubernetes, each instance of a service at Airbnb ran on its own EC2 machine, manually scaled to handle traffic increases. Capacity management varied team by team, and capacity would rarely be un-provisioned once load dropped — nobody was in a hurry to give resources back.

Over the following years, Airbnb shifted almost all online services from manually orchestrated EC2 instances to Kubernetes. Today it runs thousands of nodes across nearly a hundred clusters. Adding the Kubernetes Cluster Autoscaler — which adds nodes when pending pods can’t be scheduled and removes nodes that sit underutilized — saved roughly 5% of Airbnb’s total cloud spend on top of the operational overhead it eliminated. Airbnb’s own custom scaling component, a pluggable gRPC “Expander,” was accepted upstream into Cluster Autoscaler and became available in the v1.24.0 release.

The migration happened in three stages. Stage one was basic: a handful of homogeneous clusters, one node type each, scaled manually — still an improvement, because it consolidated capacity management to a single control point. Stage two introduced the “cluster type” abstraction as workloads diversified, and Cluster Autoscaler took over sizing each cluster automatically. But more cluster types meant more clusters — types grew past 30 and clusters past 100 — and every cluster upgrade now had to be individually tested against each type, which made management tedious.

Stage three consolidated cluster types into heterogeneous clusters that could host varied workloads under a single control plane, improving bin packing and utilization. That flexibility exposed a gap: Cluster Autoscaler’s built-in Expanders — random or fixed-priority — couldn’t express Airbnb’s actual scaling priorities around cost and instance type. Forking Cluster Autoscaler wasn’t attractive either, since Airbnb’s business logic wasn’t useful to anyone else and the project’s own release review was too slow for logic that changes continuously.

None of this was free. Heterogeneous clusters and a custom scaling path are more moving parts than the simple homogeneous setup Airbnb started with, and the team had to build and operate its own gRPC server rather than lean entirely on upstream defaults. But with the largest share of Airbnb’s compute now on one platform, that consolidation became the lever for the next round of efficiency work — reducing cluster-type sprawl instead of managing around it.

A fork of someone else’s infrastructure is a debt you pay every release forever; a pluggable interface you upstream is a debt you pay once.