{"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\/nl\/blog\/administrirovanie\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","title":{"rendered":"Kubernetes-avontuur van Dailymotion: infrastructuur cre\u00ebren in de cloud + on-premises","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kubernetes-avontuur
\n
\nOpmerking vertaler.<\/b>: Dailymotion \u2014 een van de grootste video-hostingdiensten ter wereld en daardoor een opmerkelijke gebruiker van Kubernetes. In dit artikel deelt systeemarchitect David Donchez de resultaten van de creatie van het productieplatform van het bedrijf op basis van K8s, dat begon met een cloudinstallatie in GKE en eindigde als een hybride oplossing, wat leidde tot betere reactietijden en besparingen op infrastructuurkosten.<\/i><\/p>\n

Bij de beslissing om de hoofd-API opnieuw in te richten Dailymotion<\/a><\/noindex> drie jaar geleden wilden we een effectievere manier ontwikkelen om applicaties te hosten en de processen in de ontwikkeling en productie<\/a><\/noindex>. Voor dit doel besloten we een containerorkestratieplatform te gebruiken en kozen natuurlijk voor Kubernetes.<\/p>\n

Waarom zou je een eigen platform op basis van Kubernetes cre\u00ebren?<\/a><\/noindex><\/p>\n

Productie-API's in recordtijd met behulp van Google Cloud<\/h2>\n

<\/p>\n

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

\nDrie jaar geleden, kort na de overname van Dailymotion door Vivendi<\/a><\/noindex>, concentreerden onze ingenieursteams zich op \u00e9\u00e9n wereldwijd doel: het cre\u00ebren van een geheel nieuw Dailymotion-product.<\/p>\n

Uit onze analyse van containers, oplossingen voor orkestratie en onze eerdere ervaringen concludeerden we dat Kubernetes de juiste keuze was. Een deel van de ontwikkelaars had al kennis van de basisconcepten en wist hoe het te gebruiken, wat een enorm voordeel was voor de infrastructurele transformatie.<\/p>\n

Vanuit het perspectief van infrastructuur was er behoefte aan een krachtig en flexibel systeem voor het hosten van nieuwe typen cloud-native applicaties. We verkozen het in het begin van onze reis in de cloud te blijven, zodat we rustig een uiterst betrouwbare lokale platform konden opbouwen. We besloten onze applicaties uit te rollen met Google Kubernetes Engine, hoewel we wisten dat we vroeg of laat naar onze eigen datacenters zouden overstappen en een hybride strategie zouden toepassen.<\/p>\n

Waarom GKE gekozen?<\/h3>\n

\nWe hebben deze keuze voornamelijk gemaakt om technische redenen. Bovendien was het noodzakelijk om snel infrastructuur te bieden die aan de bedrijfsbehoeften voldeed. We hadden bepaalde vereisten voor het hosten van applicaties, zoals geografische spreiding, schaalbaarheid en fouttolerantie.<\/p>\n

\"Kubernetes-avontuur
\nGKE-clusters bij Dailymotion<\/i><\/p>\n

Aangezien Dailymotion een videoplatform is dat wereldwijd toegankelijk is, wilden we de servicekwaliteit verbeteren door de wachttijd (latency)<\/i>te verkorten. Eerder was onze API<\/a><\/noindex> was alleen beschikbaar in Parijs, wat niet optimaal was. We wilden de mogelijkheid hebben om applicaties niet alleen in Europa, maar ook in Azi\u00eb en de VS te hosten.<\/p>\n

Deze gevoeligheid voor latentie betekende dat we serieus moesten werken aan de netwerkinfrastructuur van het platform. Terwijl de meeste cloudservices vereisten dat we een netwerk in elke regio moesten cre\u00ebren en deze vervolgens via VPN of een beheerde service moesten koppelen, stelde Google Cloud ons in staat een volledig routerbare enkele netwerk te cre\u00ebren die alle Google-regio's besloeg. Dit is een groot voordeel op het gebied van exploitatie en systeemeffici\u00ebntie.<\/p>\n

Bovendien presteren de netservices en load balancers van Google Cloud uitstekend. Ze stellen ons eenvoudig in staat om willekeurige openbare IP-adressen uit elke regio te gebruiken, en het geweldige BGP-protocol zorgt voor de rest (dwz het leidt gebruikers naar de dichtstbijzijnde cluster). Het is duidelijk dat bij een storing het verkeer automatisch naar een andere regio zal gaan zonder enige menselijke tussenkomst.<\/p>\n

\"Kubernetes-avontuur
\nMonitoring van load balancing in Google<\/i><\/p>\n

Ons platform maakt ook actief gebruik van grafische processors. Google Cloud stelt ons in staat om deze zeer effici\u00ebnt te gebruiken, direct in Kubernetes-clusters.<\/p>\n

Op dat moment concentreerde het infrastructuurteam zich voornamelijk op de oude stack die op fysieke servers was uitgerold. Daarom voldeed het gebruik van een beheerde service (inclusief de mastercomponenten van Kubernetes) aan onze behoeften en stelde het ons in staat om teams op te leiden in het werken met lokale clusters.<\/p>\n

Als resultaat konden we na slechts 6 maanden beginnen met het ontvangen van productieverkeer op de infrastructuur van Google Cloud.<\/p>\n

Echter, ondanks een aantal voordelen, gaat het werken met een cloudprovider gepaard met bepaalde kosten, die kunnen toenemen afhankelijk van de belasting. Daarom hebben we elk gebruikte beheerde service zorgvuldig geanalyseerd, met het plan om deze in de toekomst on-premises te implementeren. In werkelijkheid begon de introductie van lokale clusters eind 2016, en toen werd ook de hybride strategie ge\u00efnitieerd.<\/p>\n

Lancering van het lokale platform voor containerorkestratie Dailymotion<\/h2>\n

<\/p>\n

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

\nIn een situatie waarin de hele stack klaar was voor productie, en het werk aan de API zich uitstrekte<\/a><\/noindex>, het was tijd om ons te concentreren op regionale clusters.<\/p>\n

Op dat moment keken gebruikers maandelijks naar meer dan 3 miljard video's. Natuurlijk had onze uitgebreide Content Delivery Network al jaren gefunctioneerd. We wilden van deze gelegenheid gebruikmaken en Kubernetes-clusters opzetten in de bestaande datacenters.<\/p>\n

De infrastructuur van Dailymotion bestond uit meer dan 2.500 servers in zes datacenters. Al deze servers worden geconfigureerd met Saltstack. We begonnen met het voorbereiden van alle benodigde recepten voor het cre\u00ebren van master- en worker-nodes, evenals een etcd-cluster.<\/p>\n

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

Netwerkdeel<\/h3>\n

\nOns netwerk is volledig routerbaar. Elke server kondigt zijn IP aan in het netwerk met behulp van Exabgp. We hebben verschillende netwerkplugins vergeleken en de enige die aan al onze behoeften voldeed (vanwege de L3-benadering) was , dat de standaard API-set van Kubernetes aanzienlijk uitbreidt op het gebied van netwerkinstellingen.<\/a><\/noindex>. Het paste perfect in het bestaande netwerkmodel van de infrastructuur.<\/p>\n

Omdat we alle beschikbare infrastructuurelementen wilden gebruiken, moesten we eerst onze zelfontwikkelde netwerkgereedschap begrijpen (gebruik op alle servers): het gebruik ervan voor het aankondigen van IP-adresbereiken binnen een netwerk met Kubernetes-knooppunten. We hebben Calico toegestaan om IP-adressen aan pods toe te wijzen, maar we hebben het nog steeds niet gebruikt voor BGP-sessies op netwerkinfrastructuur. In feite wordt de routering verzorgd door Exabgp, die de subnetten aankondigt die door Calico worden gebruikt. Dit stelt ons in staat om toegang te krijgen tot elke pod vanuit het interne netwerk (en specifiek vanaf de load balancers).<\/p>\n

Hoe we ingress-verkeer beheren<\/h3>\n

\nOm binnenkomende verzoeken naar de juiste service te omleiden, werd besloten om de Ingress Controller te gebruiken vanwege de integratie met ingress-resources van Kubernetes.<\/p>\n

Drie jaar geleden was de nginx-ingress-controller de meest volwassen controller: Nginx werd al lange tijd gebruikt en stond bekend om zijn stabiliteit en prestaties.<\/p>\n

In ons systeem hebben we besloten om controllers te plaatsen op speciale 10-gigabit blade-servers. Elke controller was aangesloten op de endpoint van de kube-apiserver van het desbetreffende cluster. Op deze servers werd ook Exabgp gebruikt voor het aankondigen van publieke of private IP-adressen. De topologie van ons netwerk stelt ons in staat om BGP vanuit deze controllers te gebruiken voor de routering van al het verkeer rechtstreeks naar de pods zonder gebruik te maken van een service zoals NodePort. Deze aanpak helpt horizontaal verkeer tussen knooppunten te vermijden en verhoogt de effici\u00ebntie.<\/p>\n

\"Kubernetes-avontuur
\nVerkeer van het internet naar pods<\/i><\/p>\n

Nu we onze hybride platform hebben begrepen, kunnen we dieper ingaan op het migreren van verkeer.<\/p>\n

Migratie van verkeer van Google Cloud naar de Dailymotion-infrastructuur<\/h2>\n

<\/p>\n

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

\nNa bijna twee jaar van cre\u00ebren, testen en instellen hebben we eindelijk een volledige Kubernetes-stack die klaar is om een deel van het verkeer te ontvangen.<\/p>\n

\"Kubernetes-avontuur
\n
\nDe huidige routeringsstrategie is vrij eenvoudig, maar voldoet volledig aan de behoeften. Naast publieke IP's (in Google Cloud en Dailymotion) wordt AWS Route 53 gebruikt om beleid op te stellen en gebruikers door te sturen naar het cluster van onze keuze.<\/p>\n

\"Kubernetes-avontuur
\nVoorbeeld van beleid voor routering met Route 53<\/i><\/p>\n

Met Google Cloud is dit eenvoudig, aangezien we een enkele IP gebruiken voor alle clusters, en de gebruiker wordt doorgestuurd naar het dichtstbijzijnde GKE-cluster. Voor onze clusters is de technologie anders, omdat hun IP's verschillen.<\/p>\n

Tijdens de migratie streefden we ernaar regionale verzoeken naar de bijbehorende clusters door te sturen en we evalueerden de voordelen van deze aanpak.<\/p>\n

Aangezien onze GKE-clusters zijn geconfigureerd voor automatische schaling met behulp van Custom Metrics, schalen ze op of af op basis van het inkomende verkeer.<\/p>\n

In normale modus wordt al het regionale verkeer naar het lokale cluster gestuurd, terwijl GKE als reserve dient in geval van problemen (health-checks worden uitgevoerd via Route 53).<\/p>\n

\u2026<\/h2>\n

\nIn de toekomst willen we de routeringspolitieken volledig automatiseren om een autonome hybride strategie te verkrijgen die de beschikbaarheid voor gebruikers voortdurend verbetert. Wat betreft de voordelen: de cloudkosten zijn aanzienlijk gedaald en we hebben zelfs de reactietijd van de API weten te verkorten. We vertrouwen op het resulterende cloudplatform en zijn bereid om indien nodig meer verkeer naar dit platform te leiden.<\/p>\n

P.S. van de vertaler<\/h2>\n

\nMisschien bent u ook ge\u00efnteresseerd in een andere recente publicatie van Dailymotion over Kubernetes. Deze is gewijd aan het implementeren van applicaties met Helm op meerdere Kubernetes-clusters en is gepubliceerd<\/a><\/noindex> ongeveer een maand geleden.<\/p>\n

Lees ook op onze blog:<\/p>\n