Opmerking vertaler.: Dailymotion — 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.
Bij de beslissing om de hoofd-API opnieuw in te richten drie jaar geleden wilden we een effectievere manier ontwikkelen om applicaties te hosten en . Voor dit doel besloten we een containerorkestratieplatform te gebruiken en kozen natuurlijk voor Kubernetes.
Waarom zou je een eigen platform op basis van Kubernetes creëren?
Productie-API's in recordtijd met behulp van Google Cloud
Zomer 2016
Drie jaar geleden, kort na de overname van Dailymotion door , concentreerden onze ingenieursteams zich op één wereldwijd doel: het creëren van een geheel nieuw Dailymotion-product.
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.
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.
Waarom GKE gekozen?
We 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.
GKE-clusters bij Dailymotion
Aangezien Dailymotion een videoplatform is dat wereldwijd toegankelijk is, wilden we de servicekwaliteit verbeteren door de wachttijd (latency)te verkorten. Eerder was alleen beschikbaar in Parijs, wat niet optimaal was. We wilden de mogelijkheid hebben om applicaties niet alleen in Europa, maar ook in Azië en de VS te hosten.
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ëren en deze vervolgens via VPN of een beheerde service moesten koppelen, stelde Google Cloud ons in staat een volledig routerbare enkele netwerk te creëren die alle Google-regio's besloeg. Dit is een groot voordeel op het gebied van exploitatie en systeemefficiëntie.
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.
Monitoring van load balancing in Google
Ons platform maakt ook actief gebruik van grafische processors. Google Cloud stelt ons in staat om deze zeer efficiënt te gebruiken, direct in Kubernetes-clusters.
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.
Als resultaat konden we na slechts 6 maanden beginnen met het ontvangen van productieverkeer op de infrastructuur van Google Cloud.
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ïnitieerd.
Lancering van het lokale platform voor containerorkestratie Dailymotion
Herfst 2016
In een situatie waarin de hele stack klaar was voor productie, en het werk aan de API , het was tijd om ons te concentreren op regionale clusters.
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.
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ëren van master- en worker-nodes, evenals een etcd-cluster.
Netwerkdeel
Ons 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 . Het paste perfect in het bestaande netwerkmodel van de infrastructuur.
Omdat we alle beschikbare elementen van de infrastructuur wilden gebruiken, moesten we eerst uitzoeken hoe onze zelfgemaakte netwerktool (gebruikt op alle servers) kon worden ingezet om IP-adresranges in het netwerk met Kubernetes-nodes aan te kondigen. We lieten Calico IP-adressen toewijzen aan pods, maar gebruikten het niet, en gebruiken het nog steeds niet voor BGP-sessies op netwerkapparatuur. Feitelijk wordt de routering gedaan door Exabgp, dat de subnetten aankondigt die door Calico worden gebruikt. Dit stelt ons in staat om elk pod vanuit het interne netwerk te bereiken (en met name vanaf de load balancers).
Hoe we ingress-verkeer beheren
Om binnenkomende verzoeken naar de juiste service te omleiden, werd besloten om de Ingress Controller te gebruiken vanwege de integratie met ingress-resources van Kubernetes.
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.
In ons systeem hebben we besloten controllers te plaatsen op speciale 10-gigabit blade-servers. Elke controller werd aangesloten op de kube-apiserver endpoint van het betreffende cluster. Op deze servers werd ook Exabgp gebruikt voor het aankondigen van publieke of private IP-adressen. De topologie van ons netwerk maakt het mogelijk om BGP vanuit deze controllers te gebruiken voor het routeren van al het verkeer rechtstreeks naar de pods zonder gebruik te maken van een dienst zoals NodePort. Deze aanpak helpt horizontaal verkeer tussen knooppunten te vermijden en verhoogt de efficiëntie.
Het verkeer van het internet naar de pods
Nu we onze hybride platform hebben begrepen, kunnen we dieper ingaan op het migreren van verkeer.
Migratie van verkeer van Google Cloud naar de Dailymotion-infrastructuur
Herfst 2018
Na bijna twee jaar van creëren, testen en instellen hebben we eindelijk een volledige Kubernetes-stack die klaar is om een deel van het verkeer te ontvangen.
De 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.
Voorbeeld van beleid voor routering met Route 53
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.
Tijdens de migratie streefden we ernaar regionale verzoeken naar de bijbehorende clusters door te sturen en we evalueerden de voordelen van deze aanpak.
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.
In normale omstandigheden wordt al het regionale verkeer naar het lokale cluster geleid, terwijl GKE als reserve dient in geval van problemen (health-checks worden uitgevoerd door Route 53).
…
In 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.S. van de vertaler
Misschien bent u ook geïnteresseerd in een andere recente publicatie van Dailymotion over Kubernetes. Deze is gewijd aan het implementeren van applicaties met Helm op meerdere Kubernetes-clusters en ongeveer een maand geleden.
Lees ook op onze blog:
- «».
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «».
Bron: habr.com
