Im digitalen Zeitalter, in dem Flexibilität und Skalierbarkeit von IT-Infrastrukturen entscheidend für den Erfolg von Unternehmen sind, setzt Uber mit seiner Migration von Apache Mesos zu Kubernetes einen Meilenstein. Die Umstellung der Compute-Plattform auf Kubernetes stellt für das Unternehmen eine strategisch bedeutende Veränderung dar, welche die Grundlage für eine zukunftssichere, robuste und agile Infrastruktur legt. Dabei wurden zahlreiche Herausforderungen gemeistert, innovative Lösungen implementiert und der Service für Entwickler nahtlos weitergeführt, ohne dass sie von der tiefgreifenden technischen Transformation betroffen waren. Ubers Container-Orchestrierungsplattform war über Jahre hinweg erfolgreich auf Apache Mesos aufgebaut, der als stabile Lösung für stateless Workloads galt. Doch mit der Deaktivierung von Mesos Ende 2021 bei Uber und der ausbleibenden Weiterentwicklung durch die Community wurde der Bedarf nach einer moderneren, von der Branche breit akzeptierten Plattform immer dringlicher.
Kubernetes hat sich seit Jahren als Industriestandard etabliert, wird von führenden Cloud-Anbietern nativ unterstützt und bringt durch seine lebendige Open-Source-Community kontinuierliche Updates sowie ein reichhaltiges Ökosystem an nützlichen Tools und Operatoren mit. Die Entscheidung, auf Kubernetes zu migrieren, fußt auf der Notwendigkeit, eine langfristig erweiterbare und sichere Grundlage für die zahlreichen Services des Unternehmens zu schaffen. Der Begriff Kubernetes steht für eine Container-Orchestrierungsplattform, die es Unternehmen ermöglicht, Container in großem Maßstab effizient zu verwalten, zu skalieren und zu automatisieren. Im Fall von Uber, das über 4000 Services besitzt, die rund 3 Millionen Cores gleichzeitig nutzen, ist diese Technologie essenziell, um die Anforderungen an Performance und Ausfallsicherheit zu erfüllen. Die Migration war daher nicht nur ein einfacher Technologiewechsel, sondern eine strategische Maßnahme, durch die das Unternehmen seine gesamte Compute-Infrastruktur neu definiert hat.
Ein zentrales Element bei Ubers Ansatz war der Betrieb extrem großer Kubernetes-Cluster mit bis zu 7500 Nodes. Während der industrieübliche Standard darin besteht, viele kleine Cluster zu betreiben, entschied sich Uber bewusst für einige wenige, jedoch sehr große Cluster. Dies fördert eine bessere Ressourcenausnutzung und reduziert den Overhead für das Kontrollsystem. Allerdings brachte diese Strategie erhebliche Herausforderungen mit sich, da größere Cluster anfälliger für Engpässe beim API-Server, den Scheduler und andere Kernkomponenten sind. Um diese Probleme zu lösen, entwickelte Uber spezifische Benchmarks und optimierte diverse Parameter wie die QPS-Einstellungen (Queries per Second) in den Controller-Managern sowie die Parallelität im Scheduler.
Außerdem führte das Unternehmen ein Prioritäts- und Fairness-System für API-Aufrufe ein, um Ressourcen besser zu steuern und teure Anfragen zu limitieren. Auch die Umstellung von JSON- auf Protocol Buffer (Proto) Encoding half, die Effizienz der Kommunikation zu steigern. Die Integration von Kubernetes in die bestehende Entwicklerumgebung bei Uber war eine weitere Herausforderung. Die bisherigen Services waren tief in die Mesos-Architektur eingebettet, weshalb viele Systeme rund um Continuous Integration/Continuous Deployment (CI/CD), Service Discovery, Sicherheitsmechanismen, Host-Lifecycle-Management und Observability neu gestaltet werden mussten. Besonders wichtig war es, die Entwickler von den komplexen Veränderungen zu entlasten.
Der für stateless Workloads zuständige Layer „Up“ abstrahiert die darunterliegenden Cluster-Technologien und ermöglicht so eine nahtlose Migration, bei der Service-Owner keinerlei Anpassungen oder manuelles Eingreifen vornehmen mussten. Dieser Automatisierungsgrad stellt sicher, dass Dienste sowohl auf Mesos als auch auf Kubernetes parallel betrieben werden können, ohne dass Nutzer überhaupt bemerken, auf welcher Plattform sie sich befinden. Neben der reinen Migration wurde großer Wert darauf gelegt, die Funktionalität und das Nutzererlebnis auf Kubernetes auf dem Niveau von Mesos zu halten. Besonders Entwickler profitieren bei Uber von Features wie der Langzeitaufbewahrung von Container-Artefakten, darunter Logs, Heap-Profile und Kernelspeicherabbilder, die im Mesos-System lokal gespeichert wurden. In Kubernetes säubern lokale Volumes die Datenstandardmäßig bei Pod-Löschungen, daher musste Uber eine eigene Lösung schaffen.
Dies wurde durch einen Sidecar-Container realisiert, der nach Beendigung der primären Anwendung weiterhin aktiv bleibt und über einen Daemon auf dem Host die Artefakte in einen Blob-Storage hochlädt. So erhalten Entwickler weiterhin Zugriff auf alle notwendigen Debugging-Daten. Ein weiteres Uber-spezifisches Feature ist die kontrollierte Skalierung sensibler Services. Manche Anwendungen reagieren empfindlich auf ruckartige Skalierungsänderungen, was zu temporären Instabilitäten führen kann. Die Standard-Kubernetes-Rolling-Update-Methoden adressieren primär Upgrade-Pace, nicht jedoch Skalierungsvorgänge selbst.
Uber implementierte daher eine eigene Logik in einem Custom Resource Controller, der Skalierungen in kleinen, sequenziellen Schritten durchführt und so die Stabilität während dynamischer Laständerungen gewährleistet. Die Beschleunigung von Deployments war eine weitere Optimierungsmaßnahme im Rahmen der Migration. Für besonders große Container wurde die Verwendung von CloneSet-Ressourcen eingeführt, die Inplace-Updates ermöglichen, anstatt komplette Pods neu zu starten. Ergänzt wurde dies durch einen Image-Prefetch-Daemon, der Images frühzeitig auf die Nodes aller Zonen herunterlädt, was Kaltstartzeiten deutlich verkürzt und Rollouts beschleunigt. Natürlich blieb auch die Kubernetes Benutzeroberfläche in ihrer ursprünglichen Form hinter den Ansprüchen von Uber zurück.
Die hohe Clustergröße führte dazu, dass das UI regelmäßig einfriert oder abstürzt. Uber konnte hier durch gezielte Optimierungen und Caching-Mechanismen die UI deutlich stabiler und reaktionsschneller machen, sodass auch Administratoren große Cluster komfortabel und effizient verwalten können. Während der Migration traten einige unerwartete Schwierigkeiten auf, etwa bei der Überwachung der Cluster-Gesundheit. Standardtools boten keine ausreichende Sicht auf Ressourcenfragmentierung, Pod-Platzierungsprobleme oder die Auswirkungen von häufigen Updates und Neustarts. Als Antwort darauf entwickelte Uber eine eigene Observability-Plattform, welche detaillierte Metriken zu diesen Aspekten liefert und somit frühe Warnungen bei Problemen ermöglicht.
Ein besonderes Hindernis stellte der Kubernetes Informer-Reconciliation-Prozess dar, der etwa alle 8-10 Stunden sämtliche Events erneut abspielt. Aufgrund später übersehener Deployment-Events kam es zu teils stundenlangen Verzögerungen. Uber implementierte eine eigene Reconciliation-Logik mit deutlich kürzeren Intervallen von 15 Minuten, um die Zuverlässigkeit und Geschwindigkeit von Aktualisierungen zu verbessern. Auch Rollbacks wurden durch neuartige Heuristiken beschleunigt. Die Standard-Mechanismen basierend auf Progess-Deadline-Zeitüberschreitungen waren langsam und unzuverlässig, zumal manche Services keine aktiven Health-Checks haben oder längst verzögerte Checks verwenden.
Uber entwickelte einen Ansatz, der anhand von Container-Restarts entscheidet, wann automatische Rollbacks ausgelöst werden, etwa wenn mehr als 10 Prozent der Pods fünfmal oder öfter neu starten. Der Migrationsprozess erstreckte sich über eineinhalb Jahre, in der es auch strategische Pausen gab, um Probleme zu beheben und die Stabilität der Plattform zu gewährleisten. Besonders im ersten Teil der Migration konzentrierte sich das Team auf die Feinjustierung der Custom-Controller und Operatoren, um eine gleichbleibende Performance sicherzustellen. Nach der Konsolidierung beschleunigte sich der Prozess erheblich, so dass in Spitzenzeiten mehr als 300.000 Cores pro Woche migriert wurden.
Mit dem Abschluss der Migration der Shared Stateless Workloads zu Kubernetes öffnet sich für Uber nun die nächste Phase. Ziel ist es, sämtliche Cluster-orchestrierten Workloads, einschließlich Batch-Processing mit Apache Hadoop YARN und Stateful Workloads mit Odin, ebenfalls auf Kubernetes zu vereinheitlichen. Diese komplette Konvergenz verspricht Vereinfachung im Betrieb sowie Effizienzsteigerungen. Ein weiterer Schwerpunkt liegt auf dem Open-Source-Engagement. Uber plant, eigene Innovationen, die während der Migration entstanden sind, mit der Community zu teilen, um gemeinsam von den entwickelten Lösungen zu profitieren und die Zukunft von Kubernetes aktiv mitzugestalten.
