🥇Avventura Kubernetes di Dailymotion: creazione di infrastrutture nel cloud + on-premises

Nota del traduttore.: Dailymotion — uno dei più grandi servizi di hosting video al mondo e un notevole utilizzatore di Kubernetes. In questo articolo, l'architetto di sistema David Donchez condivide i risultati della creazione della piattaforma di produzione dell'azienda basata su K8s, che è iniziata con un'installazione cloud in GKE ed è diventata una soluzione ibrida, consentendo di ottenere tempi di risposta migliori e risparmiare sui costi infrastrutturali.

Nella decisione di ristrutturare l'API principale Dailymotion tre anni fa, volevamo sviluppare un modo più efficiente di ospitare applicazioni e semplificare i processi di sviluppo e produzione. A tal fine, abbiamo deciso di utilizzare una piattaforma di orchestrazione dei container e abbiamo naturalmente scelto Kubernetes.

Perché creare una propria piattaforma basata su Kubernetes?

API di livello production in tempi brevi grazie a Google Cloud

Estate 2016

Tre anni fa, subito dopo l'acquisizione di Dailymotion da parte di Vivendi, i nostri team di ingegneri si sono concentrati su un obiettivo globale: creare un prodotto completamente nuovo per Dailymotion.

Dopo aver analizzato i container, le soluzioni di orchestrazione e la nostra esperienza passata, ci siamo resi conto che Kubernetes era la scelta giusta. Parte degli sviluppatori aveva già familiarità con i concetti di base e sapeva come utilizzarlo, il che è stato un enorme vantaggio per la trasformazione infrastrutturale.

Dal punto di vista dell'infrastruttura, era necessaria una potente e flessibile sistema per ospitare nuovi tipi di applicazioni cloud-native. Abbiamo preferito rimanere nel cloud all'inizio del nostro viaggio, per costruire una piattaforma locale il più affidabile possibile. Abbiamo deciso di distribuire le nostre applicazioni utilizzando Google Kubernetes Engine, anche se sapevamo che prima o poi saremmo passati ai nostri data center e avremmo applicato una strategia ibrida.

Perché abbiamo scelto GKE?

Abbiamo preso questa decisione principalmente per motivi tecnici. Inoltre, era necessario fornire rapidamente un'infrastruttura che soddisfacesse le esigenze aziendali. Avevamo alcune necessità di ospitare applicazioni, come distribuzione geografica, scalabilità e resilienza.

I cluster GKE in Dailymotion

Poiché Dailymotion è una piattaforma video accessibile in tutto il mondo, volevamo migliorare la qualità del servizio riducendo i tempi di attesa (latency). In precedenza la nostra API era accessibile solo a Parigi, il che non era ottimale. Volevamo essere in grado di ospitare applicazioni non solo in Europa, ma anche in Asia e negli Stati Uniti.

Questa sensibilità ai ritardi significava che dovevamo lavorare seriamente sull'architettura di rete della piattaforma. Mentre la maggior parte dei servizi cloud costringeva a creare la propria rete in ogni regione e poi a collegarle tramite VPN o un servizio gestito, Google Cloud ci ha permesso di creare una rete completamente instradabile che copriva tutte le regioni di Google. Questo è un grande vantaggio in termini di operatività e efficienza del sistema.

Inoltre, i servizi di rete e i bilanciatori di carico di Google Cloud fanno un ottimo lavoro. Consentono semplicemente di utilizzare indirizzi IP pubblici arbitrari da ciascuna regione, mentre l'eccellente protocollo BGP si occupa di tutto il resto (cioè reindirizza gli utenti al cluster più vicino). È evidente che, in caso di guasto, il traffico verrà automaticamente indirizzato a un'altra regione senza alcun intervento umano.

Monitoraggio del bilanciamento del carico in Google

La nostra piattaforma utilizza anche attivamente le GPU. Google Cloud consente di utilizzarle in modo molto efficiente direttamente nei cluster Kubernetes.

All'epoca, il team infrastrutturale si concentrava principalmente sul vecchio stack distribuito su server fisici. Per questo motivo, l'uso di un servizio gestito (inclusi i componenti master di Kubernetes) soddisfaceva le nostre esigenze e permetteva di formare i team a lavorare con cluster locali.

Di conseguenza, siamo riusciti a iniziare a ricevere traffico di produzione sull'infrastruttura Google Cloud solo sei mesi dopo l'inizio dei lavori.

Tuttavia, nonostante i vari vantaggi, lavorare con un fornitore cloud comporta costi specifici che possono aumentare a seconda del carico. Ecco perché abbiamo attentamente analizzato ogni servizio gestito utilizzato, pianificando di implementarli in futuro on-premises. In effetti, l'implementazione di cluster locali è iniziata alla fine del 2016 e in quel momento è stata avviata una strategia ibrida.

Lancio della piattaforma locale di orchestrazione dei container di Dailymotion

