🥇Kubernetes-Abenteuer Dailymotion: Infrastruktur in der Cloud + On-Premises

Anmerkung des Übersetzers.: Dailymotion ist einer der größten Video-Hosting-Dienste der Welt und deshalb ein bemerkenswerter Nutzer von Kubernetes. In diesem Artikel teilt der Systemarchitekt David Donchez die Ergebnisse der Erstellung der Produktionsplattform des Unternehmens auf Basis von K8s, die mit einer Cloud-Installation in GKE begann und als hybride Lösung endete, was es ermöglichte, bessere Reaktionszeiten zu erreichen und Infrastrukturkosten zu sparen.

Bei der Entscheidung über den Umbau der Haupt-API Dailymotion vor drei Jahren wollten wir einen effizienteren Weg zur Bereitstellung von Anwendungen entwickeln und die Prozesse in der Entwicklung und Produktion. Zu diesem Zweck entschieden wir uns, eine Container-Orchestrierungsplattform zu verwenden und wählten natürlich Kubernetes.

Warum eine eigene Plattform auf Basis von Kubernetes erstellen?

API-Produktionsniveau in kürzester Zeit mit Google Cloud

Sommer 2016

Vor drei Jahren, kurz nach der Übernahme von Dailymotion durch Vivendi, konzentrierten sich unsere Engineering-Teams auf ein globales Ziel: ein völlig neues Produkt von Dailymotion zu schaffen.

Nach der Analyse von Containern, Orchestrierungslösungen und unserer vergangenen Erfahrung waren wir überzeugt, dass Kubernetes die richtige Wahl ist. Ein Teil der Entwickler hatte bereits Kenntnisse über die grundlegenden Konzepte und wusste, wie man es einsetzt, was ein großer Vorteil für die infrastrukturelle Transformation war.

Aus infrastruktureller Sicht war ein leistungsstarkes und flexibles System für die Bereitstellung neuer Arten von Cloud-nativen Anwendungen erforderlich. Zu Beginn unserer Reise zogen wir es vor, in der Cloud zu bleiben, um eine möglichst zuverlässige lokale Plattform aufzubauen. Wir beschlossen, unsere Anwendungen über Google Kubernetes Engine bereitzustellen, obwohl wir wussten, dass wir früher oder später auf unsere eigenen Rechenzentren umsteigen und eine hybride Strategie anwenden würden.

Warum GKE gewählt?

Wir trafen diese Wahl hauptsächlich aus technischen Gründen. Außerdem war es notwendig, die Infrastruktur schnell bereitzustellen, die den Anforderungen des Unternehmens gerecht wurde. Wir hatten einige Anforderungen an die Bereitstellung von Anwendungen, wie geografische Verteilung, Skalierbarkeit und Ausfallsicherheit.

GKE-Cluster bei Dailymotion

Da Dailymotion eine Video-Plattform ist, die weltweit verfügbar ist, wollten wir die Servicequalität verbessern und die Wartezeit (latency)reduzieren. Zuvor war unsere API war nur in Paris verfügbar, was suboptimal war. Es wäre wünschenswert gewesen, Anwendungen nicht nur in Europa, sondern auch in Asien und den USA bereitstellen zu können.

Diese Sensibilität gegenüber Verzögerungen bedeutete, dass wir ernsthaft an der Netzwerkarchitektur der Plattform arbeiten mussten. Während die meisten Cloud-Dienste es erforderten, ein eigenes Netzwerk in jeder Region zu erstellen und diese dann über VPN oder einen bestimmten verwalteten Dienst zu verbinden, ermöglichte Google Cloud die Schaffung eines vollständig routierbaren einheitlichen Netzwerks, das alle Google-Regionen abdeckte. Dies ist ein großer Vorteil in Bezug auf Betrieb und Effizienz des Systems.

Darüber hinaus leisten die Netzwerkdienste und Lastenausgleichsmechanismen von Google Cloud hervorragende Arbeit. Sie ermöglichen einfach die Verwendung beliebiger öffentlicher IP-Adressen aus jeder Region, und das großartige BGP-Protokoll kümmert sich um den Rest (d. h. es leitet Benutzer zum nächstgelegenen Cluster weiter). Offensichtlich wird im Falle eines Ausfalls der Verkehr automatisch in eine andere Region geleitet, ohne dass menschliches Eingreifen erforderlich ist.

Überwachung des Lastenausgleichs in Google

Unsere Plattform nutzt auch aktiv Grafikprozessoren. Google Cloud ermöglicht es, diese direkt in Kubernetes-Clustern sehr effizient zu nutzen.

Zur gleichen Zeit konzentrierte sich das Infrastrukturteam überwiegend auf den alten Stack, der auf physischen Servern bereitgestellt war. Aus diesem Grund entsprach die Nutzung des verwalteten Dienstes (einschließlich der Master-Komponenten von Kubernetes) unseren Anforderungen und ermöglichte es, Teams in der Arbeit mit lokalen Clustern zu schulen.

Infolgedessen konnten wir bereits 6 Monate nach Beginn der Arbeiten den Produktivverkehr auf der Google Cloud-Infrastruktur annehmen.

Trotz einer Reihe von Vorteilen sind die Arbeiten mit einem Cloud-Anbieter mit bestimmten Kosten verbunden, die je nach Last steigen können. Daher haben wir jeden genutzten verwalteten Dienst sorgfältig analysiert, um in Zukunft deren Implementierung bei uns vor Ort zu realisieren. Tatsächlich begann die Einführung lokaler Cluster Ende 2016, und auch die hybride Strategie wurde damals initiiert.

