Opmerking. vert.: Dailymotion is een van 's werelds grootste videohostingservices en daarom een opmerkelijke Kubernetes-gebruiker. In dit materiaal deelt systeemarchitect David Donchez de resultaten van het creëren van het productieplatform van het bedrijf op basis van K8s, dat begon met een cloudinstallatie in GKE en eindigde als een hybride oplossing, wat betere responstijden en besparingen op infrastructuurkosten mogelijk maakte.
Beslissen om de Core API opnieuw te bouwen drie jaar geleden wilden we een efficiëntere manier ontwikkelen om applicaties te hosten en het gemakkelijker te maken . Hiervoor hebben we besloten een containerorkestratieplatform in te zetten en uiteraard voor Kubernetes gekozen.
Waarom is het de moeite waard om je eigen platform te bouwen op basis van Kubernetes?
API op productieniveau in een mum van tijd met Google Cloud
Zomer 2016
Drie jaar geleden, direct nadat Dailymotion werd gekocht door zijn onze technische teams gefocust op één mondiaal doel: het creëren van een volledig nieuw Dailymotion-product.
Op basis van onze analyse van containers, orkestratieoplossingen en onze ervaringen uit het verleden zijn we ervan overtuigd dat Kubernetes de juiste keuze is. Sommige ontwikkelaars hadden al inzicht in de basisconcepten en wisten hoe ze deze moesten gebruiken, wat een enorm voordeel was voor de infrastructuurtransformatie.
Vanuit infrastructuurperspectief was een krachtig en flexibel systeem nodig om nieuwe soorten cloud-native applicaties te hosten. We kozen ervoor om aan het begin van onze reis in de cloud te blijven, zodat we met een gerust hart het meest robuuste on-premise platform konden bouwen. We besloten onze applicaties uit te rollen met behulp van Google Kubernetes Engine, hoewel we wisten dat we vroeg of laat naar onze eigen datacenters zouden verhuizen en een hybride strategie zouden toepassen.
Waarom heb je voor GKE gekozen?
Deze keuze hebben wij vooral gemaakt om technische redenen. Bovendien was het noodzakelijk om snel infrastructuur te bieden die voldoet aan de zakelijke behoeften van het bedrijf. We hadden enkele vereisten voor het hosten van applicaties, zoals geografische spreiding, schaalbaarheid en fouttolerantie.
GKE-clusters in Dailymotion
Omdat Dailymotion een videoplatform is dat wereldwijd beschikbaar is, wilden we de kwaliteit van de dienstverlening echt verbeteren door de wachttijd te verkorten (latentie). Eerder was alleen beschikbaar in Parijs, wat niet optimaal was. Ik wilde niet alleen applicaties in Europa kunnen hosten, maar ook in Azië en de VS.
Deze gevoeligheid voor latentie betekende dat er serieus moest worden gewerkt aan de netwerkarchitectuur van het platform. Terwijl de meeste cloudservices je dwongen om in elke regio je eigen netwerk te creëren en deze vervolgens te verbinden via een VPN of een soort beheerde service, stelde Google Cloud je in staat een volledig routeerbaar enkel netwerk te creëren dat alle Google-regio's bestrijkt. Dit is een groot pluspunt in termen van werking en efficiëntie van het systeem.
Daarnaast doen netwerkdiensten en load balancers van Google Cloud uitstekend werk. Ze stellen u eenvoudigweg in staat willekeurige openbare IP-adressen uit elke regio te gebruiken, en het prachtige BGP-protocol zorgt voor de rest (dat wil zeggen: gebruikers omleiden naar het dichtstbijzijnde cluster). Uiteraard gaat het verkeer bij een storing automatisch naar een andere regio, zonder menselijke tussenkomst.
Controle van Google Load Balancing
Ons platform maakt ook intensief gebruik van GPU's. Met Google Cloud kunt u ze zeer effectief rechtstreeks in Kubernetes-clusters gebruiken.
Destijds was het infrastructuurteam vooral gericht op de legacy-stack die op fysieke servers werd ingezet. Daarom voldeed het gebruik van een beheerde service (inclusief Kubernetes-masters) aan onze eisen en konden we teams trainen om met lokale clusters te werken.
Als gevolg hiervan konden we al zes maanden na de start van de werkzaamheden productieverkeer op de Google Cloud-infrastructuur ontvangen.
Ondanks een aantal voordelen gaat het werken met een cloudprovider echter gepaard met bepaalde kosten, die afhankelijk van de belasting kunnen oplopen. Daarom hebben we elke beheerde service die we gebruikten zorgvuldig geanalyseerd, in de hoop deze in de toekomst op locatie te kunnen implementeren. Sterker nog, de implementatie van lokale clusters begon eind 2016 en tegelijkertijd werd de hybride strategie geïnitieerd.
Lancering van lokaal containerorkestratieplatform Dailymotion
Herfst 2016
In omstandigheden waarin de hele stapel klaar was voor productie en werken aan de API was het tijd om ons te concentreren op regionale clusters.
Op dat moment keken gebruikers elke maand naar meer dan 3 miljard video's. Uiteraard beschikken wij al jaren over ons eigen uitgebreide Content Delivery Network. We wilden van deze omstandigheid profiteren en Kubernetes-clusters in bestaande datacenters implementeren.
De infrastructuur van Dailymotion bestond uit ruim 2,5 duizend servers in zes datacenters. Ze zijn allemaal geconfigureerd met Saltstack. We zijn begonnen met het voorbereiden van alle benodigde recepten voor het maken van master- en worker-knooppunten, evenals een etcd-cluster.
Netwerkdeel
Ons netwerk is volledig gerouteerd. Elke server adverteert zijn IP op het netwerk met behulp van Exabgp. We hebben verschillende netwerkplug-ins vergeleken en de enige die aan alle behoeften voldeed (vanwege de gebruikte L3-aanpak) was dat . Het past perfect in het bestaande netwerkinfrastructuurmodel.
Omdat we alle beschikbare infrastructuurelementen wilden gebruiken, moesten we eerst ons eigen netwerkhulpprogramma bedenken (dat op alle servers wordt gebruikt): het gebruiken om IP-adresbereiken op het netwerk met Kubernetes-nodes te adverteren. We hebben Calico toegestaan IP-adressen aan pods toe te wijzen, maar hebben dit niet gedaan en gebruiken dit nog steeds niet voor BGP-sessies op netwerkapparatuur. In feite wordt de routering afgehandeld door Exabgp, dat reclame maakt voor de subnetten die door Calico worden gebruikt. Hierdoor kunnen we elke pod bereiken vanaf het interne netwerk (en in het bijzonder vanaf load balancers).
Hoe we inkomend verkeer beheren
Om binnenkomende verzoeken om te leiden naar de gewenste service, werd besloten om Ingress Controller te gebruiken vanwege de integratie met Kubernetes-ingress-bronnen.
Drie jaar geleden was nginx-ingress-controller de meest volwassen controller: Nginx bestond al heel lang en stond bekend om zijn stabiliteit en prestaties.
In ons systeem hebben we besloten de controllers op speciale 10 Gigabit-bladeservers te plaatsen. Elke controller was verbonden met het kube-apiserver-eindpunt van het overeenkomstige cluster. Deze servers gebruikten Exabgp ook om openbare of privé-IP-adressen te adverteren. Dankzij onze netwerktopologie kunnen we BGP van deze controllers gebruiken om al het verkeer rechtstreeks naar de pods te routeren zonder gebruik te maken van een service als NodePort. Deze aanpak helpt horizontaal verkeer tussen knooppunten te voorkomen en verbetert de efficiëntie.
Verkeersbeweging van internet naar pods
Nu we ons hybride platform begrijpen, kunnen we dieper ingaan op het verkeersmigratieproces zelf.
Migratie van verkeer van Google Cloud naar Dailymotion-infrastructuur
Herfst 2018
Na bijna twee jaar bouwen, testen en afstemmen hebben we eindelijk een volledige Kubernetes-stack klaar om wat verkeer te accepteren.
De huidige routeringsstrategie is vrij eenvoudig, maar voldoende om aan de behoeften te voldoen. Naast openbare IP's (op Google Cloud en Dailymotion) wordt AWS Route 53 gebruikt om beleid in te stellen en gebruikers om te leiden naar het cluster van onze keuze.
Voorbeeld van routeringsbeleid met Route 53
Met Google Cloud is dit eenvoudig omdat we één IP-adres delen met alle clusters en de gebruiker wordt doorgestuurd naar het dichtstbijzijnde GKE-cluster. Voor onze clusters is de technologie anders, omdat hun IP's verschillend zijn.
Tijdens de migratie probeerden we regionale verzoeken om te leiden naar de juiste clusters en evalueerden we de voordelen van deze aanpak.
Omdat onze GKE-clusters zijn geconfigureerd om automatisch te schalen met behulp van aangepaste statistieken, schalen ze omhoog/omlaag op basis van binnenkomend verkeer.
In de normale modus wordt al het regionale verkeer naar het lokale cluster geleid en fungeert GKE als reserve in geval van problemen (gezondheidscontroles worden uitgevoerd door Route 53).
...
In de toekomst willen we het routeringsbeleid volledig automatiseren om tot een autonome hybride strategie te komen die de toegankelijkheid voor gebruikers voortdurend verbetert. Aan de positieve kant zijn de cloudkosten aanzienlijk verlaagd en zijn de API-responstijden zelfs verkort. We vertrouwen op het resulterende cloudplatform en zijn bereid om indien nodig meer verkeer ernaar om te leiden.
PS van vertaler
Mogelijk bent u ook geïnteresseerd in een ander recent Dailymotion-bericht over Kubernetes. Het is gewijd aan de implementatie van applicaties met Helm op veel Kubernetes-clusters en ongeveer een maand geleden.
Lees ook op onze blog:
- «.
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «.
Bron: www.habr.com