Notiz. übersetzen: Dailymotion ist einer der weltweit größten Video-Hosting-Dienste und daher ein bemerkenswerter Kubernetes-Benutzer. In diesem Material teilt Systemarchitekt David Donchez die Ergebnisse der Erstellung der Produktionsplattform des Unternehmens auf Basis von K8s mit, die mit einer Cloud-Installation in GKE begann und als Hybridlösung endete, die bessere Reaktionszeiten und Einsparungen bei den Infrastrukturkosten ermöglichte.
Entscheidung, die Kern-API neu zu erstellen Vor drei Jahren wollten wir eine effizientere und einfachere Möglichkeit zum Hosten von Anwendungen entwickeln . Zu diesem Zweck haben wir uns für den Einsatz einer Container-Orchestrierungsplattform entschieden und uns natürlich für Kubernetes entschieden.
Warum lohnt es sich, eine eigene Plattform auf Basis von Kubernetes aufzubauen?
API auf Produktionsebene im Handumdrehen mit Google Cloud
Sommer 2016
Vor drei Jahren, unmittelbar nachdem Dailymotion gekauft wurde Unsere Entwicklungsteams konzentrieren sich auf ein globales Ziel: die Entwicklung eines völlig neuen Dailymotion-Produkts.
Aufgrund unserer Analyse von Containern, Orchestrierungslösungen und unserer bisherigen Erfahrungen sind wir überzeugt, dass Kubernetes die richtige Wahl ist. Einige Entwickler hatten bereits ein Verständnis für die grundlegenden Konzepte und wussten, wie man sie anwendet, was ein großer Vorteil für die Infrastrukturtransformation war.
Aus infrastruktureller Sicht war ein leistungsstarkes und flexibles System erforderlich, um neue Arten von Cloud-nativen Anwendungen zu hosten. Wir haben uns zu Beginn unserer Reise dafür entschieden, in der Cloud zu bleiben, damit wir beruhigt die robusteste On-Premise-Plattform aufbauen können, die möglich ist. Wir haben uns entschieden, unsere Anwendungen mithilfe der Google Kubernetes Engine bereitzustellen, obwohl wir wussten, dass wir früher oder später in unsere eigenen Rechenzentren umziehen und eine Hybridstrategie anwenden würden.
Warum haben Sie sich für GKE entschieden?
Wir haben diese Wahl hauptsächlich aus technischen Gründen getroffen. Darüber hinaus war es notwendig, schnell eine Infrastruktur bereitzustellen, die den Geschäftsanforderungen des Unternehmens entspricht. Wir hatten einige Anforderungen an Hosting-Anwendungen, wie z. B. geografische Verteilung, Skalierbarkeit und Fehlertoleranz.
GKE-Cluster in Dailymotion
Da es sich bei Dailymotion um eine weltweit verfügbare Videoplattform handelt, wollten wir unbedingt die Qualität des Service verbessern, indem wir die Wartezeit verkürzen (Latenz). Vorher war nur in Paris verfügbar, was nicht optimal war. Ich wollte Bewerbungen nicht nur in Europa, sondern auch in Asien und den USA hosten können.
Aufgrund dieser Latenzempfindlichkeit waren umfangreiche Arbeiten an der Netzwerkarchitektur der Plattform erforderlich. Während Sie bei den meisten Cloud-Diensten gezwungen waren, in jeder Region ein eigenes Netzwerk zu erstellen und diese dann über ein VPN oder einen verwalteten Dienst zu verbinden, konnten Sie mit Google Cloud ein vollständig routbares einzelnes Netzwerk erstellen, das alle Google-Regionen abdeckt. Dies ist ein großes Plus im Hinblick auf Betrieb und Effizienz des Systems.
Darüber hinaus leisten Netzwerkdienste und Load Balancer von Google Cloud hervorragende Arbeit. Sie ermöglichen Ihnen lediglich die Verwendung beliebiger öffentlicher IP-Adressen aus jeder Region, und das wunderbare BGP-Protokoll kümmert sich um den Rest (d. h. die Umleitung der Benutzer zum nächstgelegenen Cluster). Offensichtlich wird der Verkehr im Falle eines Fehlers automatisch in eine andere Region umgeleitet, ohne dass ein menschliches Eingreifen erforderlich ist.
Überwachung des Google Load Balancing
Unsere Plattform nutzt auch intensiv GPUs. Mit Google Cloud können Sie diese sehr effektiv direkt in Kubernetes-Clustern nutzen.
Damals konzentrierte sich das Infrastrukturteam hauptsächlich auf den Legacy-Stack, der auf physischen Servern bereitgestellt wurde. Aus diesem Grund erfüllte der Einsatz eines verwalteten Dienstes (einschließlich Kubernetes-Master) unsere Anforderungen und ermöglichte es uns, Teams für die Arbeit mit lokalen Clustern zu schulen.
Dadurch konnten wir bereits 6 Monate nach Beginn der Arbeiten mit dem Empfang von Produktionsverkehr auf der Google Cloud-Infrastruktur beginnen.
Allerdings ist die Zusammenarbeit mit einem Cloud-Anbieter trotz einer Reihe von Vorteilen mit gewissen Kosten verbunden, die je nach Auslastung steigen können. Aus diesem Grund haben wir jeden von uns genutzten Managed Service sorgfältig analysiert, in der Hoffnung, ihn in Zukunft vor Ort implementieren zu können. Tatsächlich begann die Implementierung lokaler Cluster bereits Ende 2016 und gleichzeitig wurde die Hybridstrategie initiiert.
Einführung der lokalen Container-Orchestrierungsplattform Dailymotion
Herbst '2016
Unter Bedingungen, als der gesamte Stapel für die Produktion bereit war und an der API gearbeitet wurde war es an der Zeit, sich auf regionale Cluster zu konzentrieren.
Zu dieser Zeit sahen sich die Nutzer jeden Monat mehr als 3 Milliarden Videos an. Natürlich verfügen wir seit vielen Jahren über ein eigenes umfangreiches Content Delivery Network. Diesen Umstand wollten wir ausnutzen und Kubernetes-Cluster in bestehenden Rechenzentren einsetzen.
Die Infrastruktur von Dailymotion bestand aus mehr als 2,5 Tausend Servern in sechs Rechenzentren. Alle werden mit Saltstack konfiguriert. Wir begannen, alle notwendigen Rezepte für die Erstellung von Master- und Worker-Knoten sowie eines etcd-Clusters vorzubereiten.
Netzwerkteil
Unser Netzwerk ist komplett geroutet. Jeder Server gibt seine IP im Netzwerk mithilfe von Exabgp bekannt. Wir haben mehrere Netzwerk-Plugins verglichen und das einzige, das alle Anforderungen erfüllte (aufgrund des verwendeten L3-Ansatzes), war . Es fügt sich perfekt in das bestehende Netzwerkinfrastrukturmodell ein.
Da wir alle verfügbaren Infrastrukturelemente nutzen wollten, mussten wir zunächst unser selbst entwickeltes Netzwerkdienstprogramm (das auf allen Servern verwendet wird) herausfinden: Verwenden Sie es, um IP-Adressbereiche im Netzwerk mit Kubernetes-Knoten anzukündigen. Wir haben Calico erlaubt, Pods IP-Adressen zuzuweisen, haben es jedoch nicht für BGP-Sitzungen auf Netzwerkgeräten verwendet und werden es immer noch nicht verwenden. Tatsächlich wird das Routing von Exabgp übernommen, das die von Calico verwendeten Subnetze ankündigt. Dadurch können wir jeden Pod aus dem internen Netzwerk (und insbesondere von Load Balancern) erreichen.
Wie wir den eingehenden Datenverkehr verwalten
Um eingehende Anfragen an den gewünschten Dienst umzuleiten, entschied man sich aufgrund der Integration mit Kubernetes-Ingress-Ressourcen für den Einsatz des Ingress Controllers.
Vor drei Jahren war nginx-ingress-controller der ausgereifteste Controller: Nginx gab es schon lange und war für seine Stabilität und Leistung bekannt.
In unserem System haben wir uns entschieden, die Controller auf dedizierten 10-Gigabit-Blade-Servern zu platzieren. Jeder Controller war mit dem kube-apiserver-Endpunkt des entsprechenden Clusters verbunden. Diese Server verwendeten Exabgp auch, um öffentliche oder private IP-Adressen bekannt zu geben. Unsere Netzwerktopologie ermöglicht es uns, BGP von diesen Controllern zu verwenden, um den gesamten Datenverkehr direkt an die Pods weiterzuleiten, ohne einen Dienst wie NodePort zu verwenden. Dieser Ansatz hilft, horizontalen Verkehr zwischen Knoten zu vermeiden und die Effizienz zu verbessern.
Verkehrsbewegung vom Internet zu Pods
Nachdem wir nun unsere Hybridplattform verstanden haben, können wir tiefer in den Traffic-Migrationsprozess selbst eintauchen.
Migration des Datenverkehrs von Google Cloud zur Dailymotion-Infrastruktur
Herbst '2018
Nach fast zwei Jahren des Aufbaus, Testens und Optimierens haben wir endlich einen vollständigen Kubernetes-Stack, der bereit ist, etwas Datenverkehr zu akzeptieren.
Die aktuelle Routing-Strategie ist recht einfach, aber ausreichend, um die Anforderungen zu erfüllen. Zusätzlich zu öffentlichen IPs (auf Google Cloud und Dailymotion) wird AWS Route 53 verwendet, um Richtlinien festzulegen und Benutzer auf den Cluster unserer Wahl umzuleiten.
Beispiel einer Routing-Richtlinie mit Route 53
Mit Google Cloud ist dies einfach, da wir in allen Clustern eine einzige IP teilen und der Benutzer zum nächstgelegenen GKE-Cluster weitergeleitet wird. Für unsere Cluster ist die Technologie anders, da ihre IPs unterschiedlich sind.
Während der Migration haben wir versucht, regionale Anfragen an die entsprechenden Cluster umzuleiten und die Vorteile dieses Ansatzes bewertet.
Da unsere GKE-Cluster für die automatische Skalierung mithilfe benutzerdefinierter Metriken konfiguriert sind, skalieren sie basierend auf dem eingehenden Datenverkehr nach oben/unten.
Im Normalmodus wird der gesamte regionale Datenverkehr an den lokalen Cluster weitergeleitet und GKE dient als Reserve bei Problemen (Gesundheitsprüfungen werden von Route 53 durchgeführt).
...
In Zukunft wollen wir Routing-Richtlinien vollständig automatisieren, um eine autonome Hybridstrategie zu erreichen, die die Erreichbarkeit für Benutzer kontinuierlich verbessert. Positiv zu vermerken ist, dass die Cloud-Kosten erheblich gesenkt und die API-Antwortzeiten sogar verkürzt wurden. Wir vertrauen der resultierenden Cloud-Plattform und sind bereit, bei Bedarf mehr Datenverkehr dorthin umzuleiten.
PS vom Übersetzer
Vielleicht interessiert Sie auch ein weiterer aktueller Dailymotion-Beitrag über Kubernetes. Es widmet sich der Bereitstellung von Anwendungen mit Helm auf vielen Kubernetes-Clustern und vor ungefähr einem Monat.
Lesen Sie auch auf unserem Blog:
- «".
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «".
Source: habr.com