Start der lokalen Container-Orchestrierungsplattform Dailymotion

Herbst 2016

In einem Umfeld, in dem der gesamte Stack bereit für die Produktion war, während die Arbeit am API noch fortgesetzt wurde, es war Zeit, sich auf regionale Cluster zu konzentrieren.

Zu diesem Zeitpunkt sahen die Nutzer monatlich über 3 Milliarden Videos. Natürlich hatte unser eigenes, umfangreiches Content Delivery Network bereits seit mehr als einem Jahr funktioniert. Wir wollten diese Gegebenheit nutzen und Kubernetes-Cluster in bestehenden Rechenzentren einrichten.

Die Infrastruktur von Dailymotion umfasste mehr als 2.500 Server in sechs Rechenzentren. Alle wurden mit Saltstack konfiguriert. Wir begannen mit der Vorbereitung aller notwendigen Rezepte zur Erstellung von Master- und Worker-Knoten sowie des etcd-Clusters.

Netzwerk

Unser Netzwerk ist vollständig routierbar. Jeder Server kündigt seine IP im Netzwerk mithilfe von Exabgp an. Wir haben mehrere Netzwerk-Plugins verglichen, und das einzige, das alle Anforderungen erfüllte (aufgrund des verwendeten L3-Ansatzes), war Calico. Es fügte sich hervorragend in das bestehende Netzwerkmodell der Infrastruktur ein.

Da wir alle vorhandenen Infrastrukturelemente nutzen wollten, mussten wir uns zunächst mit unserem hausgemachten Netzwerk-Utility (das auf allen Servern verwendet wird) befassen: Wir nutzen es zur Ankündigung von IP-Adressbereichen im Netzwerk mit Kubernetes-Knoten. Wir haben Calico erlaubt, IP-Adressen an Pods zuzuweisen, verwenden es jedoch nicht und haben es bisher nicht für BGP-Sitzungen auf Netzwerkausrüstung eingesetzt. Tatsächlich übernimmt Exabgp das Routing, das Subnetze ankündigt, die von Calico verwendet werden. Dies ermöglicht es uns, von einem internen Netzwerk aus auf jeden Pod zuzugreifen (insbesondere von den Lastverteilern).

Wie wir den Ingress-Verkehr verwalten

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

Vor drei Jahren war der nginx-ingress-controller der ausgereifteste Controller: Nginx wird schon lange verwendet und ist bekannt für seine Stabilität und Performance.

In unserem System haben wir beschlossen, die Controller auf dedizierten 10-Gigabit-Blade-Servern zu platzieren. Jeder Controller wurde mit dem Endpoint des kube-apiserver des entsprechenden Clusters verbunden. Auf diesen Servern wurde ebenfalls Exabgp zur Ankündigung öffentlicher oder privater IP-Adressen eingesetzt. Die Topologie unseres Netzwerks ermöglicht es, BGP von diesen Controllern zur direkten Weiterleitung des gesamten Verkehrs zu den Pods zu verwenden, ohne einen Service wie NodePort zu nutzen. Ein solcher Ansatz hilft, den horizontalen Verkehr zwischen den Knoten zu vermeiden und die Effizienz zu steigern.

Der Datenverkehr von Internet zu Pods

Jetzt, da wir unsere hybride Plattform verstanden haben, können wir uns eingehender mit dem Prozess der Verkehrsübergabe beschäftigen.

Verkehrsübergabe von Google Cloud zur Dailymotion-Infrastruktur

Herbst 2018

Nach fast zwei Jahren der Erstellung, des Testens und der Konfiguration haben wir endlich einen vollständigen Kubernetes-Stack, der bereit ist, einen Teil des Verkehrs zu übernehmen.

Die derzeitige Routingstrategie ist recht einfach, erfüllt aber die Anforderungen. Neben den öffentlichen IPs (in Google Cloud und Dailymotion) wird AWS Route 53 verwendet, um Richtlinien zu erstellen und Benutzer zu dem Cluster weiterzuleiten, das wir wählen.

Beispiel für eine Routingrichtlinie mit Route 53

Mit Google Cloud ist es einfach, da wir eine einheitliche IP für alle Cluster verwenden, und der Benutzer zu dem nächstgelegenen GKE-Cluster weitergeleitet wird. Für unsere Cluster ist die Technologie anders, da sich ihre IPs unterscheiden.

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

Da unsere GKE-Cluster auf automatisches Skalieren mit benutzerdefinierten Metriken konfiguriert sind, erhöhen oder verringern sie die Kapazitäten je nach eingehendem Verkehr.

Im Normalbetrieb wird der gesamte regionale Datenverkehr an das lokale Cluster geleitet, während GKE als Backup bei Problemen dient (Health-Checks werden von Route 53 durchgeführt).

…

In Zukunft möchten wir die Routing-Politik vollständig automatisieren, um eine autonome Hybridstrategie zu entwickeln, die die Verfügbarkeit für die Nutzer ständig verbessert. Was die Vorteile betrifft: Die Ausgaben für die Cloud wurden erheblich gesenkt, und es gelang sogar, die API-Reaktionszeiten zu verkürzen. Wir vertrauen der entstandenen Cloud-Plattform und sind bereit, bei Bedarf mehr Traffic darauf umzuleiten.

P.S. vom Übersetzer

Möglicherweise interessiert Sie auch eine andere aktuelle Veröffentlichung von Dailymotion zu Kubernetes. Sie 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: