Why and How Uber Moved to Kubernetes — A Behind-the-Scenes Look
If you’ve ever taken a ride with Uber, there’s a massive amount of software making that experience happen seamlessly behind the scenes. From matching riders to drivers, to calculating fares, to real-time mapping—it all runs on a huge compute platform.
And recently, Uber took on a pretty huge task: migrating that compute platform to Kubernetes.
Let’s talk about why they did it, how they pulled it off, and what they learned along the way.
What Was Running Before?
For years, Uber ran its containerized workloads on Apache Mesos—a powerful system that helped them scale across thousands of machines. It worked well, and they had built a lot on top of it. But like many tech stories, what worked five years ago wasn’t cutting it anymore.
By 2021, Mesos was deprecated at Uber. That meant no more bug fixes, no more updates, and no future-proofing. Meanwhile, Kubernetes had become the go-to container orchestrator across the tech world—with an active community, rich tooling, and better support from cloud providers.
A Massive Platform to Migrate
We’re not talking about a few apps here. Uber’s compute platform is enormous:
- 50+ clusters across multiple regions and clouds (on-prem, Oracle, Google Cloud)
- Each cluster: ~5,000–7,500 machines
- Altogether: 3 million cores, 4,000 services, and 1.5 million pod launches per day
- One cluster alone might launch 120–130 pods every second
That scale makes migrating tricky. Any mistake isn’t just a bug—it could affect pricing, ETA predictions, or live trip routing.
Why Kubernetes Made Sense
The decision wasn’t just about deprecating Mesos. Kubernetes brought a few big wins:
- Standardization: It’s used across the industry, which makes hiring, tooling, and integration easier.
- Cloud-native support: Cloud vendors (like GCP and Oracle Cloud) are building for Kubernetes first.
- Community and ecosystem: With tons of open-source tools and operators, Uber didn’t have to reinvent the wheel every time.
- Better compliance and security out of the box.
Basically, Uber didn’t want to be stuck maintaining a legacy system. They wanted to ride the wave of innovation instead of fighting the tide.
How They Made the Move (Without Breaking Everything)
This wasn’t a “flip the switch” migration. It was carefully designed and rolled out with a few guiding principles:
1. Make upgrades seamless.
They aligned their Kubernetes versions with what cloud vendors offered. And when they needed to tweak something, they used Kubernetes’ built-in extensibility—no forking, no reinventing.
2. Make upgrades safe.
They built a comprehensive release validation system—running performance, integration, and soak tests before rolling anything out.
3. Make migration invisible to devs.
Most developers didn’t even notice the change. Uber ensured that services could run on Mesos or Kubernetes without needing any code changes. It just worked.
So far, this was about stateless services—the kind of workloads that don’t store data long-term. But the journey isn’t over. Uber plans to move batch jobs and other complex workloads (like those using Peloton, their internal batch platform) to Kubernetes too.
Uber’s migration wasn’t about chasing hype—it was about choosing sustainability, scalability, and community-backed innovation. Kubernetes isn’t a silver bullet, but for a company with Uber’s scale, it gave them the right tools for the next decade.
Read the full article here.