L’evoluzione delle architetture ed il cloud

Negli ultimi anni, stiamo assistendo ad una vera e propria rivoluzione nell’ambito della gestione di applicazioni ed infrastruttura in ambito Enterprise.

Sempre più aziende, di qualsiasi dimensione, stanno iniziando a muovere i propri passi verso il Cloud, e sempre più provider stanno combattendo la loro battaglia per accaparrarsi, con portfolio di servizi sempre più ampi ed offerte sempre più vantaggiose, porzioni sempre più ampie di mercato.

Ed ecco così nascere servizi ed opzioni sempre più a misura di utilizzatore, si è passati infatti dalle singole macchine fisiche all’interno dei data center, ad istanze create on demand e ritagliate per le necessità della singola azienda o utente.

In un contesto così dinamico ed in continua evoluzione, abbiamo assistito all’introduzione di concetti come IaaS (Infrastructure As A Service), PaaS (Platform As A Service), e più in generale del modello ‘As A Service’, ovvero il considerare le risorse computazionali, l’infrastruttura ed in alcuni casi lo stesso software, come servizi, ovvero qualcosa che viene pagato in base al proprio utilizzo.

In quest’ottica, i maggiori vendor di soluzioni infrastrutturali ed applicative hanno iniziato a strizzare l’occhio ai maggiori Cloud provider (AWS, Google Cloud, Azure), mettendo a disposizione degli utenti metodi di deploy, installazione e configurazione dei propri prodotti e servizi, certificati e compatibili con essi, spesso anche nell’ambito di una collaborazione diretta con i vendor.

L’avanzata senza precedenti dello sviluppo di architetture basate su microservizi, con la relativa diffusione a macchia d’olio della tecnologia dei containers a seguito dell’introduzione della tecnologia dei container in Linux e successivamente di Docker, hanno portato ad una sempre più frequente richiesta di soluzioni di computing versatili ed il più portabili possibile dove riuscire a deployare le proprie applicazioni. 

In ambienti enterprise, l’incremento dell’adozione dei container ha portato alla necessità di utilizzare degli orchestrator, che si configurano come punto di gestione ed orchestrazione di containers e tutte le componenti infrastrutturali necessarie al loro funzionamento ed all’integrazione con elementi pre-esistenti.

Kubernetes e Red Hat Openshift Container Platform

Kubernetes, fin dalla sua introduzione, ha ottenuto sempre più consensi, diventando con il tempo lo standard de facto per l’orchestrazione di containers, rendendo fattibile l’integrazione di applicazioni complesse all’interno di un contesto basato sulla containerizzazione, supportando e coadiuvando la loro migrazione ad una architettura a microservizi.

All’interno di Kubernetes, infatti, vengono gestiti anche tutti gli aspetti infrastrutturali dell’integrazione tra i vari container e relative risorse, curando gli aspetti di:

• Networking
• Isolamento
• Scalabilità
• Controllo

Sulle solide basi gettate da Kubernetes, seguito con interesse fin dalle prime release nel 2015, con Openshift, Red Hat ha iniziato ad aggiungere, in maniera modulare, funzionalità, andando anche in alcuni casi a migliorare quelli che sono gli aspetti implementativi, soprattutto a livello di sicurezza, integrazione, strumenti di sviluppo e supporto, pur mantenendo la compatibilità con l’upstream (https://github.com/cncf/k8s-conformance/tree/master/v1.18/openshift)..

Vengono infatti introdotti in Openshift degli strumenti che vanno oltre la realizzazione dell’infrastruttura di orchestrazione, andando a coprire aspetti fortemente ispirati alla metodologia DevOps, tra i quali:

• Gestione del ciclo di vita della build del software (Source to Image – S2I)
• Gestione del ciclo di vita del deploy delle applicazioni (Rollout, rollback, hook pre/post deploy, strategie di deploy Blue/Green, A/B Testing)
• Integrazione di pipeline di Continous Integration/Continous Delivery
• Strumenti dedicati per gli sviluppatori, integrazione con VSCode, CodeReady Workspaces, un cloud IDE su misura per applicazioni da portare in Openshift.
• Gestione del ciclo di vita degli Operators (Operator Lifecycle Manager)
• Kubernetes native pipelines (Tekton)
• Serverless e FaaS (Knative)
• Monitoring & Logging
• Network plugin per gestire in maniera puntuale l’isolamento tra i progetti, per una reale multitenancy.

Le funzionalità aggiuntive, unite alla semplicità di utilizzo ed alla ricchezza di documentazione, ha fatto in modo che Openshift fosse riconosciuto come la distribuzione  ‘Enterprise’ di Kubernetes per eccellenza, di cui, di fatto, va ad estendere le già solide basi.

Red Hat Openshift vs xKS 

Provisioning ed installazione

On Premise

Abbiamo anticipato alcune delle funzionalità caratteristiche di Openshift, ma una particolare nota di merito dovrebbe essere spesa per parlare dell’installer.

L’installazione di Openshift a partire dalla versione 4.0 è stata resa molto più semplice ed intuitiva, grazie ad un installer, perfettamente integrato per supportare il setup, oltre che on premise, anche sui principali cloud provider.

Una installazione di base richiede all’utente un set di parametri minimi all’interno di un file di configurazione, che l’installer utilizzerà per creare le risorse necessarie alla preparazione dell’ambiente.

In un’installazione On Premise l’utente ha il pieno controllo della gestione infrastrutturale e dei singoli nodi, compresi quelli del control plane, e sarà l’unico responsabile del provisioning infrastrutturale, dalle VM, ai load balancer, ai server DNS/DHCP.

Per quanto riguarda Openshift, i nodi master che ospitano il control plane saranno basati su Red Hat CoreOS, e la loro gestione e manutenzione sarà principalmente eseguita da cluster operators, come ad esempio il machine-config-operator, che si occuperà di interagire con il sistema operativo e garantire che vengano applicate le configurazioni, definite all’interno di risorse dedicate in Openshift, oltre a curarne gli aspetti di aggiornamento, sempre attraverso un operator dedicato.

Al termine dell’installazione, la piattaforma sarà completamente utilizzabile, con tutti gli strumenti menzionati in precedenza.

Per quanto riguarda Kubernetes, l’installazione on premise è generalmente gestita attraverso un tool di bootstrap, kubeadm, che si occupa del provisioning del nostro control plane ed eseguire le configurazioni di base sui nostri nodi. I nodi worker verranno aggiunti in seguito sulla base di un cluster ID che viene fornito in fase di installazione.

Una volta terminata l’installazione di un cluster Kubernetes (k8s), l’utente dovrà provvedere in autonomia ad integrarla con gli strumenti necessari, secondo le proprie necessità.

Managed & Full Managed

E’ bene fin da subito distinguere le tipologie di installazione che è possibile avere nel ‘cloud’.

Abbiamo infatti tre macro categorie:

Le installazioni Unmanaged, dove l’utente installa il cluster, Openshift o Kubernetes, manualmente utilizzando l’installer su una infrastruttura, il cui provisioning avviene in due relative modalità:

• UPI (User provided infrastructure) 

L’utente crea e gestisce l’infrastruttura che ospiterà il cluster

• IPI (Installer provided infrastructure) 

L’installer Openshift si occupa di gestire il provisioning dell’infrastruttura interfacciandosi direttamente con le API del cloud provider

Questa installazione può avvenire on premise (bare metal, legacy virtualization) o sul cloud provider di riferimento, pubblico o privato.

Le installazioni Managed, dove il cloud provider si fa carico di eseguire il provisioning e la gestione dei soli nodi del control plane, lasciando quindi all’utente l’onere di gestire i nodi worker ed i relativi aggiornamenti/monitoring, che si traduce molto spesso nella necessità di usufruire di servizi aggiuntivi, solitamente a pagamento, per poter avere una installazione completa.

C’è poi una gestione Full Managed, dove il cloud provider si occupa di gestire il provisioning, il monitoraggio e la gestione anche dei nodi worker, oltre al control plane ed all’infrastruttura.

Nel caso di un’installazione su Cloud provider, per semplificare la procedura di installazione, l’installer Openshift andrà ad interfacciarsi direttamente con le API dei principali Cloud providers, per andare ad eseguire il provisioning delle risorse necessarie al setup.

Alcuni Cloud Provider come ad esempio Amazon Web Services ed Azure, negli ultimi mesi hanno collaborato con Red Hat per fornire ai propri clienti installazioni Managed e Full Managed di Openshift, ossia installazioni che si fanno carico di preparare e fornire all’utente la soluzione, ‘chiavi in mano’, curando tutti gli aspetti di approvvigionamento, sia di macchine che di infrastruttura, e la loro manutenzione.

Inoltre, la procedura di setup è ampiamente semplificata, essendo completamente automatizzata, il che permette all’utente di rendere operativo il suo ambiente con un click.

Un approccio simile in realtà è stato affrontato anche per l’integrazione di Kubernetes all’interno di contesti Cloud, abbiamo infatti:

GKE – Google Kubernetes Engine (Google Cloud)

AKS – Azure Kubernetes Services (Microsoft Azure) 

EKS – Elastic Kubernetes Services (AWS)

Tutti questi servizi permettono infatti di avere in pochi minuti una installazione Kubernetes attiva e funzionante, utilizzando istanze con provisioning di VM ‘al volo’ all’interno del cloud provider, e richiedendo all’utente un minimo di informazioni iniziali (nome del cluster, dimensione delle istanze, il numero di nodi e metodi di accesso).

Ma attenzione, molti dei servizi di cui stiamo parlando curano esclusivamente la parte di provisioning e gestione del control plane, ovvero dei nodi che vanno a comporre quella che è l’infrastruttura di base di Kubernetes, dove viene eseguito il deploy dei componenti di base:

• kube-api-server
• kube-controller
• kube-scheduler
• etcd

Questo, nella pratica, prendendo ad esempio come spunto l’infografica che viene riportata per il servizio AKS di Azure, ci fa capire che l’utente dovrà farsi carico del provisioning e della gestione dei nodi di calcolo all’interno della piattaforma Azure.

Questa è una delle prime differenze tra i servizi di questo tipo ed il servizio, ad esempio Full Managed offerto da Azure ed AWS, dove l’utente deve esclusivamente preoccuparsi di creare le proprie applicazioni, senza preoccuparsi di update dei nodi, monitoraggio, ecc.

Gestione del cluster

Chiarito quello che è l’aspetto prettamente di setup, il prodotto che ci troveremo a dover gestire in realtà differisce anche sotto al punto di vista della gestione.

Ad esempio il monitoraggio del nostro cluster, mentre risulta essere incluso all’interno di Openshift Container Platform, non risulta invece presente di default in Kubernetes, ma può essere, ad esempio, aggiunto come servizio offerto dal cloud provider con un pricing separato, mentre dovrà essere installato manualmente, spesso con progetti supportati esclusivamente dalla community, dall’utente nel caso di un’installazione totalmente on premise (bare metal o virtuale).

Sempre in ambito cloud, i nodi, ad esempio nel caso di AKS, sono basati su Ubuntu, mentre in OCP viene utilizzata Red Hat CoreOS, distribuzione certificata ed ottimizzata per l’utilizzo in ambiente container orchestration, garantendo quindi un livello di servizio e di supporto superiore.

Richiamando la possibilità di gestire aggiornamenti e configurazioni all’interno del cluster OCP dei nodi sottostanti, nel caso di un’installazione bare metal, ad esempio, l’utente non dovrà più preoccuparsi di avere sistemi disallineati o non aggiornati.

I servizi Kubernetes su cloud provider, inoltre, sono appunto SERVIZI, esattamente come una istanza, uno storage, ed in tutti i casi è prevista un’interazione attraverso CLI (Command line interface) esterne dedicate:

• az nel caso di Azure
• gcloud nel caso di Google Cloud
• aws nel caso di Amazon Web Services)

Questo si traduce nella necessità, da parte di chi si orienta verso questi servizi, di formarsi, studiare ed eventualmente richiedere supporto oltre che per la gestione del cluster in sé, ma anche per poter interagire con l’ecosistema che lo ospita.

Inoltre, la necessità di utilizzare uno strumento proprietario per poter gestire il cluster, di fatto si configura come un vendor lock-in.

In Openshift, invece, tutte le azioni relative al cluster, compreso l’eventuale scaling che coinvolga anche risorse computazionali, nel caso di installazione su cloud provider, verranno gestite attraverso la CLI dedicata, oc, che di fatto è una versione estesa dell’utility Kubernetes kubectl, e per quanto riguarda le funzioni di base, non esclusive di Openshift, sono completamente intercambiabili.

Costi

Un punto importante quando si valuta la possibilità di utilizzare il Cloud come risorsa per il proprio business è quello di valutare ed essere perfettamente a conoscenza dei costi e delle risorse necessarie a servire il nostro cluster.

L’adozione di una soluzione come Openshift permette, sia nella versione puramente cloud, sia nella versione Fully Managed sui cloud provider, di avere il controllo sui costi della piattaforma.

Essi infatti si riferiscono alle risorse che effettivamente vanno a comporre il nostro cluster, con la possibilità di avere delle stime sulla base dell’utilizzo effettivo.

Per quanto riguarda invece l’installazione On Premise, al termine della prova di 60 giorni è prevista una subscription.

Un altro aspetto da considerare è la necessità di formazione, i costi per la consulenza ed il supporto sulla piattaforma che andrà ad ospitare il nostro cluster. 

Come abbiamo detto, la gestione da parte del cloud provider è limitata al control plane Kubernetes ed alle risorse ad esso collegate, mentre eventuali integrazioni con altri servizi o il semplice utilizzo degli strumenti messi a disposizione del provider necessitano di essere conosciuti.

In alcuni casi, gli strumenti da utilizzare all’interno del cloud provider (strumenti di CI/CD, gestione del codice, storage) non sono di immediata comprensione, e necessitano di un supporto, aggiuntivo, ad esempio da parte di esperti della piattaforma.

Inoltre, per cercare di aggiungere funzionalità al motore Kubernetes, sarà necessario aggiungere servizi, che ad esempio nel caso di AKS, GCP, o AWS si configurano come servizi, alcuni gratuiti, altri a pagamento ma in generale basati su soluzioni del cloud provider stesso, non necessariamente open source.

La documentazione di Openshift ed il supporto di Red Hat, sono l’unica risorsa necessaria, sia per l’installazione su cloud provider di un cluster, sia per l’utilizzo di servizi fully managed, come Openshift Online, Azure Red Hat Openshift o AWS Openshift. 

Tale supporto copre sia le funzionalità strettamente legate ad Openshift, sia la gestione di ciò che è prettamente legato al suo motore, Kubernetes.

Le installazioni Kubernetes, anche se automatizzate da processi messi a disposizione dal cloud provider, possono contare dell’esclusivo supporto della community, seppur molto attivo, e dell’intervento di partner certificati per il supporto operativo, oltre al supporto del cloud provider per eventuali problemi a livello di infrastruttura.

Funzionalità

Come anticipato prima, Openshift mette a disposizione dell’utente, out of the box, funzionalità per sviluppatori e per la gestione del ciclo di vita applicativo, oltre al monitoraggio del cluster, dei nodi e del loro contenuto.

Di base, in sostanza, attraverso una installazione Kubernetes pura, per fare un paragone con il mondo automobilistico, avremo a disposizione un motore completamente funzionante, ed avremo accesso alle singole parti del resto del veicolo, che dovremo andare ad assemblare e rendere funzionanti, con relativo investimento di tempo e budget, spesso sproporzionati rispetto all’adozione di una soluzione già completa.

Con un prodotto come Openshift, infatti, avremo fin da subito un’automobile in grado di permetterci di viaggiare, senza però toglierci il gusto di poter fare del ‘tuning’, ma che dovremo fare solo se decidessimo di farlo.

In ambito sicurezza, l’utilizzo di un sistema Red Hat Linux come base per i nodi Openshift garantisce l’implementazione di policy SELinux, l’implementazione degli SCC (Security context contraints) per la gestione dei confini applicativi dei singoli container, inibendo ad esempio di default la possibilità di eseguire container con utenza di root.

Inoltre, vi è la possibilità di utilizzare diversi identity provider (htpasswd, LDAP, github, AD) permettendo di eseguire binding utente/ruolo in ogni singola istanza, mentre nei servizi Kubernetes managed viene spesso eseguito un binding con il servizio della piattaforma (ad esempio Azure AD su AKS) al quale viene anche demandata la gestione delle identità, compresa l’assegnazione dei ruoli.

Conclusioni 

In piena ottica di condivisione, è stato ritenuto utile fornire una overview di quelle che sono le sostanziali differenze tra l’adozione di una piattaforma completa come Red Hat Openshift Container Platform, e l’utilizzo di un servizio di provisioning di un cluster Kubernetes all’interno dei maggiori cloud provider al momento disponibili sul mercato.

In fase di valutazione delle soluzioni disponibili, è sempre consigliato approfondire tutti gli aspetti implementativi, rivolgendosi a personale qualificato in grado di poter identificare, evidenziare ed indirizzare quelle che sono le necessità di business e come trovare la soluzione idonea a realizzarle.

Chiarezza, competenza e concretezza devono essere le fondamenta sul quale costruire la propria infrastruttura, evitando di incorrere in sorprese o adottare soluzioni che di fatto non siano coerenti con quelle che sono le nostre aspettative, seppur superficialmente più attraenti, magari a livello di pricing e di promozione.

Alcuni link utili:

Red Hat OCP Documentation 

Azure Red Hat Openshift Documentation

Openshift Dedicated Documentation