🥇Avventura Kubernetes di Dailymotion: creazione di infrastrutture nel cloud + in loco

Nota di traduzione.: Dailymotion — uno dei più grandi servizi di hosting video al mondo e quindi un utente significativo 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 è terminata come soluzione ibrida, consentendo di ottenere un miglior tempo di risposta e risparmi sui costi infrastrutturali.

Prendendo una decisione sulla ristrutturazione dell'API principale Dailymotion tre anni fa, volevamo sviluppare un modo più efficiente per distribuire applicazioni e semplificare i processi di sviluppo e produzione. A questo scopo, abbiamo deciso di utilizzare una piattaforma di orchestrazione dei container e naturalmente abbiamo scelto Kubernetes.

Perché dovrebbe essere creata una propria piattaforma basata su Kubernetes?

API di livello di produzione in tempi brevi con Google Cloud

Estate 2016

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

A seguito dell'analisi dei container, delle soluzioni di orchestrazione e delle nostre esperienze precedenti, abbiamo concluso 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 grande vantaggio per la trasformazione dell'infrastruttura.

Dal punto di vista dell'infrastruttura, era necessaria una potente e flessibile soluzione per ospitare nuovi tipi di applicazioni cloud-native. Abbiamo preferito rimanere nel cloud all'inizio del nostro viaggio per costruire tranquillamente 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 ci saremmo trasferiti nei nostri data center e avremmo applicato una strategia ibrida.

Perché abbiamo scelto GKE?

Abbiamo fatto questa scelta principalmente per motivi tecnici. Inoltre, era necessario fornire rapidamente un'infrastruttura che rispondesse alle esigenze aziendali. Avevamo alcuni requisiti per l'hosting delle applicazioni, come la distribuzione geografica, la scalabilità e la tolleranza ai guasti.

Cluster GKE in Dailymotion

Poiché Dailymotion è una piattaforma video accessibile in tutto il mondo, volevamo davvero migliorare la qualità del servizio, riducendo il tempo di attesa (latency). Prima la nostra API era disponibile solo a Parigi, il che era subottimale. Volevamo avere la possibilità di distribuire le applicazioni non solo in Europa, ma anche in Asia e negli Stati Uniti.

Questa sensibilità ai ritardi significava che era necessario 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 qualche servizio gestito, Google Cloud consentiva di creare una rete unica e totalmente instradabile, che coprisse tutte le regioni di Google. Questo è un grande vantaggio in termini di operatività ed efficienza del sistema.

Inoltre, i servizi di rete e i bilanciatori di carico di Google Cloud svolgono egregiamente il loro lavoro. Consentono semplicemente di utilizzare indirizzi IP pubblici arbitrari da ciascuna regione e il meraviglioso protocollo BGP si occuperà di tutto il resto (ossia reindirizzerà gli utenti al cluster più vicino). È ovvio che, in caso di guasto, il traffico verrà automaticamente instradato verso un'altra regione senza alcun intervento umano.

Monitoraggio del bilanciamento del carico in Google

La nostra piattaforma sfrutta anche attivamente le unità di elaborazione grafica. Google Cloud consente di utilizzarle in modo molto efficiente direttamente nei cluster Kubernetes.

Nel frattempo, il team di infrastruttura si concentrava principalmente sul vecchio stack distribuito su server fisici. È per questo che 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 i cluster locali.

Di conseguenza, siamo riusciti a iniziare ad accettare il traffico di produzione sull'infrastruttura Google Cloud solo sei mesi dopo l'inizio del lavoro.

Tuttavia, nonostante una serie di vantaggi, lavorare con un fornitore di cloud comporta determinati costi, che possono aumentare a seconda del carico. È per questo che abbiamo attentamente analizzato ciascun servizio gestito utilizzato, prevedendo di implementarli in futuro presso di noi on-premises. In realtà, l'implementazione dei cluster locali è iniziata alla fine del 2016 e in quel momento è stata avviata la strategia ibrida.

