Le al­ter­na­ti­ve a Ku­ber­ne­tes

Ku­ber­ne­tes è il leader nel settore dei programmi di or­che­stra­zio­ne dei cluster. Ma ci sono anche delle al­ter­na­ti­ve alquanto in­te­res­san­ti, ognuna con vantaggi e svantaggi specifici, così come diverse pos­si­bi­li­tà di utilizzo. Da un cluster locale per un proprio ambiente di sviluppo fino a un sistema di­stri­bui­to e ad alta di­spo­ni­bi­li­tà con decine di migliaia di nodi. Vi pre­sen­tia­mo le migliori soluzioni tra cui scegliere.

Ku­ber­ne­tes si è imposto come standard per l’or­che­stra­zio­ne dei container in seguito al successo avuto da Docker come piat­ta­for­ma per la vir­tua­liz­za­zio­ne dei container. Tuttavia, la gamma di funzione di Ku­ber­ne­tes va oltre l’am­mi­ni­stra­zio­ne di gruppi di container. Ku­ber­ne­tes au­to­ma­tiz­za il de­ploy­ment, la gestione e la sca­la­bi­li­tà delle ap­pli­ca­zio­ni con­tai­ne­riz­za­te e in più supporta le seguenti fun­zio­na­li­tà:

• Rollout e rollback delle modifiche au­to­ma­tiz­za­ti
• Ri­le­va­men­to dei servizi (Service Discovery) interno alla rete
• Or­che­stra­zio­ne dei di­spo­si­ti­vi di ar­chi­via­zio­ne di massa
• Pos­si­bi­li­tà di scalare ap­pli­ca­zio­ni e servizi
• Ela­bo­ra­zio­ne in serie dei dati

Se da un lato non tutte le al­ter­na­ti­ve a Ku­ber­ne­tes fanno al­tret­tan­to, dall’altro molte di loro offrono fun­zio­na­li­tà di cui Ku­ber­ne­tes non dispone. Tra quelle più ap­prez­za­te si an­no­ve­ra­no so­prat­tut­to le co­sid­det­te funzioni comfort relative all’am­mi­ni­stra­zio­ne degli utenti, al mo­ni­to­rag­gio e alla sicurezza. Cio­no­no­stan­te, alcune delle al­ter­na­ti­ve sono comunque basate su Ku­ber­ne­tes, mentre altre possono invece essere usate in com­bi­na­zio­ne con Ku­ber­ne­tes. Diamo dunque un’occhiata agli aspetti più im­por­tan­ti di Ku­ber­ne­tes e delle sue al­ter­na­ti­ve.

Nell’am­mi­ni­stra­zio­ne dei cluster e dei container esistono approcci dif­fe­ren­ti. I parametri di utilizzo de­scri­vo­no come le risorse vengano assegnate e gestite. Inoltre, servono a stabilire quali sono gli ambienti adatti per i vari sistemi e quali tipi di ap­pli­ca­zio­ne possono essere adoperati:

Am­mi­ni­stra­re un cluster di container so­li­ta­men­te non basta. Un cluster risulta fun­zio­na­le, quindi utile, soltanto se si svolgono anche altre ope­ra­zio­ni:

Sia Ku­ber­ne­tes che le al­ter­na­ti­ve sono un software per la gestione di cluster di­stri­bui­ti. Ci sono diversi approcci per strut­tu­ra­re un sistema di questo tipo. Qui di seguito vi mostriamo i punti prin­ci­pa­li:

Sul mercato sono presenti una serie di sistemi che offrono delle capacità com­pa­ra­bi­li a quelle di Ku­ber­ne­tes. Le abbiamo suddivise in tre classi prin­ci­pa­li:

Dopodiché ci sono al­ter­na­ti­ve a Ku­ber­ne­tes come Apache Mesos e Azk, che non rientrano in nessuna delle tre classi sopra descritte. Quelli di seguito elencati sono i sistemi che con­fron­te­re­mo a Ku­ber­ne­tes:

• Docker Swarm
• Apache Mesos
• AWS Fargate
• OpenShift
• Rancher
• Nomad
• Azk

Iniziamo con una breve pa­no­ra­mi­ca su Ku­be­re­ne­tes.

Ku­ber­ne­tes consente l’ese­cu­zio­ne e l’or­che­stra­zio­ne di cluster di ap­pli­ca­zio­ni con­tai­ne­riz­za­te. La gamma di funzioni include la gestione del cluster, la pia­ni­fi­ca­zio­ne, il ri­le­va­men­to dei servizi, il mo­ni­to­rag­gio e il secrets ma­na­ge­ment. Con Ku­ber­ne­tes possono essere rea­liz­za­ti cluster con fino a 5.000 nodi e 300.000 container. Svi­lup­pa­to ori­gi­na­ria­men­te da Google, il software oggi è pa­tro­ci­na­to dalla Cloud Native Computing Foun­da­tion (CNCF). Al suo continuo sviluppo oltre al gigante Google par­te­ci­pa­no anche Red Hat, Docker e IBM.

Le im­ple­men­ta­zio­ni di Ku­ber­ne­tes come standard ri­guar­da­no le in­fra­strut­tu­re di cloud pubblico dei grandi provider. Nuovi sviluppi e strumenti vengono forniti con­ti­nua­men­te come “minikube”, “kubeadm” e “K3s” e servono a rendere di­spo­ni­bi­li delle funzioni comfort, a sem­pli­fi­ca­re l’in­stal­la­zio­ne e l’am­mi­ni­stra­zio­ne di Ku­ber­ne­tes, oltre che a rendere il software fun­zio­nan­te anche su hardware meno potenti.

Il grande svan­tag­gio di Ku­ber­ne­tes sta nella com­ples­si­tà del software. L’in­stal­la­zio­ne completa di Ku­ber­ne­tes comprende circa mezza dozzina di servizi che in­te­ra­gi­sco­no fra loro. La con­fi­gu­ra­zio­ne richiede un certo impegno e la corretta ese­cu­zio­ne del software pesa alquanto sulle risorse.

Kubernets viene uti­liz­za­to per progetti di big data e machine learning, che ri­chie­do­no un eco­si­ste­ma Ku­ber­ne­tes o le chart di Helm. Per via della com­ples­si­tà del software, Ku­ber­ne­tes risulta per lo più adatto a grandi progetti con durata plu­rien­na­le e un budget suf­fi­cien­te. La sua in­stal­la­zio­ne richiede un team di lavoro dedicato a tempo pieno. In al­ter­na­ti­va ci sono delle offerte Ku­ber­ne­tes gestite da terzi all’interno di un’in­fra­strut­tu­ra di cloud pubblico.

Docker Swarm è lo strumento per l’or­che­stra­zio­ne di cluster basato sul motore di Docker e svi­lup­pa­to dall’azienda omonima. Uno swarm cluster consiste di swarm manager node, che or­che­stra­no e ge­sti­sco­no il cluster, e di worker node. Questi ultimi ricevono gli incarichi trasmessi dai manager node.

Il più grande vantaggio di Docker Swarm sta nella forte in­te­gra­zio­ne del software all’interno dell’eco­si­ste­ma Docker. Una volta in­stal­la­to il motore Docker si può usare anche Docker Swarm. Per la gestione si utilizza la celebre in­ter­fac­cia a riga di comando di Docker. Docker Swarm in­te­ra­gi­sce con le fun­zio­na­li­tà di Docker e Docker Compose at­tra­ver­so l’apposita API Swarm. Il software supporta la sca­la­bi­li­tà, la ri­par­ti­zio­ne dei carichi, il ri­le­va­men­to dei servizi e le reti multi-host.

A confronto diretto con Ku­ber­ne­tes, Docker Swarm offre meno pos­si­bi­li­tà di adat­ta­men­to e meno esten­sio­ni. In generale possiamo dire che la gamma di funzioni è ridotta.

Docker Swarm risulta molto adatto per l’ela­bo­ra­zio­ne di carichi di lavoro ridotti rispetto a Ku­ber­ne­tes. Se si dispone già di un ambiente Docker, allora uti­liz­za­re Docker Swarm per l’or­che­stra­zio­ne di cluster di container diventa facile.

Il progetto Apache Mesos segue gli stessi principi del kernel di Linux, no­no­stan­te l’im­ple­men­ta­zio­ne avvenga a un livello di astra­zio­ne dif­fe­ren­te. Il kernel Mesos viene eseguito su ogni macchina del cluster e mette a di­spo­si­zio­ne API per ap­pli­ca­zio­ni come Hadoop, Spark, Kafka ed Ela­stic­search. Mesos permette di eseguire in modo di­stri­bui­to la gestione e la pia­ni­fi­ca­zio­ne delle risorse at­tra­ver­so data center e ambienti cloud.

Con Apache Mesos le risorse di calcolo come CPU, RAM e spazio di ar­chi­via­zio­ne vengono astratte dalle effettive macchine. In questo modo i cluster possono essere scalati nell’ordine di decine di migliaia di nodi. Per farlo vengono impiegati nodi manager e nodi agente ri­don­dan­ti e tol­le­ran­ti agli errori, i quali all’evenienza vengono ag­gior­na­ti senza in­ter­ru­zio­ne del servizio. All’interno di un cluster, le ap­pli­ca­zio­ni cloud native e legacy sono gestite fianco a fianco. Il software opera su Linux, macOS e Windows e contiene un’in­ter­fac­cia web per la gestione di cluster e container.

Mesos è pensato per sistemi con molti cluster e per un’elevata sca­la­bi­li­tà. Il software adopera un grado di astra­zio­ne minore rispetto a Ku­ber­ne­tes. Per questo motivo l’impiego del software risulta meno adatto per i cluster di piccole di­men­sio­ni con meno di una dozzina di nodi.

Con Apache Mesos è possibile costruire sistemi di­stri­bui­ti elastici e tol­le­ran­ti agli errori. Il software è adatto per grandi sistemi, pensati per disporre della massima ri­don­dan­za.

AWS Fargate è un motore di calcolo ser­ver­less (senza server) per container basato sul modello Container as a Service. Sce­glien­do Fargate il focus è sulle ap­pli­ca­zio­ni invece che sull’in­fra­strut­tu­ra. Per un’ap­pli­ca­zio­ne con­tai­ne­riz­za­ta si sta­bi­li­sco­no i requisiti di rete, lo spazio di ar­chi­via­zio­ne, la sca­la­bi­li­tà e così via. Fargate si occupa della gestione delle risorse ne­ces­sa­rie. Per farlo il software si affida alle tec­no­lo­gie Amazon Elastic Container Service (ECS) e Amazon Elastic Ku­ber­ne­tes Service (EKS), sempre di proprietà di Amazon.

Il prin­ci­pa­le punto a favore di AWS Fargate è il deciso orien­ta­men­to verso le ap­pli­ca­zio­ni. Non essendo ne­ces­sa­rio occuparsi dell’in­fra­strut­tu­ra, viene meno l’overhead e quindi l’am­mi­ni­stra­zio­ne e la sca­la­bi­li­tà del server. Fargate scala le risorse in maniera elastica, così da evitare di dover uti­liz­za­re più risorse del ne­ces­sa­rio per i picchi di utilizzo. Si pagano soltanto le risorse di calcolo ef­fet­ti­va­men­te uti­liz­za­te. Fargate vanta un elevato grado di sicurezza grazie all’iso­la­men­to integrale dell’ap­pli­ca­zio­ne.

AWS Fargate rende con­for­te­vo­le l’utilizzo di Ku­ber­ne­tes. Tuttavia, questo può anche portare a costi piuttosto elevati. Inoltre, la pro­te­zio­ne dell’utente dalla tec­no­lo­gia alla base del software riduce le pos­si­bi­li­tà di controllo e di scelta.

Con AWS Fargate possono essere im­ple­men­ta­te ap­pli­ca­zio­ni, API, ar­chi­tet­tu­re di mi­cro­ser­vi­zi e l’ela­bo­ra­zio­ne in serie dei dati. Fargate esegue ap­pli­ca­zio­ni con­tai­ne­riz­za­te, sca­lan­do­le in base alle necessità. Il software trova anche impiego nell’al­le­na­men­to dell’in­tel­li­gen­za ar­ti­fi­cia­le e dell’ap­pren­di­men­to au­to­ma­ti­co.

La piat­ta­for­ma OpenShift svi­lup­pa­ta da Red Hat è basata su Ku­ber­ne­tes. Consente l’or­che­stra­zio­ne di container e reti, per­met­ten­do la pia­ni­fi­ca­zio­ne e la gestione di risorse scalabili e di­stri­bui­te. Il software può essere usato su più ambienti cloud, tra i quali anche cloud privati con una propria in­fra­strut­tu­ra di calcolo, o le in­fra­strut­tu­re cloud di Amazon AWS e Microsoft Azure.

Oltre allo strumento a riga di comando, OpenShift dispone anche di un’in­ter­fac­cia web per la gestione delle varie fun­zio­na­li­tà. Ado­pe­ran­do il modello GitOps, gli svi­lup­pa­to­ri sono tenuti a mantenere l’intera con­fi­gu­ra­zio­ne sotto forma di codice. No­no­stan­te la so­mi­glian­za del nome, OpenShift non ha nulla a che vedere con la tec­no­lo­gia OpenStack.