Autunno 2016

Una volta che l'intero stack era pronto per la produzione e i lavori sull'API è continuato, era tempo di concentrarsi sui cluster regionali.

All'epoca gli utenti visualizzavano oltre 3 miliardi di video ogni mese. Naturalmente, la nostra rete di Content Delivery Network era già attiva da diversi anni. Volevamo sfruttare questa situazione e implementare cluster Kubernetes nei data center esistenti.

L'infrastruttura di Dailymotion comprendeva oltre 2.500 server distribuiti in sei data center. Tutti venivano configurati tramite Saltstack. Iniziammo a preparare tutte le ricette necessarie per creare i nodi master e worker, oltre al cluster etcd.

Parte di rete

La nostra rete è completamente instradabile. Ogni server annuncia il proprio IP nella rete tramite Exabgp. Abbiamo confrontato diversi plugin di rete e l'unico che soddisfaceva tutte le esigenze (a causa dell'approccio utilizzato a livello L3) era Calico. Si è adattato perfettamente al modello di rete esistente dell'infrastruttura.

Poiché desideravamo utilizzare tutti gli elementi dell'infrastruttura, dovevamo prima capire la nostra utility di rete in casa (utilizzata su tutti i server): dovevamo usarla per annunciare i range di indirizzi IP nella rete con i nodi Kubernetes. Abbiamo permesso a Calico di assegnare indirizzi IP ai pod, ma non lo abbiamo utilizzato e non lo utilizziamo ancora per le sessioni BGP sull'hardware di rete. In realtà, l'instradamento è gestito da Exabgp, che annuncia le subnet utilizzate da Calico. Questo ci consente di raggiungere qualsiasi pod dalla rete interna (in particolare dai bilanciatori di carico).

Come gestiamo il traffico ingress

Per reindirizzare le richieste in arrivo al servizio corretto, abbiamo deciso di utilizzare Ingress Controller grazie alla sua integrazione con le risorse ingress di Kubernetes.

Tre anni fa, nginx-ingress-controller era il controller più maturo: Nginx era già ampiamente utilizzato ed era noto per la sua stabilità e prestazioni.

Nel nostro sistema abbiamo deciso di posizionare i controller su server blade dedicati a 10 gigabit. Ogni controller si collegava all'endpoint kube-apiserver del relativo cluster. Su questi server veniva utilizzato anche Exabgp per annunciare indirizzi IP pubblici o privati. La topologia della nostra rete consente di utilizzare BGP da questi controller per instradare tutto il traffico direttamente ai pod senza utilizzare un servizio come NodePort. Questo approccio aiuta a evitare il traffico orizzontale tra i nodi e aumenta l'efficienza.

Movimento del traffico da Internet ai pod

Ora che abbiamo compreso la nostra piattaforma ibrida, possiamo immergerci nel processo stesso di migrazione del traffico.

Migrazione del traffico da Google Cloud all'infrastruttura Dailymotion

Autunno 2018

Dopo quasi due anni di creazione, testing e configurazione, abbiamo finalmente ottenuto un full stack Kubernetes pronto ad accogliere parte del traffico.

La strategia attuale di instradamento è piuttosto semplice, ma soddisfa le necessità. Oltre agli IP pubblici (in Google Cloud e Dailymotion), utilizziamo AWS Route 53 per definire le politiche e reindirizzare gli utenti al cluster che scegliamo.

Esempio di politica di instradamento utilizzando Route 53

Con Google Cloud è semplice, poiché utilizziamo un solo IP per tutti i cluster, e l'utente viene reindirizzato al cluster GKE più vicino. Per i nostri cluster, la tecnologia è diversa, poiché i loro IP sono differenti.

Durante la migrazione, ci siamo impegnati a reindirizzare le richieste regionali ai cluster corrispondenti e abbiamo valutato i vantaggi di questo approccio.

Poiché i nostri cluster GKE sono configurati per l'auto-scaling utilizzando Metriche Personalizzate, aumentano o riducono le risorse in base al traffico in ingresso.

In condizioni normali, tutto il traffico regionale viene indirizzato al cluster locale, mentre GKE funge da riserva in caso di problemi (i health-check vengono eseguiti da Route 53).

…

In futuro vogliamo automatizzare completamente le politiche di instradamento per ottenere una strategia ibrida autonoma che migliori costantemente la disponibilità per gli utenti. Tra i vantaggi: i costi per il cloud sono notevolmente diminuiti e siamo riusciti anche a ridurre il tempo di risposta API. Ci fidiamo della piattaforma cloud risultante e siamo pronti a reindirizzare maggior traffico su di essa se necessario.

P.S. dal traduttore

Potrebbe interessarti anche un'altra recente pubblicazione di Dailymotion su Kubernetes. È dedicata al deployment delle applicazioni con Helm su più cluster Kubernetes e è stato pubblicato circa un mese fa.

Leggete anche nel nostro blog: