🥇Kubernetes-Abenteuer bei Dailymotion: Aufbau einer Infrastruktur in der Cloud + vor Ort

Hinweis.: Dailymotion — einer der größten Video-Hosting-Dienste weltweit und daher ein prominenter Nutzer von Kubernetes. In diesem Artikel teilt Systemarchitekt David Donchez die Ergebnisse der Entwicklung der Produktionsplattform des Unternehmens auf Basis von K8s, die mit einer Cloud-Installation in GKE begann und als hybrid Lösung endete, was eine bessere Reaktionszeit und Einsparungen bei den Infrastrukturkosten ermöglichte.

Bei der Entscheidung zur Neugestaltung der Haupt-API Dailymotion vor drei Jahren wollten wir eine effizientere Methode zur Bereitstellung von Anwendungen entwickeln und die Entwicklungs- und Produktionsprozesse. Zu diesem Zweck entschieden wir uns für eine Container-Orchestrierungsplattform und wählten selbstverständlich Kubernetes aus.

Warum ist es sinnvoll, eine eigene Plattform auf Kubernetes-Basis zu schaffen?

API in Produktionsqualität in kürzester Zeit mit Google Cloud

Sommer 2016

Vor drei Jahren, unmittelbar nach dem Kauf von Dailymotion durch Vivendi, konzentrierten sich unsere Ingenieurteams auf ein gemeinsames Ziel: einen völlig neuen Dailymotion-Produkten zu schaffen.

Nach der Analyse von Containern, Orchestrierungslösungen und unserer bisherigen Erfahrung sind wir überzeugt, dass Kubernetes die richtige Wahl ist. Teilweise hatten die Entwickler bereits grundlegende Konzepte im Blick und wussten, wie man es anwendet, was ein enormes Plus für die infrastrukturelle Transformation war.

Infrastrukturell benötigten wir ein robustes und flexibles System für die Bereitstellung neuer Arten von Cloud-Anwendungen. Wir entschieden uns, zu Beginn unseres Weges in der Cloud zu bleiben, um eine möglichst zuverlässige lokale Plattform ruhig aufzubauen. Unsere Anwendungen wurden mit Google Kubernetes Engine bereitgestellt, obwohl uns bewusst war, dass wir früher oder später auf unsere eigenen Rechenzentren umsteigen und eine hybride Strategie anwenden würden.

Warum haben wir GKE gewählt?

Unsere Entscheidung basierte hauptsächlich auf technischen Überlegungen. Zudem war es erforderlich, die Infrastruktur schnell zu implementieren, um den geschäftlichen Anforderungen gerecht zu werden. Wir hatten einige Vorgaben für die Bereitstellung von Anwendungen, wie geografische Verteilung, Skalierbarkeit und Ausfallsicherheit.

GKE-Cluster bei Dailymotion

Da Dailymotion eine weltweit verfügbare Videoplattform ist, war es unser Bestreben, die Servicequalität durch die Reduzierung der Wartezeiten zu verbessern. (Latenz). Zuvor war unsere API nur in Paris verfügbar, was suboptimal war. Wir wollten die Möglichkeit haben, Anwendungen nicht nur in Europa, sondern auch in Asien und den USA bereitzustellen.

Diese Sensibilität für Latenzen bedeutete, dass wir intensiv an der Netzwerkarchitektur der Plattform arbeiten mussten. Während die meisten Cloud-Dienste erforderten, dass man ein Netzwerk in jeder Region aufbaute und diese dann über VPN oder einen verwalteten Dienst verband, ermöglichte Google Cloud die Schaffung eines vollständig routbaren einheitlichen Netzwerks, das alle Google-Regionen abdeckt. Dies ist ein großer Vorteil in Bezug auf Betrieb und Systemeffizienz.

Darüber hinaus arbeiten die Netzwerktechnologien und Lastenausgleicher von Google Cloud hervorragend. Sie ermöglichen die Nutzung beliebiger öffentlicher IP-Adressen aus jedem Gebiet, während das großartige BGP-Protokoll sich um den Rest kümmert (d.h. es leitet die Benutzer zum nächstgelegenen Cluster). Offensichtlich wird im Falle eines Ausfalls der Verkehr automatisch in eine andere Region umgeleitet, ohne menschliches Eingreifen.

Überwachung der Lastenausgleichung in Google

Unsere Plattform nutzt auch aktiv Grafikprozessoren. Google Cloud ermöglicht eine äußerst effiziente Nutzung dieser direkt in Kubernetes-Clustern.

Gleichzeitig konzentrierte sich das Infrastrukturteam hauptsächlich auf den alten Stack, der auf physischen Servern bereitgestellt wurde. Daher erfüllte die Nutzung des verwalteten Dienstes (einschließlich der Masterkomponenten von Kubernetes) unsere Anforderungen und erleichterte das Training der Teams im Umgang mit lokalen Clustern.

Infolgedessen konnten wir bereits 6 Monate nach Projektbeginn Produktionsverkehr auf der Infrastruktur von Google Cloud entgegennehmen.

Obwohl die Zusammenarbeit mit einem Cloud-Anbieter einige Vorteile bietet, sind damit auch bestimmte Kosten verbunden, die je nach Last steigen können. Aus diesem Grund haben wir jeden verwalteten Service sorgfältig analysiert, um diese in Zukunft in unserer eigenen Infrastruktur umzusetzen. Tatsächlich begann die Einführung lokaler Cluster Ende 2016, und zu diesem Zeitpunkt wurde auch eine hybride Strategie initiiert.

Start der lokalen Container-Orchestrierungsplattform von Dailymotion

Herbst 2016

In dem Moment, als der gesamte Stack produktionsbereit war und die Arbeiten an der API fortgesetzt wurden, war es an der Zeit, sich auf die regionalen Cluster zu konzentrieren.