Il prin­ci­pa­le vantaggio di OpenShift è quello di poter dare ai team di sviluppo un ambiente di lavoro fun­zio­na­le e potente. In­di­pen­den­te­men­te dall’ambiente uti­liz­za­to (cloud pubblico, privato o ibrido), gli svi­lup­pa­to­ri possono contare sugli stessi approcci per co­stru­zio­ne, test e gestione delle ap­pli­ca­zio­ni. In modo par­ti­co­la­re le OpenShift Pipelines sono una soluzione per lo sviluppo continuo (Con­ti­nuous De­ve­lo­p­ment).

Un ulteriore punto di forza di OpenShift sono gli strumenti integrati di mo­ni­to­rag­gio e di accesso. Tra questi vi è Pro­me­theus per la gestione del mo­ni­to­rag­gio e delle notifiche, Jaeger per il trac­cia­men­to delle tran­sa­zio­ni, Kali per le in­ter­fac­ce e per la vi­sua­liz­za­zio­ne e Istion per l’im­ple­men­ta­zio­ne di ar­chi­tet­tu­re di­stri­bui­te di mi­cro­ser­vi­zi. Inoltre, OpenShift ricorre a Red Hat Container Catalog, con­te­nen­te le immagini container testate e cer­ti­fi­ca­te da Red Hat.

Così come avviene per tanti altri prodotti svi­lup­pa­ti da Red Hat, OpenShift punta sulla di­stri­bu­zio­ne com­mer­cia­le di Linux che prende il nome di Red Hat En­ter­pri­se Linux (RHEL). La di­pen­den­za da questo sistema operativo porta però a una classica si­tua­zio­ne di vendor lock-in.

OpenShift risulta par­ti­co­lar­men­te adatto per la messa in pratica di strategie che com­pren­do­no un cloud ibrido e per rea­liz­za­re e scalare le ap­pli­ca­zio­ni con­tai­ne­riz­za­te ne­ces­sa­rie. Le or­ga­niz­za­zio­ni che si affidano già all’eco­si­ste­ma Red Hat traggono par­ti­co­la­re vantaggio dall’utilizzo del software.

Rancher è un’altra al­ter­na­ti­va basata su Ku­ber­ne­tes. Rap­pre­sen­ta uno strumento completo per i team di lavoro che puntano sui container, pensato per le sfide operative e in materia di sicurezza che ci si trova ad af­fron­ta­re nella gestione di diversi cluster Ku­ber­ne­tes. Rancher mette a di­spo­si­zio­ne dei team DevOps un’in­ter­fac­cia di controllo cen­tra­liz­za­ta e sem­pli­fi­ca la gestione di tutti i cluster Ku­ber­ne­tes dell’or­ga­niz­za­zio­ne. Il pro­vi­sio­ning di un cluster, gli ag­gior­na­men­ti, così come la gestione degli utenti e delle regole (policy ma­na­ge­ment) sono incluse nella gamma di funzioni del software.

Rancher sem­pli­fi­ca il de­ploy­ment dei cluster Ku­ber­ne­tes con le macchine fisiche, così come su ambienti cloud sia privati che pubblici. I cluster sono protetti grazie alle norme di sicurezza globali: vengono uti­liz­za­ti sistemi cen­tra­liz­za­ti per l’au­ten­ti­ca­zio­ne, il controllo degli accessi e la trac­cia­bi­li­tà. Il software previene gli errori legati ai cluster e, se ne­ces­sa­rio, esegue delle misure di sal­va­tag­gio e ri­pri­sti­no.

Rancher funziona con diverse di­stri­bu­zio­ni Linux e Ku­ber­ne­tes, evitando così che l’utente si ritrovi in una si­tua­zio­ne di co­sid­det­to vendor lock-in, ossia di di­pen­den­za. Per quanto riguarda le funzioni comfort, sono presenti l’Active Directory, il supporto LDAP e SAML, nonché il pro­vi­sio­ning del DNS.

In confronto a Ku­ber­ne­tes, la comunità attorno a Rancher è si­gni­fi­ca­ti­va­men­te più piccola. Inoltre, il software funziona soltanto con sistema operativo Linux.

Rancher risulta molto adatto a gestire diversi cluster Ku­ber­ne­tes da una singola in­ter­fac­cia cen­tra­liz­za­ta che permette di assegnare permessi utente su diversi cluster.

