{"id":36484,"date":"2019-10-31T22:11:54","date_gmt":"2019-10-31T19:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises\/"},"modified":"2019-10-31T22:11:54","modified_gmt":"2019-10-31T19:11:54","slug":"kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","title":{"rendered":"Avventura Kubernetes di Dailymotion: costruzione di infrastrutture nel cloud + on-premises","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Avventura
\n
\nNota di traduzione.<\/b>: Dailymotion \u2014 uno dei pi\u00f9 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 \u00e8 iniziata con un'installazione cloud in GKE ed \u00e8 terminata come soluzione ibrida, consentendo di ottenere un miglior tempo di risposta e risparmi sui costi infrastrutturali.<\/i><\/p>\n

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

Perch\u00e9 dovrebbe essere creata una propria piattaforma basata su Kubernetes?<\/a><\/noindex><\/p>\n

API di livello di produzione in tempi brevi con Google Cloud<\/h2>\n

<\/p>\n

Estate 2016<\/p><\/blockquote>\n

\nTre anni fa, subito dopo l'acquisto di Dailymotion da parte della Vivendi<\/a><\/noindex>, i nostri team di ingegneri si sono concentrati su un obiettivo globale: creare un prodotto Dailymotion completamente nuovo.<\/p>\n

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\u00e0 familiarit\u00e0 con i concetti di base e sapeva come utilizzarlo, il che \u00e8 stato un grande vantaggio per la trasformazione dell'infrastruttura.<\/p>\n

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\u00f9 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.<\/p>\n

Perch\u00e9 abbiamo scelto GKE?<\/h3>\n

\nAbbiamo 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\u00e0 e la tolleranza ai guasti.<\/p>\n

\"Avventura
\nCluster GKE in Dailymotion<\/i><\/p>\n

Poich\u00e9 Dailymotion \u00e8 una piattaforma video accessibile in tutto il mondo, volevamo davvero migliorare la qualit\u00e0 del servizio, riducendo il tempo di attesa (latency)<\/i>. Prima la nostra API<\/a><\/noindex> era disponibile solo a Parigi, il che era subottimale. Volevamo avere la possibilit\u00e0 di distribuire le applicazioni non solo in Europa, ma anche in Asia e negli Stati Uniti.<\/p>\n

Questa sensibilit\u00e0 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 \u00e8 un grande vantaggio in termini di operativit\u00e0 ed efficienza del sistema.<\/p>\n

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\u00e0 di tutto il resto (ossia reindirizzer\u00e0 gli utenti al cluster pi\u00f9 vicino). \u00c8 ovvio che, in caso di guasto, il traffico verr\u00e0 automaticamente instradato verso un'altra regione senza alcun intervento umano.<\/p>\n

\"Avventura
\nMonitoraggio del bilanciamento del carico in Google<\/i><\/p>\n

La nostra piattaforma sfrutta anche attivamente le unit\u00e0 di elaborazione grafica. Google Cloud consente di utilizzarle in modo molto efficiente direttamente nei cluster Kubernetes.<\/p>\n

Nel frattempo, il team di infrastruttura si concentrava principalmente sul vecchio stack distribuito su server fisici. \u00c8 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.<\/p>\n

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

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

Lancio della piattaforma locale di orchestrazione dei container di Dailymotion<\/h2>\n

<\/p>\n

Autunno 2016<\/p><\/blockquote>\n

\nIn un contesto in cui l'intero stack era pronto per la produzione e il lavoro sull'API \u00e8 durato<\/a><\/noindex>, c'era tempo per concentrarsi sui cluster regionali.<\/p>\n

A quel tempo, gli utenti visualizzavano oltre 3 miliardi di video al mese. Certo, avevamo gi\u00e0 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.<\/p>\n

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\u00ec come il cluster etcd.<\/p>\n

\"Avventura
\n<\/p>\n

Parte di rete<\/h3>\n

\nLa nostra rete \u00e8 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<\/a><\/noindex>. Si \u00e8 integrato perfettamente nel modello di rete esistente dell'infrastruttura.<\/p>\n

Poich\u00e9 volevamo utilizzare tutti gli elementi infrastrutturali esistenti, innanzitutto dovevamo capire la nostra utility di rete interna (utilizzata su tutti i server): usarla per annunciare gli intervalli di indirizzi IP nella rete con nodi Kubernetes. Abbiamo permesso a Calico di assegnare indirizzi IP ai pod, ma non l'abbiamo usato e non lo usiamo ancora per le sessioni BGP sulle apparecchiature di rete. In effetti, la gestione del routing \u00e8 affidata a 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).<\/p>\n

Come gestiamo il traffico ingress<\/h3>\n

\nPer reindirizzare le richieste in ingresso al servizio corretto, \u00e8 stato deciso di utilizzare l'Ingress Controller per la sua integrazione con le risorse ingress di Kubernetes.<\/p>\n

Tre anni fa, l'nginx-ingress-controller era il controller pi\u00f9 maturo: Nginx era gi\u00e0 utilizzato da tempo ed era conosciuto per la sua stabilit\u00e0 e prestazioni.<\/p>\n

Nel nostro sistema abbiamo deciso di posizionare i controller su blade server dedicati da 10 gigabit. Ogni controller si connetteva all'endpoint kube-apiserver del cluster corrispondente. 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 servizi come NodePort. Questo approccio aiuta a evitare il traffico orizzontale tra i nodi e aumenta l'efficienza.<\/p>\n

\"Avventura
\nTraffico dati da Internet ai pod<\/i><\/p>\n

Ora che abbiamo chiarito la nostra piattaforma ibrida, possiamo approfondire il processo di migrazione del traffico.<\/p>\n

Migrazione del traffico da Google Cloud all'infrastruttura Dailymotion<\/h2>\n

<\/p>\n

Autunno 2018<\/p><\/blockquote>\n

\nDopo quasi due anni di creazione, test e configurazione, abbiamo finalmente ottenuto un'intera stack Kubernetes pronta ad accogliere parte del traffico.<\/p>\n

\"Avventura
\n
\nL'attuale strategia di instradamento \u00e8 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.<\/p>\n

\"Avventura
\nEsempio di politica di instradamento con Route 53<\/i><\/p>\n

Con Google Cloud \u00e8 semplice, poich\u00e9 utilizziamo un singolo IP per tutti i cluster, e l'utente viene reindirizzato al cluster GKE pi\u00f9 vicino. La tecnologia per i nostri cluster \u00e8 diversa, poich\u00e9 i loro IP sono diversi.<\/p>\n

Durante la migrazione, abbiamo cercato di reindirizzare le richieste regionali ai cluster corrispondenti e abbiamo valutato i vantaggi di questo approccio.<\/p>\n

Poich\u00e9 i nostri cluster GKE sono configurati per il ridimensionamento automatico tramite Custom Metrics, aumentano\/diminuiscono le risorse in base al traffico in entrata.<\/p>\n

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

\u2026<\/h2>\n

\nIn futuro vogliamo automatizzare completamente le politiche di routing, per ottenere una strategia ibrida autonoma che migliori continuamente l'accessibilit\u00e0 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\u00f9 traffico su di essa se necessario.<\/p>\n

P.S. dal traduttore<\/h2>\n

\nPotrebbe anche interessarvi un'altra recente pubblicazione di Dailymotion su Kubernetes. \u00c8 dedicata al deployment di applicazioni con Helm su diversi cluster Kubernetes e \u00e8 stata pubblicata<\/a><\/noindex> circa un mese fa.<\/p>\n

Leggi anche nel nostro blog:<\/p>\n