Lancio della piattaforma locale di orchestrazione dei container di Dailymotion

Autunno 2016

In un contesto in cui l'intero stack era pronto per la produzione e il lavoro sull'API è durato, c'era tempo per concentrarsi sui cluster regionali.

A quel tempo, gli utenti visualizzavano oltre 3 miliardi di video al mese. Certo, avevamo già operato nel corso degli anni una rete di Content Delivery Network ben sviluppata. Volevamo sfruttare questa situazione e distribuire cluster Kubernetes nei centri dati esistenti.

L'infrastruttura di Dailymotion contava oltre 2.500 server in sei data center. Tutti sono configurati utilizzando Saltstack. Abbiamo iniziato a preparare tutte le ricette necessarie per creare nodi master e worker, così come il 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 adottato a livello di L3) era Calico. Si è integrato perfettamente nel modello di rete esistente dell'infrastruttura.

Poiché volevamo utilizzare tutti gli elementi esistenti nell'infrastruttura, innanzitutto dovevamo capire la nostra utilità di rete interna (utilizzata su tutti i server): usarla per annunciare le gamme di indirizzi IP nella rete con i nodi Kubernetes. Abbiamo permesso a Calico di assegnare gli indirizzi IP ai pod, ma non lo abbiamo utilizzato e non lo utilizziamo tuttora per le sessioni BGP sull'hardware di rete. Di fatto, il routing è gestito da Exabgp, che annuncia le sottoreti utilizzate da Calico. Questo ci consente di raggiungere qualsiasi pod dalla rete interna (e in particolare dai bilanciatori di carico).

Come gestiamo il traffico ingress

Per reindirizzare le richieste in ingresso al servizio corretto, è stato deciso di utilizzare l'Ingress Controller per la sua integrazione con le risorse ingress di Kubernetes.

Tre anni fa, l'nginx-ingress-controller era il controller più maturo: Nginx era già utilizzato da tempo ed era conosciuto per la sua stabilità e prestazioni.

Nel nostro sistema abbiamo deciso di posizionare i controller su blade server dedicati da 10 gigabit. Ogni controller si collegava all'endpoint kube-apiserver del corrispondente 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 tipo 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 chiarito la nostra piattaforma ibrida, possiamo approfondire il processo di migrazione del traffico.

Migrazione del traffico da Google Cloud all'infrastruttura Dailymotion

Autunno 2018

Dopo quasi due anni di creazione, test e configurazione, abbiamo finalmente ottenuto un'intera stack Kubernetes pronta ad accogliere parte del traffico.

L'attuale strategia di instradamento è piuttosto semplice, ma soddisfa appieno le esigenze. Oltre agli IP pubblici (in Google Cloud e Dailymotion), utilizziamo AWS Route 53 per definire politiche e reindirizzare gli utenti al cluster di nostra scelta.

Esempio di politica di instradamento con Route 53

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

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

Poiché i nostri cluster GKE sono configurati per il ridimensionamento automatico tramite Custom Metrics, aumentano/diminuiscono le risorse in base al traffico in entrata.

In condizioni normali, tutto il traffico regionale è diretto al cluster locale, mentre GKE funge da riserva in caso di problemi (i controlli di stato sono effettuati da Route 53).

…

In futuro vogliamo automatizzare completamente le politiche di routing, per ottenere una strategia ibrida autonoma che migliori continuamente l'accessibilità per gli utenti. Per quanto riguarda i vantaggi: i costi per il cloud sono stati notevolmente ridotti e siamo riusciti a ridurre anche il tempo di risposta dell'API. Ci fidiamo della piattaforma cloud risultante e siamo pronti a reindirizzare più traffico su di essa se necessario.

P.S. dal traduttore

Potrebbe anche interessarvi un'altra recente pubblicazione di Dailymotion su Kubernetes. È dedicata al deployment di applicazioni con Helm su diversi cluster Kubernetes e è stata pubblicata circa un mese fa.