Zu diesem Zeitpunkt schauten die Nutzer monatlich mehr als 3 Milliarden Videos. Natürlich betrieb bereits seit mehreren Jahren unser eigenes umfangreiches Content Delivery Network. Wir wollten diese Gelegenheit nutzen und Kubernetes-Cluster in bestehenden Rechenzentren implementieren.

Die Infrastruktur von Dailymotion umfasst über 2.500 Server in sechs Rechenzentren. Alle werden mithilfe von Saltstack konfiguriert. Wir haben begonnen, die erforderlichen Rezepte zur Erstellung von Master- und Worker-Knoten sowie eines etcd-Clusters vorzubereiten.

Netzwerkbereich

Unser Netzwerk ist vollständig routierbar. Jeder Server gibt seine IP-Adresse im Netzwerk über Exabgp bekannt. Wir haben mehrere Netzwerk-Plugins verglichen und das einzige, das allen Anforderungen gerecht wurde (aufgrund des verwendeten L3-Ansatzes), war Calico. Es fügte sich hervorragend in das bestehende Netzwerkmodell der Infrastruktur ein.

Da wir alle verfügbaren Infrastrukturkomponenten nutzen wollten, war es zunächst notwendig, uns mit unserem hauseigenen Netzwerktool (das auf allen Servern verwendet wird) auseinanderzusetzen: Es sollte verwendet werden, um IP-Adressbereiche in unserem Netzwerk mit Kubernetes-Knoten zu annoncierten. Wir haben Calico erlaubt, IP-Adressen für Pods zuzuweisen, verwenden es jedoch bis heute nicht für BGP-Sitzungen auf der Netzwerkausrüstung. Tatsächlich übernimmt Exabgp die Routenverwaltung, der die von Calico verwendeten Subnetze annonciert. Dies ermöglicht uns, auf jeden Pod aus dem internen Netzwerk zuzugreifen (insbesondere von den Lastenausgleichern aus).

Wie wir den Ingress-Traffic verwalten

Um eingehende Anfragen an den richtigen Dienst weiterzuleiten, haben wir uns entschieden, den Ingress Controller aufgrund seiner Integration mit den ingress-Ressourcen von Kubernetes zu verwenden.

Vor drei Jahren war der nginx-ingress-controller der am weitesten entwickelte Controller: Nginx wurde schon lange verwendet und war für seine Stabilität und Leistung bekannt.

In unserem System haben wir beschlossen, Controller auf dedizierten 10-Gigabit-Blade-Servern zu hosten. Jeder Controller war mit dem Endpoint des kube-apiserver des jeweiligen Clusters verbunden. Auf diesen Servern wurde auch Exabgp verwendet, um öffentliche oder private IP-Adressen anzukündigen. Die Topologie unseres Netzwerks ermöglicht es, BGP von diesen Controllern zu nutzen, um gesamten Traffic direkt an die Pods zu routen, ohne einen Dienst wie NodePort zu verwenden. Dieser Ansatz hilft, horizontalen Traffic zwischen den Knoten zu vermeiden und die Effizienz zu steigern.

Trafficbewegung aus dem Internet zu den Pods

Jetzt, da wir unser hybrides System verstanden haben, können wir tiefer in den Prozess der Trafficmigration eintauchen.

Migration des Traffics aus Google Cloud in die Infrastruktur von Dailymotion

Herbst 2018

Nach fast zwei Jahren der Erstellung, Tests und Anpassung haben wir endlich ein vollständiges Kubernetes-Stack, das bereit ist, einen Teil des Traffics zu übernehmen.

Die aktuelle Routing-Strategie ist ziemlich einfach, erfüllt aber die Bedürfnisse vollständig. Neben den öffentlichen IPs (in Google Cloud und Dailymotion) wird AWS Route 53 verwendet, um Richtlinien festzulegen und die Benutzer zu dem Cluster umzuleiten, den wir gewählt haben.

Beispiel für eine Routing-Policy mit Route 53

Mit Google Cloud ist das einfach, da wir eine einheitliche IP für alle Cluster verwenden und die Nutzer an den nächstgelegenen GKE-Cluster weitergeleitet werden. Für unsere Cluster hingegen ist die Technologie anders, da ihre IP-Adressen unterschiedlich sind.

Während der Migration strebten wir an, regionale Anfragen an die entsprechenden Cluster weiterzuleiten und bewerteten die Vorteile dieses Ansatzes.

Unsere GKE-Cluster sind so konfiguriert, dass sie mithilfe von benutzerdefinierten Metriken automatisch skalieren, wodurch sie je nach eingehendem Traffic Ressourcen hinzufügen oder reduzieren.

Im Normalbetrieb wird der gesamte regionale Traffic an den lokalen Cluster geleitet, während GKE als Backup dient, falls Probleme auftreten (Health-Checks werden von Route 53 durchgeführt).

…

In Zukunft möchten wir die Routing-Politiken vollständig automatisieren, um eine autonome Hybridstrategie zu entwickeln, die die Verfügbarkeit für die Nutzer kontinuierlich verbessert. Der Vorteil: Die Ausgaben für die Cloud wurden erheblich gesenkt, und auch die API-Reaktionszeiten konnten verkürzt werden. Wir vertrauen auf die entstandene Cloud-Plattform und sind bereit, bei Bedarf mehr Traffic darauf umzuleiten.

P.S. vom Übersetzer

Sie könnten sich auch für einen anderen aktuellen Dailymotion-Beitrag über Kubernetes interessieren. Dieser behandelt das Deployment von Anwendungen mit Helm auf mehreren Kubernetes-Clustern und wurde veröffentlicht vor etwa einem Monat.

Lesen Sie auch in unserem Blog: