Hinweis.: Dailymotion — einer der größten Video-Hosting-Dienste weltweit und daher ein bedeutender Nutzer von Kubernetes. In diesem Artikel teilt der Systemarchitekt David Donchez die Ergebnisse der Erstellung der Produktionsplattform des Unternehmens basierend auf K8s, die mit einer Cloud-Installation in GKE begann und als hybrides Konzept endete, was zu einer besseren Reaktionszeit führte und Infrastrukturkosten einsparten.
Bei der Entscheidung über den Umbau der Haupt-API vor drei Jahren wollten wir eine effizientere Methode zur Bereitstellung von Anwendungen entwickeln und Zu diesem Zweck entschieden wir uns, eine Container-Orchestrierungsplattform zu nutzen, und wählten selbstverständlich Kubernetes.
Warum eine eigene Plattform auf Basis von Kubernetes erstellen?
API auf Produktionsniveau in kürzester Zeit mit Google Cloud
Sommer 2016
Vor drei Jahren, unmittelbar nach dem Kauf von Dailymotion durch , konzentrierten sich unsere Ingenieurteams auf ein globales Ziel: ein völlig neues Produkt für Dailymotion zu schaffen.
Nach der Analyse von Containern, Orchestrierungslösungen und unserer bisherigen Erfahrung sind wir zu dem Schluss gekommen, dass Kubernetes die richtige Wahl ist. Teilweise hatten Entwickler bereits ein grundlegendes Verständnis der Konzepte und wussten, wie man es nutzt, was ein enormes Plus für die infrastrukturelle Transformation war.
In Bezug auf die Infrastruktur benötigten wir ein leistungsfähiges und flexibles System zur Bereitstellung neuer Arten von cloud-native Anwendungen. Zu Beginn unseres Weges entschieden wir uns für die Cloud, um in Ruhe eine höchst zuverlässige lokale Plattform aufzubauen. Unsere Anwendungen wurden mit Google Kubernetes Engine bereitgestellt, obwohl wir wussten, dass wir früher oder später auf unsere eigenen Rechenzentren umsteigen und eine hybrides Strategie anwenden würden.
Warum haben wir GKE gewählt?
Diese Entscheidung fiel hauptsächlich aus technischen Gründen. Darüber hinaus war es erforderlich, schnell eine Infrastruktur bereitzustellen, die den Bedürfnissen des Unternehmens gerecht wird. Wir hatten bestimmte Anforderungen an die Bereitstellung von Anwendungen, wie z. B. geografische Verteilung, Skalierbarkeit und Hochverfügbarkeit.
GKE-Cluster bei Dailymotion
Da Dailymotion eine weltweit zugängliche Video-Plattform ist, wollten wir die Servicequalität erheblich verbessern und die Wartezeiten reduzieren. (Latenz). Zuvor 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 zu hosten.
Diese Sensibilität gegenüber Latenzen bedeutete, dass wir ernsthaft an der Netzwerkarchitektur der Plattform arbeiten mussten. Während die meisten Cloud-Dienste erforderten, dass man in jeder Region ein eigenes Netzwerk aufbaut und diese über VPN oder einen verwalteten Dienst verbindet, ermöglichte Google Cloud die Schaffung eines vollständig routierbaren einheitlichen Netzwerks, das alle Regionen von Google abdeckt. Das ist ein großer Vorteil in Bezug auf Betrieb und Systemeffizienz.
Darüber hinaus funktionieren Netzwerddienste und Lastenausgleicher von Google Cloud hervorragend. Sie ermöglichen die Nutzung beliebiger öffentlicher IP-Adressen aus jeder Region, während das beeindruckende BGP-Protokoll sich um den Rest kümmert (d. h. es leitet die Benutzer zum nächstgelegenen Cluster). Offensichtlich wird der Datenverkehr im Falle eines Ausfalls automatisch in eine andere Region umgeleitet, ohne dass menschliches Eingreifen erforderlich ist.
Überwachung der Lastenverteilung bei Google
Unsere Plattform nutzt auch GPUs aktiv. 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 Services (einschließlich der Master-Komponenten von Kubernetes) unsere Anforderungen und ermöglichte es den Teams, den Umgang mit lokalen Clustern zu erlernen.
Infolgedessen konnten wir nach nur 6 Monaten seit Projektbeginn den Produktionsverkehr auf der Infrastruktur von Google Cloud aufnehmen.
Trotz einer Reihe von Vorteilen bringt die Zusammenarbeit mit einem Cloud-Anbieter jedoch bestimmte Kosten mit sich, die je nach Auslastung steigen können. Deshalb haben wir jeden verwalteten Service sorgfältig analysiert, um diese künftig in der eigenen Infrastruktur zu implementieren. Tatsächlich begann die Einführung lokaler Cluster Ende 2016, und zu diesem Zeitpunkt wurde eine hybride Strategie eingeleitet.
Start der lokalen Container-Orchestrierungsplattform Dailymotion
Herbst 2016
In der Phase, in der der gesamte Stack für die Produktion bereit war und die Arbeiten am API , war es an der Zeit, sich auf die regionalen 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 mehreren Jahren bestanden. Wir wollten diese Gegebenheit nutzen und Kubernetes-Cluster in bestehenden Rechenzentren bereitstellen.
Die Infrastruktur von Dailymotion umfasst über 2.500 Server in sechs Rechenzentren. Alle werden mithilfe von Saltstack konfiguriert. Wir haben damit begonnen, alle notwendigen Rezepte zur Erstellung von Master- und Worker-Knoten sowie eines etcd-Clusters vorzubereiten.
Netzwerkbereich
Unser Netzwerk ist vollständig routierbar. Jeder Server kündigt seine IP im Netzwerk über Exabgp an. Wir haben mehrere Netzwerk-Plugins verglichen, und das einzig alle Anforderungen erfüllende Plugin (aufgrund des verwendeten L3-Ansatzes) war . Es fügte sich hervorragend in das bestehende Netzwerkmodell der Infrastruktur ein.
Da wir alle vorhandenen Infrastruktur-Elemente nutzen wollten, war es zunächst notwendig, uns mit unserem hauseigenen Netzwerk-Tool auseinanderzusetzen (das auf allen Servern genutzt wird): Es sollte zur Ankündigung von IP-Adressbereichen im Netzwerk mit Kubernetes-Knoten verwendet werden. Wir ließen Calico IP-Adressen den Pods zuweisen, verwenden es jedoch nicht für BGP-Sitzungen auf der Netzwerkausrüstung. Tatsächlich wird das Routing von Exabgp übernommen, das die von Calico genutzten Subnetze ankündigt. Dies ermöglicht uns den Zugriff auf jeden Pod aus dem internen Netzwerk (insbesondere von den Lastenausgleichern).
Wie wir den Ingress-Verkehr verwalten
Um eingehende Anfragen an den entsprechenden Dienst weiterzuleiten, haben wir uns entschieden, den Ingress Controller zu nutzen, da dieser gut mit den Ingress-Ressourcen von Kubernetes integriert ist.
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 uns entschieden, Controller auf dedizierten 10-Gigabit-Blade-Servern zu platzieren. Jeder Controller war mit dem Endpoint kube-apiserver des entsprechenden Clusters verbunden. Auf diesen Servern wurde auch Exabgp verwendet, um öffentliche oder private IP-Adressen zu annoncieren. Die Topologie unseres Netzwerks ermöglicht es, BGP von diesen Controllern zu nutzen, um den gesamten Traffic direkt zu den Pods zu routen, ohne einen NodePort-Service zu verwenden. Dieser Ansatz hilft, den horizontalen Traffic zwischen den Knoten zu vermeiden und erhöht die Effizienz.
Traffic von Internet zu Pods
Jetzt, da wir unsere hybride Plattform geklärt haben, können wir tiefer in den Prozess der Traffic-Migration eintauchen.
Traffic-Migration von Google Cloud zur Dailymotion-Infrastruktur
Herbst 2018
Nach fast zwei Jahren der Entwicklung, Tests und Konfiguration haben wir schließlich einen vollständigen Kubernetes-Stack, der bereit ist, einen Teil des Traffics aufzunehmen.
Die aktuelle Routing-Strategie ist recht einfach, erfüllt jedoch die Bedürfnisse voll und ganz. Neben öffentlichen IPs (in Google Cloud und Dailymotion) wird AWS Route 53 verwendet, um Richtlinien festzulegen und Benutzer nach unserem gewählten Cluster weiterzuleiten.
Beispiel für eine Routing-Policy mit Route 53
Mit Google Cloud ist das einfach, da wir eine einzige IP-Adresse für alle Cluster verwenden und der Benutzer zum nächstgelegenen GKE-Cluster umgeleitet wird. Für unsere Cluster nutzen wir eine andere Technologie, da ihre IP-Adressen unterschiedlich sind.
Während der Migration haben wir angestrebt, regionale Anfragen an die entsprechenden Cluster weiterzuleiten und die Vorteile dieses Ansatzes zu bewerten.
Da unsere GKE-Cluster für die automatische Skalierung mit benutzerdefinierten Metriken konfiguriert sind, passen sie ihre Kapazitäten je nach eingehendem Verkehr an.
Im Normalbetrieb wird der gesamte regionale Verkehr an das lokale Cluster geleitet, während GKE als Backup für den Fall von Problemen dient (Health-Checks werden über Route 53 durchgeführt).
…
In Zukunft wollen wir die Routingrichtlinien vollständig automatisieren, um eine autonome Hybridstrategie zu entwickeln, die die Verfügbarkeit für die Benutzer kontinuierlich verbessert. Die Vorteile sind unter anderem eine signifikante Senkung der Cloud-Kosten und eine verkürzte API-Reaktionszeit. Wir vertrauen der entstandenen Cloud-Plattform und sind bereit, bei Bedarf mehr Traffic dorthin umzuleiten.
P.S. vom Übersetzer
Vielleicht interessiert Sie auch ein weiterer aktueller Beitrag von Dailymotion über Kubernetes. Dieser behandelt das Deployment von Anwendungen mit Helm auf mehreren Kubernetes-Clustern und vor etwa einem Monat.
Lesen Sie auch in unserem Blog:
- «».
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