Nomad rap­pre­sen­ta un in­te­res­san­te strumento per la gestione e la pia­ni­fi­ca­zio­ne dei cluster, svi­lup­pa­to da HashiCorp. Il software può essere uti­liz­za­to sia in con­nes­sio­ne con Ku­ber­ne­tes che come al­ter­na­ti­va autonoma. Nomad fa parte dell’offerta di software per cloud e pro­vi­sio­ning di HashiCorp. Seguendo la filosofia Unix, l’azienda pre­fe­ri­sce un approccio modulare dove ogni strumento svolge una funzione ben definita. Ad esempio, Terraform per l’In­fra­struc­tu­re as Code (IaC), Consul per la Service Discovery e Vault per il secrets ma­na­ge­ment.

Oltre alle classiche ap­pli­ca­zio­ni con­tai­ne­riz­za­te, Nomad supporta anche ap­pli­ca­zio­ni vir­tua­liz­za­te e “stan­da­lo­ne” tra­di­zio­na­li. Di­ver­sa­men­te da Ku­ber­ne­tes, Nomad non è composto da com­po­nen­ti di sistema integrate tra di loro. Piuttosto, il software si presenta sotto forma di un singolo file binario di piccole di­men­sio­ni e viene di­stri­bui­to negli ambienti di sviluppo e cloud locali, così come nei data center sia privati che pubblici.

In­di­pen­den­te­men­te dall’ambiente nel quale viene uti­liz­za­to, Nomad offre sempre lo stesso comfort operativo. Con il software possono essere di­stri­bui­ti cluster con decine di migliaia di nodi su più zone di di­spo­ni­bi­li­tà, regioni e data center. Anche i multi-cluster de­ploy­ment rientrano nelle funzioni di­spo­ni­bi­li.

Poiché Nomad è stato svi­lup­pa­to re­la­ti­va­men­te di recente, l’eco­si­ste­ma è ancora molto poco definito rispetto a Ku­ber­ne­tes. Per questo motivo non esistono soluzioni Nomad gestite da parte dei prin­ci­pa­li provider di servizi cloud.

Nomad è molto adatto per i team di lavoro di piccole e medie di­men­sio­ni ai quali mancano le capacità per gestire un software di or­che­stra­zio­ne complesso. Inoltre, conviene uti­liz­za­re Nomad se si decide di ricorrere ad ap­pli­ca­zio­ni sia con­tai­ne­riz­za­te che non (Windows, Java). La sem­pli­ci­tà del software permette a chi lo usa di muoversi ra­pi­da­men­te e reagire pron­ta­men­te alle mutevoli esigenze della propria attività.

Con Azk gli svi­lup­pa­to­ri possono usufruire di una buona al­ter­na­ti­va a Ku­ber­ne­tes. Questo strumento viene in­stal­la­to in locale e permette l’or­che­stra­zio­ne degli ambienti di sviluppo sulla propria macchina. Azk offre un’in­ter­fac­cia a riga di comando e per ogni nuovo progetto crea un apposito file di con­fi­gu­ra­zio­ne (chiamato Azkfile.js) che serve a definire l’ambiente di sviluppo. Sono incluse anche le immagini container di Docker, le im­po­sta­zio­ni di rete e dei di­spo­si­ti­vi di ar­chi­via­zio­ne di massa, così come le variabili am­bien­ta­li uti­liz­za­te.

Il maggiore vantaggio di Azk è quello di sem­pli­fi­ca­re l’im­po­sta­zio­ne degli ambienti di sviluppo locali agli svi­lup­pa­to­ri. Oltre al re­po­si­to­ry centrale, con­te­nen­te le immagini e i sistemi uti­liz­za­ti più spesso, anche il formato Azkfile con­tri­bui­sce a una buona espe­rien­za utente. Un Azkfile è creato in un dialetto Ja­va­Script di facile com­pren­sio­ne e su cui si basa l’ambiente di sviluppo locale. Inoltre, Azk offre la pos­si­bi­li­tà di generare au­to­ma­ti­ca­men­te un Azkfile con poche e semplici in­di­ca­zio­ni.

Poiché Azk si rivolge agli svi­lup­pa­to­ri web di pro­fes­sio­ne, Windows non è sup­por­ta­to.

Azk serve prin­ci­pal­men­te ad au­to­ma­tiz­za­re l’in­stal­la­zio­ne e l’or­che­stra­zio­ne degli ambienti di sviluppo. In modo tale che un team possa definire degli ambienti fun­zio­na­li per diversi progetti.