Sappiamo che al giorno d’oggi parlare di Kubernetes vuol dire essere “sulla cresta dell’onda” e, sebbene in generale l’uso di questo software andrebbe limitato ad aree “specifiche”, ci sono aziende il cui business è interamente basato sull’uso di questo orchestrator.

E’ il caso di Conductor Technologies, azienda forse non troppo conosciuta nell’informatica generalista ma che, nell’ambito rendering video, è una delle migliori, come dimostra l’essere stata parte del processo di produzione di pellicole come Deadpool o Star Trek Beyond. L’idea dell’azienda è quella di permettere a chi deve gestire i propri task di rendering di concentrarsi sul proprio lavoro e non sulla parte infrastrutturale e tecnologica dell’ambiente che eseguirà alla fine il rendering effettivo.

Quando l’azienda ha iniziato la migrazione dal vecchio sistema di gestione basato su macchine virtuali a Kubernetes la scelta è caduta sul sistema offerto da Google, GKE, per potersi concentrare -al tempo il team era composto da due persone- sulla gestione della propria soluzione e non sull’infrastruttura k8s.

Con la crescita del business, i sistemisti di Conductor hanno iniziato a trovarsi davanti dei limiti, sia riguardanti GKE, che Kubernetes stesso:

• L’autoscaler (la funzionalità che permette di incrementare il numero di Pod a seconda del carico degli stessi) di default di Kubernetes, e di conseguenza il GKE autoscaler, non sono pensati per i job di tipo batch. E, caso vuole, il sistema di Conductor usa ampiamente questi job, scatenando situazioni in cui job si accodavano pesantemente senza che venissero scalati in automatico.
• Mancanza totale di controllo su quando le istanze venissero rimosse a seguito della fine di un processo che ne ha generate di nuove grazie all’autoscaling (un problema che anche Atlassian ha avuto)
• Il controller di Kubernetes che si occupa di supervisionare i job batch non è affidabile, ed a volte si perde lo stato delle cose.
• Infine, con GKE, non si ha alcuna visibilità sulla dimensione del “control plane” del cluster. All’incrementare del carico, GKE scala le istanze del control plane per gestire più richieste, ma il tempo di upgrade è parecchio lungo e blocca qualsiasi attività sul cluster così come la possibilità di schedulare nuovi job.

Ed i problemi non sono finiti qua perché, se a questi limiti strutturali si aggiunge una carico parecchio alto sui nodi GKE bloccato da Google per attività di sistema (si parla del 30%/40% delle risorse), uso di driver vecchi per le GPU e limiti sull’uso delle API di GKE (di 600 richieste/minuto).

Insomma, alla fine in Conductor hanno deciso di iniziare a guardarsi intorno per capire come risolvere tutti questi problemi.

In un primo momento hanno optato per i servizi batch di AWS per la loro semplicità ma, con la crescita continua del loro business, gestire le differenze tra GKE ed AWS è diventato sempre più difficile, ed era necessario trovare un nuovo metodo univoco per gestire l’infrastruttura.

Ed è qui che sono arrivati a Nomad, un orchestrator open-source di HashiCorp che fa della semplicità e della flessibilità il suo cavallo di battaglia.

In effetti Conductor conferma la semplicità dell’uso della soluzione: creato un nuovo cluster in un weekend, messo in produzione in due settimane e clienti migrati ad esso in un mese. Inoltre essendo Nomad un singolo binario con un singolo file di configurazione, hanno potuto “colarlo” nelle immagini che usano per gestire gli upgrade con zero downtime semplicemente deployando nuovi nodi. Inoltre il fatto di deployarlo e gestirlo alla stessa maniera indipendentemente da quale sia il fornitore di cloud ha permesso di unificare e semplificare tutti i processi di gestione, indipendentemente da dove le macchine girano (e, con un record di 275.000 core concorrenti e 4.000 istanze in una singola region, direi che avere un sistema di gestione semplice ed univoco è fondamentale).

Se volete maggiori dettagli e benchmark trovate una descrizione più accurata in un interessante articolo su TheNewStack, di seguito vi lasciamo una presentazione tenuta dalla stessa Conductor all’HashiConf Europe di quest’anno. Buona visione.

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.