Nota. trad.: Dailymotion è uno dei servizi di hosting video più grandi al mondo e quindi un notevole utente Kubernetes. In questo materiale, l'architetto di sistema David Donchez condivide i risultati della creazione della piattaforma di produzione dell'azienda basata su K8, iniziata con un'installazione cloud in GKE e terminata con una soluzione ibrida, che ha consentito tempi di risposta migliori e risparmi sui costi dell'infrastruttura.
Decidere di ricostruire l'API core tre anni fa, volevamo sviluppare un modo più efficiente per ospitare le applicazioni e renderlo più semplice . A questo scopo abbiamo deciso di utilizzare una piattaforma di orchestrazione dei container e naturalmente abbiamo scelto Kubernetes.
Perché vale la pena costruire la propria piattaforma basata su Kubernetes?
API a livello di produzione in pochissimo tempo utilizzando Google Cloud
Estate 2016
Tre anni fa, subito dopo l'acquisizione di Dailymotion da parte di , i nostri team di ingegneri sono concentrati su un obiettivo globale: creare un prodotto Dailymotion completamente nuovo.
Sulla base della nostra analisi dei container, delle soluzioni di orchestrazione e della nostra esperienza passata, siamo convinti che Kubernetes sia la scelta giusta. Alcuni sviluppatori comprendevano già i concetti di base e sapevano come utilizzarli, il che ha rappresentato un enorme vantaggio per la trasformazione dell'infrastruttura.
Dal punto di vista dell'infrastruttura, era necessario un sistema potente e flessibile per ospitare nuovi tipi di applicazioni native del cloud. Abbiamo scelto di rimanere nel cloud all'inizio del nostro viaggio in modo da poter costruire in tutta tranquillità la piattaforma on-premise più solida possibile. Abbiamo deciso di implementare 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é hai scelto GKE?
Abbiamo fatto questa scelta principalmente per ragioni tecniche. Inoltre, era necessario fornire rapidamente un'infrastruttura che soddisfacesse le esigenze aziendali. Avevamo alcuni requisiti per l'hosting delle applicazioni, come distribuzione geografica, scalabilità e tolleranza agli errori.
Cluster GKE in Dailymotion
Poiché Dailymotion è una piattaforma video disponibile in tutto il mondo, volevamo davvero migliorare la qualità del servizio riducendo i tempi di attesa (latenza). Prima era disponibile solo a Parigi, il che non era ottimale. Volevo poter ospitare applicazioni non solo in Europa, ma anche in Asia e negli Stati Uniti.
Questa sensibilità alla latenza significava che sarebbe stato necessario svolgere un lavoro serio sull'architettura di rete della piattaforma. Mentre la maggior parte dei servizi cloud ti obbliga a creare la tua rete in ciascuna regione e quindi a collegarla tramite una VPN o qualche tipo di servizio gestito, Google Cloud ti consente di creare un'unica rete completamente instradabile che copre tutte le regioni di Google. Questo è un grande vantaggio in termini di funzionamento ed efficienza del sistema.
Inoltre, i servizi di rete e i bilanciatori del carico di Google Cloud svolgono un ottimo lavoro. Ti consentono semplicemente di utilizzare indirizzi IP pubblici arbitrari da ciascuna regione e il meraviglioso protocollo BGP si occupa di tutto il resto (ovvero reindirizzando gli utenti al cluster più vicino). Ovviamente, in caso di guasto, il traffico si sposterà automaticamente in un'altra regione senza alcun intervento umano.
Monitoraggio del bilanciamento del carico di Google
La nostra piattaforma fa anche un uso massiccio di GPU. Google Cloud ti consente di utilizzarli in modo molto efficace direttamente nei cluster Kubernetes.
All'epoca, il team dell'infrastruttura si concentrava principalmente sullo stack legacy distribuito sui server fisici. Ecco perché l'utilizzo di un servizio gestito (inclusi i master Kubernetes) ha soddisfatto i nostri requisiti e ci ha permesso di formare i team per lavorare con i cluster locali.
Di conseguenza, abbiamo potuto iniziare a ricevere il traffico di produzione sull'infrastruttura Google Cloud già dopo soli 6 mesi dall'inizio dei lavori.
Tuttavia, nonostante una serie di vantaggi, la collaborazione con un fornitore di servizi cloud comporta determinati costi, che possono aumentare a seconda del carico. Ecco perché abbiamo analizzato attentamente ogni servizio gestito che abbiamo utilizzato, sperando di implementarli on-premise in futuro. L’implementazione dei cluster locali, infatti, è iniziata alla fine del 2016 e contestualmente è stata avviata la strategia ibrida.
Lancio della piattaforma di orchestrazione dei container locali Dailymotion
Autunno '2016
In condizioni in cui l'intero stack era pronto per la produzione e funzionava sull'API , era giunto il momento di concentrarsi sui cluster regionali.
A quel tempo, gli utenti guardavano più di 3 miliardi di video ogni mese. Naturalmente disponiamo da molti anni della nostra vasta rete di distribuzione dei contenuti. Volevamo sfruttare questa circostanza e implementare i cluster Kubernetes nei data center esistenti.
L'infrastruttura di Dailymotion era composta da oltre 2,5mila server in sei data center. Tutti sono configurati utilizzando Saltstack. Abbiamo iniziato a preparare tutte le ricette necessarie per creare nodi master e di lavoro, nonché un cluster etcd.
Parte di rete
La nostra rete è completamente instradata. Ogni server pubblicizza il proprio IP sulla rete utilizzando Exabgp. Abbiamo confrontato diversi plugin di rete e l'unico che ha soddisfatto tutte le esigenze (grazie all'approccio L3 utilizzato) è stato . Si inserisce perfettamente nel modello di infrastruttura di rete esistente.
Dato che volevamo utilizzare tutti gli elementi dell'infrastruttura disponibili, la prima cosa che dovevamo fare era capire la nostra utilità di rete sviluppata internamente (utilizzata su tutti i server): usarla per pubblicizzare gli intervalli di indirizzi IP sulla rete con i nodi Kubernetes. Abbiamo consentito a Calico di assegnare indirizzi IP ai pod, ma non lo abbiamo utilizzato e non lo utilizziamo ancora per le sessioni BGP sulle apparecchiature di rete. Infatti, il routing è gestito da Exabgp, che pubblicizza le sottoreti utilizzate da Calico. Questo ci permette di raggiungere qualsiasi pod dalla rete interna (e in particolare dai bilanciatori di carico).
Come gestiamo il traffico in entrata
Per reindirizzare le richieste in entrata al servizio desiderato, si è deciso di utilizzare Ingress Controller grazie alla sua integrazione con le risorse di ingresso Kubernetes.
Tre anni fa, nginx-ingress-controller era il controller più maturo: Nginx esisteva da molto tempo ed era noto per la sua stabilità e prestazioni.
Nel nostro sistema, abbiamo deciso di posizionare i controller su server blade dedicati da 10 Gigabit. Ogni controller era connesso all'endpoint kube-apiserver del cluster corrispondente. Questi server utilizzavano anche Exabgp per pubblicizzare indirizzi IP pubblici o privati. La nostra topologia di rete ci 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 migliora l'efficienza.
Movimento del traffico da Internet ai pod
Ora che conosciamo la nostra piattaforma ibrida, possiamo approfondire il processo di migrazione del traffico stesso.
Migrazione del traffico da Google Cloud all'infrastruttura Dailymotion
Autunno '2018
Dopo quasi due anni di creazione, test e messa a punto, abbiamo finalmente uno stack Kubernetes completo pronto ad accettare parte del traffico.
L'attuale strategia di routing è abbastanza semplice, ma sufficiente a soddisfare le esigenze. Oltre agli IP pubblici (su Google Cloud e Dailymotion), AWS Route 53 viene utilizzato per impostare policy e reindirizzare gli utenti al cluster di nostra scelta.
Esempio di policy di routing utilizzando Route 53
Con Google Cloud questo è semplice poiché condividiamo un singolo IP tra 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 diversi.
Durante la migrazione, abbiamo cercato di reindirizzare le richieste regionali ai cluster appropriati e valutato i vantaggi di questo approccio.
Poiché i nostri cluster GKE sono configurati per la scalabilità automatica utilizzando le metriche personalizzate, aumentano o diminuiscono in base al traffico in entrata.
In modalità normale, tutto il traffico regionale viene indirizzato al cluster locale e GKE funge da riserva in caso di problemi (i controlli sanitari vengono effettuati dalla Route 53).
...
In futuro, vogliamo automatizzare completamente le policy di routing per ottenere una strategia ibrida autonoma che migliori continuamente l’accessibilità per gli utenti. L’aspetto positivo è che i costi del cloud sono stati notevolmente ridotti e i tempi di risposta delle API sono stati addirittura ridotti. Ci fidiamo della piattaforma cloud risultante e siamo pronti a reindirizzarvi più traffico, se necessario.
PS da traduttore
Potresti anche essere interessato a un altro post recente di Dailymotion su Kubernetes. È dedicato alla distribuzione di applicazioni con Helm su molti cluster Kubernetes e circa un mese fa.
Leggi anche sul nostro blog:
- «'.
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «'.
Fonte: habr.com