Im Jahr 2024 vollzog Uber eine bedeutende Transformation seiner Compute-Plattform, indem es die bisher genutzte Container-Orchestrierungssoftware Apache Mesos zugunsten von Kubernetes ersetzte. Diese Veränderung war keine bloße technische Anpassung, sondern ein strategischer Schritt hin zu einer zukunftssicheren, stabilen und branchenweit anerkannten Container-Verwaltung. Die Migration von stateless Workloads stellt nur den Anfang einer umfassenden Vereinheitlichung dar, die Uber künftig in allen Bereichen seiner Infrastruktur vorantreiben möchte. Dabei wurde das Ziel verfolgt, eine nahtlose, zuverlässige und durchgängige Entwicklererfahrung sicherzustellen, ohne dass die Entwickler selbst vom Migrationsprozess beeinträchtigt werden sollten. Die vorliegende Analyse erforscht die Motivation, die Herausforderungen und die innovativen Lösungen, die diesen Transformationsprozess ermöglichten.
Dabei wird auch auf die einzigartigen Anforderungen und außergewöhnlichen Dimensionen eingegangen, die Uber an seine Container-Plattform stellt. Die Entscheidung, von Mesos auf Kubernetes umzustellen, basierte auf mehreren gewichtigen Gründen. Obwohl Apache Mesos über Jahre hinweg eine stabile Plattform für Ubers Container-Orchestrierung bot, wurde das Projekt ab 2021 bei Uber nicht mehr aktiv weiterentwickelt oder gepflegt. Das Fehlen von regelmäßigen Updates, Bugfixes und generellen Verbesserungen stellte ein Risiko für die infrastrukturelle Zukunftsfähigkeit dar. Dagegen hat Kubernetes als Industriestandard für Container-Orchestrierung eine solide Basis mit einer lebendigen Open-Source-Community, kontinuierlichen Upgrades und umfangreicher Unterstützung durch führende Cloud-Anbieter wie Google Cloud oder Oracle Cloud.
Diese Faktoren garantieren sowohl Stabilität als auch Innovationsfähigkeit, die für die enormen Skalierungsbedürfnisse von Uber essenziell sind. Mit der Umstellung auf Kubernetes gelangen jedoch auch neue Herausforderungen auf das Team zu. Uber betreibt seine Compute-Plattform in beispiellosem Maßstab: Über 50 Cluster mit jeweils zwischen 5.000 und 7.500 Hosts, zusammengenommen etwa 3 Millionen Cores, auf denen täglich hunderttausende Service-Deployments stattfinden.
Diese Menge führt zu einer enorm hohen Pod-Churn-Rate von bis zu 130 Pods pro Sekunde pro Cluster. Die Standardpraxis in der Industrie sieht vor, viele kleine Kubernetes-Cluster zu betreiben, typischerweise zwischen 1.500 und 2.000 Nodes, um Kontrolle und Verfügbarkeit zu maximieren. Uber verfolgt jedoch das gegenteilige Modell und betreibt sehr große Cluster.
Das impliziert besondere Anforderungen an API-Server-Last, Scheduler-Performance und Fragmentierungsmanagement. Um diesen Herausforderungen Herr zu werden, entwickelte das Container Platform Team bei Uber spezielle Benchmarking-Werkzeuge, mit denen Belastungsszenarien von bis zu 7.500 Nodes und 200.000 Pods simuliert und optimiert werden konnten. Dabei wurde die Performance durch verschiedene Anpassungen verbessert: Die QPS-Einstellungen (queries per second) für Controller Manager und Scheduler wurden erhöht, um parallel mehr Anfragen zu verarbeiten.
Darüber hinaus wurde die API-Nutzung mittels Priorisierung und Fairness so gesteuert, dass besonders kostenintensive API-Operationen wie Listen- oder Get-Anfragen limitiert wurden. Das Datenformat der Kubernetes-Kommunikation wurde von JSON auf das effizientere Proto-Encoding umgestellt, was nochmal deutlich höhere Antwortgeschwindigkeiten ermöglicht. Zudem wurde der Kubernetes-Pod-Topology-Spread-Scheduler so modifiziert, dass er schneller und ressourcenschonender arbeitet, was in großen Clustern für gleichmäßig verteilte Workload-Platzierung sorgt. Neben dieser technischen Skalierung waren auch die Integrationen in das restliche Uber-Ökosystem eine große Aufgabe. Die bestehende CI/CD-Pipeline, der Mechanismus für Service-Discovery, Sicherheits- und Observability-Systeme sowie Prozesse zur Host-Verwaltung mussten für das Kubernetes-Umfeld vollständig neu konzipiert und implementiert werden.
Die fundamentalen architektonischen Unterschiede zwischen Mesos und Kubernetes machten eine einfache Migration unmöglich; stattdessen wurde alles von Grund auf neu aufgebaut. Eine zentrale Rolle spielte hierbei das eigene Uber-Tool „Up“, das als globale stateless Federation Layer fungiert. Up abstrahiert von der zugrundeliegenden Cluster-Technologie und ermöglicht Entwicklern, ihre Anwendungen unabhängig von der tatsächlichen Orchestrierungsplattform bereitzustellen. Diese zusätzliche Schicht ermöglichte eine automatisierte, zentrale Steuerung der Migration, bei der Dienste unbemerkt und ohne Aufwand der Service-Besitzer sukzessive von Mesos- auf Kubernetes-Cluster umgezogen werden konnten. Ein zentraler Aspekt der Migration war die Gewährleistung von Feature-Parität.
Die Entwickler mussten auf Kubernetes dieselbe Qualität in der Entwicklererfahrung bekommen wie zuvor unter Mesos. Dazu gehörte nicht zuletzt eine umfassende Sichtbarkeit und Zugänglichkeit zu Container-Artefakten wie Logs, Heap-Dumps oder Core-Dumps, die zur Fehleranalyse unabdingbar sind. Während Mesos diese Artefakte lokal auf den Hosts speicherte und direkt im Up-UI verfügbar machte, löscht Kubernetes standardmäßig lokale Volumes bei Pod-Löschung, was diese Zugriffe erschwert. Uber löste das Problem durch die Einführung eines Sidecar-Containers sowie eines Artefakt-Uploader-Daemons. Der Sidecar-Container bleibt auch nach dem Beenden des Hauptcontainers aktiv, während der Daemon die relevanten Artefakte komprimiert und in einen Blob-Storage hochlädt, sodass sie weiterhin abrufbar sind.
Darüber hinaus entwickelte Uber maßgeschneiderte Lösungen für besondere Anforderungen an das Skalierverhalten. Manche Dienste sind sensibel gegenüber schnellen Skalierungssprüngen, etwa weil zu starke Lastwechsel oder Resharding-Prozesse bei Apache Helix™-basierten Services zu Instabilitäten führen können. Kubernetes bietet hierfür keine native Unterstützung. Deshalb entstand ein eigener Custom Resource Controller, der Skalierungsoperationen in kontrollierten, kleinen Schritten realisiert. Diese Batch-Skalierung ermöglicht es, Laständerungen sicher und ohne Störungen auszurollen.
Auch die Geschwindigkeit von Deployments wurde optimiert. Da Uber häufig sehr große Container verwendet, führten lange Pull-Zeiten zu Verlangsamungen bei Rollouts. Die Einführung von CloneSets als Kubernetes-Custom-Resource ermöglichte in-place Updates, bei denen Pods gepatcht anstatt ersetzt werden. Zudem sorgt ein Image-Prefetch-Daemon dafür, dass Container-Images im Vorfeld auf Nodes in verschiedenen Zonen heruntergeladen werden, was die Startzeit drastisch reduziert. Die Native Kubernetes-Benutzeroberfläche stieß bei den extrem großen Clustern zudem an ihre Grenzen und wurde von Uber mit zahlreichen Caching-Techniken und Performance-Verbesserungen optimiert.
Damit blieben auch bei zehntausenden Hosts und hunderttausenden Pods die UI-Reaktionszeiten akzeptabel. Auch unerwartete Hürden galt es zu meistern. Eines dieser Probleme war das Fehlen eines umfassenden Monitorings für die Cluster-Gesundheit aus einer ganzheitlichen Perspektive. Uber entwickelte daraufhin ein eigenes Observability-Werkzeug, das detaillierte Metriken zu Ressourcenfragmentierung, Pod-Performance und Auswirkungen häufiger Updates oder Neustarts bereitstellt. Zudem erlebte das Team Probleme mit der Standardinformer-Reconciliation von Kubernetes, die Ereignisse nur alle 8-10 Stunden wiedergibt und bei Controller-Wechsel den Rollout verzögerte.
Ein maßgeschneiderter Reconciliation-Mechanismus löst dieses Problem, indem er hohe Objekte alle 15 Minuten zwingt, ihren Status abzugleichen. Im Bereich Rollbacks wurde erkannt, dass die standardmäßigen Fortschritts-Timeouts für Deployment-Fehler nicht ausreichend schnell und zuverlässig waren. Manche Dienste verfügten zudem über deaktivierte Gesundheitschecks oder sehr lange Initialisierungszeiten, was eine falsche Erfolgsmeldung erzeugte. Uber entwickelte daher heuristische Methoden, die auf der Überwachung von Container-Restarts basieren: Werden mehr als 10 Prozent der Pods fünfmal oder öfter während einer Rollout-Phase neu gestartet, wird ein automatischer Rollback ausgelöst. Der Migrationsprozess selbst wurde über eineinhalb Jahre mit mehreren strategischen Pausen umgesetzt.
Diese Pausen dienten der Problemanalyse und Korrektur von Stabilitätsfallen sowie Performance-Engpässen. Die Optimierungen – wie verbesserte Controller- und Operator-Logik, API-Tuning sowie Protokollanpassungen – trugen dazu bei, die Migrationsgeschwindigkeit wieder anzukurbeln. In Spitzenzeiten konnten bis zu 300.000 Cores pro Woche umgezogen werden. Am Stichtag Juli 2024 waren alle stateless Workloads erfolgreich migriert.
Die zukünftigen Pläne umfassen eine vollständige Konvergenz aller Cluster-Management-Technologien auf Kubernetes. Dadurch soll auch der Umgang mit Batch- und Stateful-Workloads durch Apache Hadoop YARN™ und Odin vereinheitlicht werden. Dieser Schritt verspricht eine enorme Vereinfachung der Infrastrukturbetreuung und weitere Effizienzsteigerungen. Zudem plant Uber, seine Erfahrungen und eventuell entwickelte Features aktiv in die Open-Source-Community einzubringen, um den Kubernetes-Stack insgesamt voranzubringen. Der Weg von Uber zur Kubernetes-Migration zeigt exemplarisch, wie technische Vision, rigoroses Engineering und Anpassungen auf höchstem Niveau zusammenwirken müssen, um den Anforderungen eines der weltweit größten und dynamischsten Serviceanbieter gerecht zu werden.
Die strategische Verlagerung zu einem offenen, weit verbreiteten Standard trägt zur langfristigen Stabilität, Sicherheit und Flexibilität bei. Dabei bleibt die Nutzer- und Entwicklererfahrung kontinuierlich im Fokus, die durch Automatisierung und Transparenz bestmöglich unterstützt wird. Ubers technische Reise eröffnet wertvolle Einblicke in die Herausforderungen großskaliger Cloud-Infrastrukturen und unterstreicht die Wichtigkeit von Innovation gepaart mit bewährter Praxis in der Welt der Container-Orchestrierung.
