{"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":"L'avventura di Kubernetes di Dailymotion: creazione di un'infrastruttura nel cloud + on-premises","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"L'avventura
\n
\nNota del traduttore.<\/b>: Dailymotion \u2014 uno dei pi\u00f9 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 \u00e8 iniziata con un'installazione cloud in GKE ed \u00e8 diventata una soluzione ibrida, consentendo di ottenere tempi di risposta migliori e risparmiare sui costi infrastrutturali.<\/i><\/p>\n

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

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

API di livello production in tempi brevi grazie a Google Cloud<\/h2>\n

<\/p>\n

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

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

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

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

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

\nAbbiamo preso questa decisione principalmente per motivi tecnici. Inoltre, era necessario fornire rapidamente un'infrastruttura che soddisfacesse le esigenze aziendali. Avevamo alcune necessit\u00e0 di ospitare applicazioni, come distribuzione geografica, scalabilit\u00e0 e resilienza.<\/p>\n

\"L'avventura
\nI cluster GKE in Dailymotion<\/i><\/p>\n

Poich\u00e9 Dailymotion \u00e8 una piattaforma video accessibile in tutto il mondo, volevamo migliorare la qualit\u00e0 del servizio riducendo i tempi di attesa (latency)<\/i>. In precedenza la nostra API<\/a><\/noindex> 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.<\/p>\n

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

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\u00e8 reindirizza gli utenti al cluster pi\u00f9 vicino). \u00c8 evidente che, in caso di guasto, il traffico verr\u00e0 automaticamente indirizzato a un'altra regione senza alcun intervento umano.<\/p>\n

\"L'avventura
\nMonitoraggio del bilanciamento del carico in Google<\/i><\/p>\n

La nostra piattaforma utilizza anche attivamente le GPU. Google Cloud consente di utilizzarle in modo molto efficiente direttamente nei cluster Kubernetes.<\/p>\n

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

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

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

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

<\/p>\n

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

\nUna volta che l'intero stack era pronto per la produzione e i lavori sull'API \u00e8 continuato<\/a><\/noindex>, era tempo di concentrarsi sui cluster regionali.<\/p>\n

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

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

\"L'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 utilizzato a livello L3) era Calico<\/a><\/noindex>. Si \u00e8 adattato perfettamente al modello di rete esistente dell'infrastruttura.<\/p>\n

Poich\u00e9 volevamo utilizzare tutti gli elementi dell'infrastruttura esistente, prima di tutto dovevamo capire la nostra utility di rete interna (utilizzata su tutti i server): utilizzarla 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 nemmeno per le sessioni BGP sull'hardware di rete. Di fatto, la routizzazione \u00e8 gestita da Exabgp, che annuncia le sottoreti utilizzate da Calico. Questo ci permette di raggiungere qualsiasi pod dalla rete interna (in particolare dai bilanciatori di carico).<\/p>\n

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

\nPer reindirizzare le richieste in arrivo al servizio corretto, abbiamo deciso di utilizzare Ingress Controller grazie alla sua integrazione con le risorse ingress di Kubernetes.<\/p>\n

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

Nella nostra configurazione 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 anche utilizzato 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

\"L'avventura
\nIl traffico da internet ai pod<\/i><\/p>\n

Ora che abbiamo compreso la nostra piattaforma ibrida, possiamo immergerci nel processo stesso 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, testing e configurazione, abbiamo finalmente ottenuto un full stack Kubernetes pronto ad accogliere parte del traffico.<\/p>\n

\"L'avventura
\n
\nLa strategia attuale di instradamento \u00e8 piuttosto semplice, ma soddisfa le necessit\u00e0. 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.<\/p>\n

\"L'avventura
\nEsempio di politica di instradamento utilizzando Route 53<\/i><\/p>\n

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

Durante la migrazione, ci siamo impegnati a 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 l'auto-scaling utilizzando Metriche Personalizzate, aumentano o riducono le risorse in base al traffico in ingresso.<\/p>\n

In condizioni normali, tutto il traffico regionale viene indirizzato al cluster locale, mentre GKE funge da riserva in caso di problemi (i controlli di integrit\u00e0 vengono effettuati tramite Route 53).<\/p>\n

\u2026<\/h2>\n

\nIn futuro vogliamo automatizzare completamente le politiche di instradamento per ottenere una strategia ibrida autonoma che migliori costantemente la disponibilit\u00e0 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>\n

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

\nPotrebbe interessarti anche un'altra recente pubblicazione di Dailymotion su Kubernetes. \u00c8 dedicata al deployment delle applicazioni con Helm su pi\u00f9 cluster Kubernetes e \u00e8 stato pubblicato<\/a><\/noindex> circa un mese fa.<\/p>\n

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