{"id":36484,"date":"2019-10-31T22:11:54","date_gmt":"2019-10-31T19:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises\/"},"modified":"2019-10-31T22:11:54","modified_gmt":"2019-10-31T19:11:54","slug":"kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","title":{"rendered":"Tinders Umstieg auf Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Tinders
\n
\nAnmerkung des \u00dcbersetzers.<\/b>: Dailymotion ist einer der gr\u00f6\u00dften 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\u00f6sung endete, was es erm\u00f6glichte, bessere Reaktionszeiten zu erreichen und Infrastrukturkosten zu sparen.<\/i><\/p>\n

Bei der Entscheidung \u00fcber den Umbau der Haupt-API Dailymotion<\/a><\/noindex> vor drei Jahren wollten wir einen effizienteren Weg zur Bereitstellung von Anwendungen entwickeln und die Prozesse in der Entwicklung und Produktion<\/a><\/noindex>. Zu diesem Zweck entschieden wir uns, eine Container-Orchestrierungsplattform zu verwenden und w\u00e4hlten nat\u00fcrlich Kubernetes.<\/p>\n

Warum eine eigene Plattform auf Basis von Kubernetes erstellen?<\/a><\/noindex><\/p>\n

API-Produktionsniveau in k\u00fcrzester Zeit mit Google Cloud<\/h2>\n

<\/p>\n

Sommer 2016<\/p><\/blockquote>\n

\nVor drei Jahren, kurz nach der \u00dcbernahme von Dailymotion durch Vivendi<\/a><\/noindex>, konzentrierten sich unsere Engineering-Teams auf ein globales Ziel: ein v\u00f6llig neues Produkt von Dailymotion zu schaffen.<\/p>\n

Nach der Analyse von Containern, Orchestrierungsl\u00f6sungen und unserer vergangenen Erfahrung waren wir \u00fcberzeugt, dass Kubernetes die richtige Wahl ist. Ein Teil der Entwickler hatte bereits Kenntnisse \u00fcber die grundlegenden Konzepte und wusste, wie man es einsetzt, was ein gro\u00dfer Vorteil f\u00fcr die infrastrukturelle Transformation war.<\/p>\n

Aus infrastruktureller Sicht war ein leistungsstarkes und flexibles System f\u00fcr 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\u00f6glichst zuverl\u00e4ssige lokale Plattform aufzubauen. Wir beschlossen, unsere Anwendungen \u00fcber Google Kubernetes Engine bereitzustellen, obwohl wir wussten, dass wir fr\u00fcher oder sp\u00e4ter auf unsere eigenen Rechenzentren umsteigen und eine hybride Strategie anwenden w\u00fcrden.<\/p>\n

Warum GKE gew\u00e4hlt?<\/h3>\n

\nWir trafen diese Wahl haupts\u00e4chlich aus technischen Gr\u00fcnden. Au\u00dferdem 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.<\/p>\n

\"Tinders
\nGKE-Cluster bei Dailymotion<\/i><\/p>\n

Da Dailymotion eine Video-Plattform ist, die weltweit verf\u00fcgbar ist, wollten wir die Servicequalit\u00e4t verbessern und die Wartezeit (latency)<\/i>reduzieren. Zuvor war unsere API<\/a><\/noindex> war nur in Paris verf\u00fcgbar, was suboptimal war. Es w\u00e4re w\u00fcnschenswert gewesen, Anwendungen nicht nur in Europa, sondern auch in Asien und den USA bereitstellen zu k\u00f6nnen.<\/p>\n

Diese Sensibilit\u00e4t gegen\u00fcber Verz\u00f6gerungen bedeutete, dass wir ernsthaft an der Netzwerkarchitektur der Plattform arbeiten mussten. W\u00e4hrend die meisten Cloud-Dienste es erforderten, ein eigenes Netzwerk in jeder Region zu erstellen und diese dann \u00fcber VPN oder einen bestimmten verwalteten Dienst zu verbinden, erm\u00f6glichte Google Cloud die Schaffung eines vollst\u00e4ndig routierbaren einheitlichen Netzwerks, das alle Google-Regionen abdeckte. Dies ist ein gro\u00dfer Vorteil in Bezug auf Betrieb und Effizienz des Systems.<\/p>\n

Dar\u00fcber hinaus leisten die Netzwerkdienste und Lastenausgleichsmechanismen von Google Cloud hervorragende Arbeit. Sie erm\u00f6glichen einfach die Verwendung beliebiger \u00f6ffentlicher IP-Adressen aus jeder Region, und das gro\u00dfartige BGP-Protokoll k\u00fcmmert sich um den Rest (d. h. es leitet Benutzer zum n\u00e4chstgelegenen Cluster weiter). Offensichtlich wird im Falle eines Ausfalls der Verkehr automatisch in eine andere Region geleitet, ohne dass menschliches Eingreifen erforderlich ist.<\/p>\n

\"Tinders
\n\u00dcberwachung des Lastenausgleichs in Google<\/i><\/p>\n

Unsere Plattform nutzt auch aktiv Grafikprozessoren. Google Cloud erm\u00f6glicht es, diese direkt in Kubernetes-Clustern sehr effizient zu nutzen.<\/p>\n

Zur gleichen Zeit konzentrierte sich das Infrastrukturteam \u00fcberwiegend auf den alten Stack, der auf physischen Servern bereitgestellt war. Aus diesem Grund entsprach die Nutzung des verwalteten Dienstes (einschlie\u00dflich der Master-Komponenten von Kubernetes) unseren Anforderungen und erm\u00f6glichte es, Teams in der Arbeit mit lokalen Clustern zu schulen.<\/p>\n

Infolgedessen konnten wir bereits 6 Monate nach Beginn der Arbeiten den Produktivverkehr auf der Google Cloud-Infrastruktur annehmen.<\/p>\n

Trotz einer Reihe von Vorteilen sind die Arbeiten mit einem Cloud-Anbieter mit bestimmten Kosten verbunden, die je nach Last steigen k\u00f6nnen. Daher haben wir jeden genutzten verwalteten Dienst sorgf\u00e4ltig analysiert, um in Zukunft deren Implementierung bei uns vor Ort zu realisieren. Tats\u00e4chlich begann die Einf\u00fchrung lokaler Cluster Ende 2016, und auch die hybride Strategie wurde damals initiiert.<\/p>\n

Start der lokalen Container-Orchestrierungsplattform Dailymotion<\/h2>\n

<\/p>\n

Herbst 2016<\/p><\/blockquote>\n

\nIn einem Umfeld, in dem der gesamte Stack bereit f\u00fcr die Produktion war, w\u00e4hrend die Arbeit am API noch fortgesetzt wurde<\/a><\/noindex>, es war Zeit, sich auf regionale Cluster zu konzentrieren.<\/p>\n

Zu diesem Zeitpunkt sahen die Nutzer monatlich \u00fcber 3 Milliarden Videos. Nat\u00fcrlich 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.<\/p>\n

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.<\/p>\n

\"Tinders
\n<\/p>\n

Netzwerk<\/h3>\n

\nUnser Netzwerk ist vollst\u00e4ndig routierbar. Jeder Server k\u00fcndigt seine IP im Netzwerk mithilfe von Exabgp an. Wir haben mehrere Netzwerk-Plugins verglichen, und das einzige, das alle Anforderungen erf\u00fcllte (aufgrund des verwendeten L3-Ansatzes), war Calico<\/a><\/noindex>. Es f\u00fcgte sich hervorragend in das bestehende Netzwerkmodell der Infrastruktur ein.<\/p>\n

Da wir alle vorhandenen Infrastrukturelemente nutzen wollten, mussten wir zun\u00e4chst mit unserem hausgemachten Netzwerk-Tool (das auf allen Servern verwendet wird) klarkommen: Wir wollten es nutzen, um IP-Adressbereiche im Netzwerk mit Kubernetes-Knoten anzuk\u00fcndigen. Wir lie\u00dfen Calico IP-Adressen an Pods zuweisen, haben es aber nicht f\u00fcr BGP-Sitzungen auf der Netzwerkhardware verwendet und tun das bis heute nicht. Tats\u00e4chlich \u00fcbernimmt Exabgp das Routing, das die von Calico verwendeten Subnetze ank\u00fcndigt. Das erm\u00f6glicht es uns, von unserem internen Netzwerk aus (insbesondere von Load-Balancern) auf jeden Pod zuzugreifen.<\/p>\n

Wie wir den Ingress-Verkehr verwalten<\/h3>\n

\nUm eingehende Anfragen an den richtigen Dienst weiterzuleiten, beschlossen wir, den Ingress-Controller aufgrund seiner Integration mit den Ingress-Ressourcen von Kubernetes zu verwenden.<\/p>\n

Vor drei Jahren war der nginx-ingress-controller der ausgereifteste Controller: Nginx wird schon lange verwendet und ist bekannt f\u00fcr seine Stabilit\u00e4t und Performance.<\/p>\n

In unserem System haben wir beschlossen, die Controller auf dedizierten 10-Gigabit-Blade-Servern zu platzieren. Jeder Controller war mit dem Endpoint des kube-apiserver des entsprechenden Clusters verbunden. Auf diesen Servern wurde ebenfalls Exabgp verwendet, um \u00f6ffentliche oder private IP-Adressen anzuk\u00fcndigen. Die Topologie unseres Netzwerks erm\u00f6glicht es, BGP von diesen Controllern zu verwenden, um den gesamten Verkehr direkt an die Pods zu routen, ohne einen Service wie NodePort zu verwenden. Dieser Ansatz hilft, horizontalen Verkehr zwischen den Knoten zu vermeiden und erh\u00f6ht die Effizienz.<\/p>\n

\"Tinders
\nVerkehrsbewegungen aus dem Internet zu Pods<\/i><\/p>\n

Jetzt, da wir unsere hybride Plattform verstanden haben, k\u00f6nnen wir uns eingehender mit dem Prozess der Verkehrs\u00fcbergabe besch\u00e4ftigen.<\/p>\n

Verkehrs\u00fcbergabe von Google Cloud zur Dailymotion-Infrastruktur<\/h2>\n

<\/p>\n

Herbst 2018<\/p><\/blockquote>\n

\nNach fast zwei Jahren der Erstellung, des Testens und der Konfiguration haben wir endlich einen vollst\u00e4ndigen Kubernetes-Stack, der bereit ist, einen Teil des Verkehrs zu \u00fcbernehmen.<\/p>\n

\"Tinders
\n
\nDie derzeitige Routingstrategie ist recht einfach, erf\u00fcllt aber die Anforderungen. Neben den \u00f6ffentlichen IPs (in Google Cloud und Dailymotion) wird AWS Route 53 verwendet, um Richtlinien zu erstellen und Benutzer zu dem Cluster weiterzuleiten, das wir w\u00e4hlen.<\/p>\n

\"Tinders
\nBeispiel f\u00fcr eine Routingrichtlinie mit Route 53<\/i><\/p>\n

Mit Google Cloud ist es einfach, da wir eine einheitliche IP f\u00fcr alle Cluster verwenden, und der Benutzer zu dem n\u00e4chstgelegenen GKE-Cluster weitergeleitet wird. F\u00fcr unsere Cluster ist die Technologie anders, da sich ihre IPs unterscheiden.<\/p>\n

W\u00e4hrend der Migration strebten wir an, regionale Anfragen an die entsprechenden Cluster weiterzuleiten und bewerteten die Vorteile dieses Ansatzes.<\/p>\n

Da unsere GKE-Cluster auf automatisches Skalieren mit benutzerdefinierten Metriken konfiguriert sind, erh\u00f6hen oder verringern sie die Kapazit\u00e4ten je nach eingehendem Verkehr.<\/p>\n

Im Normalbetrieb wird der gesamte regionale Verkehr an das lokale Cluster geleitet, w\u00e4hrend GKE als Backup dient, falls Probleme auftreten (Health-Checks werden von Route 53 durchgef\u00fchrt).<\/p>\n

\u2026<\/h2>\n

\nIn Zukunft m\u00f6chten wir die Routing-Politik vollst\u00e4ndig automatisieren, um eine autonome Hybridstrategie zu entwickeln, die die Verf\u00fcgbarkeit f\u00fcr die Nutzer st\u00e4ndig verbessert. Was die Vorteile betrifft: Die Ausgaben f\u00fcr die Cloud wurden erheblich gesenkt, und es gelang sogar, die API-Reaktionszeiten zu verk\u00fcrzen. Wir vertrauen der entstandenen Cloud-Plattform und sind bereit, bei Bedarf mehr Traffic darauf umzuleiten.<\/p>\n

P.S. vom \u00dcbersetzer<\/h2>\n

\nM\u00f6glicherweise interessiert Sie auch eine andere aktuelle Ver\u00f6ffentlichung von Dailymotion zu Kubernetes. Sie behandelt das Deployment von Anwendungen mit Helm auf mehreren Kubernetes-Clustern und wurde ver\u00f6ffentlicht<\/a><\/noindex> vor etwa einem Monat.<\/p>\n

Lesen Sie auch in unserem Blog:<\/p>\n