{"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":"Kubernetes-Abenteuer von Dailymotion: Erstellung von Infrastruktur in der Cloud + vor Ort","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kubernetes-Abenteuer
\n
\nHinweis.<\/b>: Dailymotion \u2014 einer der gr\u00f6\u00dften 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\u00f6sung endete, was eine bessere Reaktionszeit und Einsparungen bei den Infrastrukturkosten erm\u00f6glichte.<\/i><\/p>\n

Bei der Entscheidung zur Neugestaltung der Haupt-API Dailymotion<\/a><\/noindex> vor drei Jahren wollten wir eine effizientere Methode zur Bereitstellung von Anwendungen entwickeln und die Entwicklungs- und Produktionsprozesse<\/a><\/noindex>. Zu diesem Zweck entschieden wir uns f\u00fcr eine Container-Orchestrierungsplattform und w\u00e4hlten selbstverst\u00e4ndlich Kubernetes aus.<\/p>\n

Warum ist es sinnvoll, eine eigene Plattform auf Kubernetes-Basis zu schaffen?<\/a><\/noindex><\/p>\n

API in Produktionsqualit\u00e4t in k\u00fcrzester Zeit mit Google Cloud<\/h2>\n

<\/p>\n

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

\nVor drei Jahren, unmittelbar nach dem Kauf von Dailymotion durch Vivendi<\/a><\/noindex>, konzentrierten sich unsere Ingenieurteams auf ein gemeinsames Ziel: einen v\u00f6llig neuen Dailymotion-Produkten zu schaffen.<\/p>\n

Nach der Analyse von Containern, Orchestrierungsl\u00f6sungen und unserer bisherigen Erfahrung sind wir \u00fcberzeugt, 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\u00fcr die infrastrukturelle Transformation war.<\/p>\n

Infrastrukturell ben\u00f6tigten wir ein robustes und flexibles System f\u00fcr die Bereitstellung neuer Arten von Cloud-Anwendungen. Wir entschieden uns, zu Beginn unseres Weges in der Cloud zu bleiben, um eine m\u00f6glichst zuverl\u00e4ssige lokale Plattform ruhig aufzubauen. Unsere Anwendungen wurden mit Google Kubernetes Engine bereitgestellt, obwohl uns bewusst war, dass wir fr\u00fcher oder sp\u00e4ter auf unsere eigenen Rechenzentren umsteigen und eine hybride Strategie anwenden w\u00fcrden.<\/p>\n

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

\nUnsere Entscheidung basierte haupts\u00e4chlich auf technischen \u00dcberlegungen. Zudem war es erforderlich, die Infrastruktur schnell zu implementieren, um den gesch\u00e4ftlichen Anforderungen gerecht zu werden. Wir hatten einige Vorgaben f\u00fcr die Bereitstellung von Anwendungen, wie geografische Verteilung, Skalierbarkeit und Ausfallsicherheit.<\/p>\n

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

Da Dailymotion eine weltweit verf\u00fcgbare Videoplattform ist, war es unser Bestreben, die Servicequalit\u00e4t durch die Reduzierung der Wartezeiten zu verbessern. (Latenz)<\/i>. Zuvor war unsere API<\/a><\/noindex> nur in Paris verf\u00fcgbar, was suboptimal war. Wir wollten die M\u00f6glichkeit haben, Anwendungen nicht nur in Europa, sondern auch in Asien und den USA bereitzustellen.<\/p>\n

Diese Sensibilit\u00e4t f\u00fcr Latenzen bedeutete, dass wir intensiv an der Netzwerkarchitektur der Plattform arbeiten mussten. W\u00e4hrend die meisten Cloud-Dienste erforderten, dass man ein Netzwerk in jeder Region aufbaute und diese dann \u00fcber VPN oder einen verwalteten Dienst verband, erm\u00f6glichte Google Cloud die Schaffung eines vollst\u00e4ndig routbaren einheitlichen Netzwerks, das alle Google-Regionen abdeckt. Dies ist ein gro\u00dfer Vorteil in Bezug auf Betrieb und Systemeffizienz.<\/p>\n

Dar\u00fcber hinaus arbeiten die Netzwerktechnologien und Lastenausgleicher von Google Cloud hervorragend. Sie erm\u00f6glichen die Nutzung beliebiger \u00f6ffentlicher IP-Adressen aus jedem Gebiet, w\u00e4hrend das gro\u00dfartige BGP-Protokoll sich um den Rest k\u00fcmmert (d.h. es leitet die Benutzer zum n\u00e4chstgelegenen Cluster). Offensichtlich wird im Falle eines Ausfalls der Verkehr automatisch in eine andere Region umgeleitet, ohne menschliches Eingreifen.<\/p>\n

\"Kubernetes-Abenteuer
\n\u00dcberwachung der Lastenausgleichung in Google<\/i><\/p>\n

Unsere Plattform nutzt auch aktiv Grafikprozessoren. Google Cloud erm\u00f6glicht eine \u00e4u\u00dferst effiziente Nutzung dieser direkt in Kubernetes-Clustern.<\/p>\n

Gleichzeitig konzentrierte sich das Infrastrukturteam haupts\u00e4chlich auf den alten Stack, der auf physischen Servern bereitgestellt wurde. Daher erf\u00fcllte die Nutzung des verwalteten Dienstes (einschlie\u00dflich der Masterkomponenten von Kubernetes) unsere Anforderungen und erleichterte das Training der Teams im Umgang mit lokalen Clustern.<\/p>\n

Infolgedessen konnten wir bereits 6 Monate nach Projektbeginn Produktionsverkehr auf der Infrastruktur von Google Cloud entgegennehmen.<\/p>\n

Obwohl die Zusammenarbeit mit einem Cloud-Anbieter einige Vorteile bietet, sind damit auch bestimmte Kosten verbunden, die je nach Last steigen k\u00f6nnen. Aus diesem Grund haben wir jeden verwalteten Service sorgf\u00e4ltig analysiert, um diese in Zukunft in unserer eigenen Infrastruktur umzusetzen. Tats\u00e4chlich begann die Einf\u00fchrung lokaler Cluster Ende 2016, und zu diesem Zeitpunkt wurde auch eine hybride Strategie initiiert.<\/p>\n

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

<\/p>\n

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

\nIn dem Moment, als der gesamte Stack produktionsbereit war und die Arbeiten an der API fortgesetzt wurden<\/a><\/noindex>, war es an der Zeit, sich auf die regionalen Cluster zu konzentrieren.<\/p>\n

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

Die Infrastruktur von Dailymotion umfasst \u00fcber 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.<\/p>\n

\"Kubernetes-Abenteuer
\n<\/p>\n

Netzwerkbereich<\/h3>\n

\nUnser Netzwerk ist vollst\u00e4ndig routierbar. Jeder Server gibt seine IP-Adresse im Netzwerk \u00fcber Exabgp bekannt. Wir haben mehrere Netzwerk-Plugins verglichen und das einzige, das allen Anforderungen gerecht wurde (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 verf\u00fcgbaren Infrastrukturelemente nutzen wollten, mussten wir uns zun\u00e4chst mit unserem hausinternen Netzwerk-Tool vertraut machen, das auf allen Servern eingesetzt wird: Es sollte verwendet werden, um IP-Adressbereiche im Netzwerk der Kubernetes-Knoten anzuk\u00fcndigen. Wir haben Calico erlaubt, IP-Adressen den Pods zuzuweisen, aber nicht f\u00fcr BGP-Sitzungen auf dem Netzwerkger\u00e4t verwendet \u2013 und tun dies bis heute nicht. Tats\u00e4chlich \u00fcbernimmt Exabgp die Routing-Verantwortung und k\u00fcndigt die Subnetze an, die von Calico verwendet werden. Dies erm\u00f6glicht es uns, von unserem internen Netzwerk (insbesondere von den Lastenausgleichern) auf jeden Pod zuzugreifen.<\/p>\n

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

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

Vor drei Jahren war der nginx-ingress-controller der am weitesten entwickelte Controller: Nginx wurde schon lange verwendet und war f\u00fcr seine Stabilit\u00e4t und Leistung bekannt.<\/p>\n

In unserem System haben wir uns entschieden, 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 auch Exabgp verwendet, um \u00f6ffentliche oder private IP-Adressen anzuk\u00fcndigen. Die Topologie unseres Netzwerks erm\u00f6glicht es, BGP von diesen Controllern zu nutzen, um den gesamten Datenverkehr direkt an die Pods zu leiten, ohne Dienste wie NodePort zu verwenden. Dieser Ansatz hilft, horizontalen Datenverkehr zwischen den Knoten zu vermeiden und erh\u00f6ht die Effizienz.<\/p>\n

\"Kubernetes-Abenteuer
\nDatenverkehr aus dem Internet zu den Pods<\/i><\/p>\n

Jetzt, da wir unser hybrides System verstanden haben, k\u00f6nnen wir tiefer in den Prozess der Trafficmigration eintauchen.<\/p>\n

Migration des Traffics aus Google Cloud in die Infrastruktur von Dailymotion<\/h2>\n

<\/p>\n

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

\nNach fast zwei Jahren der Erstellung, Tests und Anpassung haben wir endlich ein vollst\u00e4ndiges Kubernetes-Stack, das bereit ist, einen Teil des Traffics zu \u00fcbernehmen.<\/p>\n

\"Kubernetes-Abenteuer
\n
\nDie aktuelle Routing-Strategie ist ziemlich einfach, erf\u00fcllt aber die Bed\u00fcrfnisse vollst\u00e4ndig. Neben den \u00f6ffentlichen IPs (in Google Cloud und Dailymotion) wird AWS Route 53 verwendet, um Richtlinien festzulegen und die Benutzer zu dem Cluster umzuleiten, den wir gew\u00e4hlt haben.<\/p>\n

\"Kubernetes-Abenteuer
\nBeispiel f\u00fcr eine Routing-Policy mit Route 53<\/i><\/p>\n

Mit Google Cloud ist das einfach, da wir eine einheitliche IP f\u00fcr alle Cluster verwenden und die Nutzer an den n\u00e4chstgelegenen GKE-Cluster weitergeleitet werden. F\u00fcr unsere Cluster hingegen ist die Technologie anders, da ihre IP-Adressen unterschiedlich sind.<\/p>\n

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

Unsere GKE-Cluster sind so konfiguriert, dass sie mithilfe von benutzerdefinierten Metriken automatisch skalieren, wodurch sie je nach eingehendem Traffic Ressourcen hinzuf\u00fcgen oder reduzieren.<\/p>\n

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

\u2026<\/h2>\n

\nIn Zukunft m\u00f6chten wir die Routing-Politiken vollst\u00e4ndig automatisieren, um eine autonome Hybridstrategie zu entwickeln, die die Verf\u00fcgbarkeit f\u00fcr die Nutzer kontinuierlich verbessert. Der Vorteil: Die Ausgaben f\u00fcr die Cloud wurden erheblich gesenkt, und auch die API-Reaktionszeiten konnten verk\u00fcrzt werden. Wir vertrauen auf die entstandene Cloud-Plattform und sind bereit, bei Bedarf mehr Traffic darauf umzuleiten.<\/p>\n

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

\nSie k\u00f6nnten sich auch f\u00fcr einen anderen aktuellen Dailymotion-Beitrag \u00fcber Kubernetes interessieren. Dieser 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