No results found
VMware è probabilmente la soluzione più nota di virtualizzazione e permette di implementare macchine virtuali sia su server fisici che su infrastrutture Cloud; con gli anni e con lo sviluppo che la tecnica dei container ha avuto, anche VMware, a partire dal 2015 è gradualmente entrata nel cosiddetto “container Space”.
I container rappresentano oggi e saranno sempre più in futuro, l’architettura di riferimento e, semplificando molto, possono essere definiti come macchine virtuali molto più semplici da gestire, isolate e snelle, idealmente finalizzate ad eseguire un’applicazione. Un’architettura basata su container non si può considerare tale senza un gestore, ovvero un orchestratore e oggi quello che va per la maggiore è indubbiamente Kubernetes.
In questo tutorial esporremo l’evoluzione che VMware ha compiuto fino ad approdare all’universo dei container, con riferimento a tutto ciò che fa da contorno, a vSphere e a Kubernetes.
Nel 2015 VMware annuncia due progetti molto importanti che sono il Photon OS e il Directory Services basati su LightWave; si tratta di progetti che rilascia Open Source; in realtà da qui in avanti molte aziende rilasceranno soluzioni Open Source, perché lo sviluppo del core di molti progetti richiede uno sforzo notevole e se si rende Open Source un software e si mette il codice a disposizione della community, si può sfruttare il lavoro di quest’ultima per migliorarlo e avere gli elementi necessari per sviluppare versioni funzionali.
VMware entra anch’essa in questo “giro” con due progetti, uno dei quali -Photon OS- è un sistema operativo che nasce per come sistema operativo minimale, con un footprint molto piccolo per poter far girare su qualcosa di nuovo, ossia il Container Engine. Il secondo progetto è Directory Services, che serve un po’ per tutto il coordinamento, lo scambio dei certificati e tutto ciò che riguarda un po' la gestione di varie istanze di Photon OS.
Sempre nel 2015 parte il progetto Bonneville che praticamente porterà a quello che si chiama vSphere Integrated Containers e sempre nel 2015 VMware entra in un consorzio che è la Cloud Native computing Foundation, ossia una fondazione nella quale atterrano molti progetti, il più interessante dei quali era proprio quello di Kubernetes.
Oggi le aziende che entrano in questo “giro” si “accreditano” come realtà nelle quali è possibile eseguire dei workload che sono compatibili con questo standard, ossia quello stabilito dalla Cloud Native Computing Foundation. Docker è una di esse.
Nel 2016 parte il progetto Admiral, che sarebbe è il primo elemento a livello di interfaccia di gestione dei container e di gestione del primi cicli di vita del software a container; qui passiamo dall’applicazione tradizionale al container.
Siamo alle origini e si tratta ancora di progetti Open Source, accanto ai quali sorge la prima IUI che si chiama Project Admiral.
Da qui in avanti si susseguono altri rilasci paralleli, come ad esempio quello di vSphere.
Oggi si sta verificando un cambio generazionale anche per tutto quello che riguarda il vCenter, la gestione degli host e così via.
Sta cambiando qualcosa dall’alto e dal basso: dal basso perché cambia l’hypervisor, che diventa più potente e sembra che si evolva in qualcosa di più; dall’alto cambia la modalità di interfaccia che andrà a consumare queste risorse.
Nel 2017 arriviamo a vSphere Integrated Containers; per capire di cosa si tratta va precisato che siamo abituati a vedere il container come un elemento all'interno della macchina virtuale, ossia come un’istanza isolata protetta. Ma non si tratta di una VM, perché è un qualcosa che si esegue a livello di User Space e che fondamentalmente racchiude librerie e codice runtime che finisce nella cosiddetta memoria volatile e che praticamente si preoccuperà di eseguire un servizio o tutta un’applicazione.
Quindi si ha come al solito una parte di ingresso, ossia una porta d’ingresso che servirà a far fluire e comunque a elaborare un qualcosa e da cui uscirà un servizio intero.
Attenzione che in tema di container spesso si commette un errore, ma che di fatto è una modalità che oggi viene ancora accettata, ossia prendere l'applicazione tradizionale e “incapsularla” in un container: si racchiude un’applicazione tradizionale (quindi fatta per essere eseguita su una macchina fisica) la si racchiude in un container è la si fa eseguire a runtime all’interno del sistema operativo del container stesso.
Fare una cosa di questo genere è un po’ contrario alla logica odierna, perché oggi quando si va ad eseguire dei container, in realtà si vanno ad eseguire dei microservizi, ossia un qualcosa di talmente piccolo e integrato in una sorta di rete a maglia: praticamente all’interno di un sistema ancora più complesso che può essere considerato una mesh formata da altri container. Ebbene, l’applicazione finale è l’insieme di questi container.
Quindi quando si parla di container bisogna distinguere bene quelle che sono applicazioni tradizionali containerizzate dalle applicazioni formate da microservizi.
Torniamo alla cronistoria e vediamo che a un certo punto nel 2017 VMware partecipa a KubeCOM, quindi si interessa a ciò che succede nell’ambito di Kubernetes.
Attraverso PKS (Pivot Kubernetes Service) e l'integrazione con un prodotto che esce proprio nel 2017 (NSX-T) si crea un’integrazione perfetta tra l’infrastruttura sottostante (quindi le Foundation che sono vSphere e vSan) ossia la parte di hypervisor, e la parte di gestione dello storage basata su un concetto di iperconvergenza. Vicino a questo abbiamo un altro elemento molto importante che è il network. Il motivo per cui occorre integrare il network è che di fatto la gestione della comunicazione intra-container era permessa solo tramite l’utilizzo di NSX-T, sempre nell'ambito di vSphere.
Oggi per gestire la comunicazione intra-container c’è una quantità veramente ampia di soluzioni open o commerciali, cioè open gratuite o commerciali o comunque Enterprise, che ci permettono di stabilire la comunicazione tra container, ma anche di abilitare la security intra-container.
Per comprendere l’importanza di questa security va considerato che quando si è passati dalle infrastrutture Bare Metal alle infrastrutture di virtualizzazione, parallelamente all’ottimizzazione e all’efficientamento del carico di lavoro all’interno del Data Center si verificato l’aumento della superficie di attacco, perché se prima avevamo un solo sistema operativo da gestire, con la virtualizzazione abbiamo 10, 20, anche 30 sistemi operativi da gestire per unità e anche di più; infatti oggi, grazie all’incremento delle tecnologie di ripartizione di RAM, processori e così via, all’interno di un singolo server fisico possiamo anche far girare centinaia di macchine virtuali.
Ma di contro abbiamo un aumento della superficie di attacco, intendendo con ciò la quantità di elementi esposti ai cyber-attacchi, perché è aumentato quello che consideriamo il traffico est – ovest all’interno dell’infrastruttura; in pratica, mentre tradizionalmente si ritiene che gli attacchi arrivino dall’alto (quindi viaggino da nord a sud) e quindi dal firewall perimetrale verso il sistema e quindi tutta la sicurezza la si concentrava considerando quel flusso, oggi in realtà gran parte del traffico e gran parte delle violazioni avvengono dentro l’infrastruttura virtuale, quindi da macchina virtuale a macchina virtuale (in gergo, da est a ovest).
Con l’architettura a container questo fenomeno si amplifica perché una sola macchina virtuale può contenere anche 20-30 container.
Avere la parte della security gestita con NSX-T è stato un grosso passo in avanti per VMware, perché introduceva tanti prodotti e grazie alla collaborazione con pivotal è stato finalmente possibile deliverare Kubernetes in ambito vSphere.
Dopo l’integrazione con PKS, nel 2019 viene annunciato Project Pacific, cioè praticamente la fusione di componenti di Kubernetes all’interno dell’hypervisor VMware; finalmente diventa disponibile un’interfaccia, oltre all’interfaccia tradizionale e quindi alle integrazioni con vCenter, che aggiunge elementi che servono a deliverare il Cluster Kubernetes.
In breve, per iniziare a usare i Cluster Kubernetes serve un elemento (un kickstarter) che permetta di deliverare il primo Cluster Kubernetes. Dall’altra parte c’è la modalità con cui si utilizza il Cluster, quindi un’interfaccia grafica che in qualche maniera viene integrata all’interno dell’interfaccia vSphere e che quindi permette al vSphere Admin di non dover cambiare più di tanto le modalità di gestione del troubleshooting.
Arriviamo così al 2020, quando VMware lancia vSphere 7 che rappresenta il consolidamento del progetto che da Project Pacific passa a vSphere 7.
Facciamo un accenno alla tipica architettura a container basata sul popolare Docker che permette di avere le nozioni di base per comprendere il perché di Kubernetes.
Docker è una tecnologia basata su container Linux per automatizzare il deployment di applicazioni all'interno di contenitori software, fornendo un elevato livello di astrazione grazie alla virtualizzazione a livello di sistema operativo concesso da Linux.
Docker utilizza le funzionalità di isolamento delle risorse del kernel Linux, come cgroup e namespace per consentire a container indipendenti di coesistere sulla stessa istanza di Linux, evitando l'installazione e la manutenzione di una macchina virtuale (VM): i namespace del kernel Linux isolano ciò che l'applicazione può vedere dell'ambiente operativo, incluso l'albero dei processi, la rete, gli ID utente e i file system montati, mentre i cgroup forniscono l'isolamento delle risorse, inclusa la CPU, la memoria, i dispositivi di I/O a blocchi e la rete.
I container condividono lo stesso kernel, ma ciascuno di essi può dover utilizzare una certa quantità di risorse, come la CPU, la memoria e l'I/O.
Docker ha sviluppato un proprio formato di “conteinerizzazione” interoperabile, capace di pacchettizzare le applicazioni ed effettuarne il deploy in qualsiasi ambiente di esecuzione, senza doversi preoccupare delle condizioni di eseguibilità.
Gli elementi principali di Docker sono il Docker Host, che è la macchina dove i container vanno in esecuzione; in esso c’è un demone Docker, una serie di immagini e i container veri e propri, oltre alle Docker API.
L’Immagine contiene tutte le istruzioni che faranno nascere il container (ad esempio da dove deve partire, le dipendenze e i pacchetti, le configurazioni ecc.) e può essere paragonata a un template di VMware, dove creiamo una macchina, poi installiamo il sistema operativo e tutto quello che ci serve, quindi con questo template possiamo clonare altre macchine.
Il container è l'immagine Docker quando è in esecuzione, ossia l'unità standard dei servizi; ogni volta che lanciamo un container diciamo a Docker di prendere una data immagine e costruire un container partendo da essa. Praticamente un container Docker parte da un file che viene chiamato Docker file, ossia l’immagine e dall'immagine poi facciamo nascere il container. Dall’immagine possiamo far partire uno, due o decine e centinaia di container, che poi condivideranno a questo punto il kernel e tutte le dipendenze del sistema operativo ecc.
L’engine è il software che esegue i comandi per i container e può essere considerato come qualcosa di simile all’hypervisor delle macchine virtuali
Infine il Registry è il registro che memorizza, distribuisce e gestisce le immagini di Docker, quindi quando da client (locale o remoto) si chiede la creazione di un certo container, Docker ne va a “chiedere” l’immagine al Registry.
Il container in pratica è l’esecuzione dell’immagine, ossia un’istanza dell’immagine che contiene solo la differenza rispetto all’immagine originale. Per comprendere il concetto si può fare un parallelo con Horizon, dove la modalità di Delivery, per esempio dei client e dei desktop virtuali, è basada sulla cosiddetta Gold Image e prevede che a questa immagine venga attaccata tutte le volte un’istanza relativa ad essa, ma contenente solo le differenze rispetto all’istanza originale. Quindi a runtime, lo storage, anche se è uno storage effimero (un qualcosa che quando muore il container se ne va via con esso) agganciato a questa immagine, di fatto ne contiene solo i delta.
Quindi l’immagine di base ha tutto quello che serve e l’istanza contiene una parte di storage con i delta; questo storage è libero fino a quando a livello di container non andiamo a introdurre il persistent volume ovvero a un certo punto questa directory viene montata dal container e quindi viene fruita direttamente all'interno del container utilizzando proprio dei comandi classici di mount, però tutto sempre all’interno del container.
Quindi quello che andremo a scrivere poi in queste directory finalmente verrà stoccato all’interno di questo di questo storage e quindi potremo facilmente avere le persistenze anche del container.
Il container quindi ha una logica stateless, quindi logica che ci permette di eseguire istanze protette ma che in situazione ordinaria non ne conserva lo stato; la cancellazione del container non è come la cancellazione di una macchina virtuale perché quando viene cancellato il container è come mandare giù un’istanza che stava in RAM, quindi se non è stato creato un persistent volume i relativi dati vengono persi.
Ciò fa un po’ parte delle logiche di costituzione delle applicazioni, perché le applicazioni tradizionali prevedono ancora l’utilizzo di volumi persistenti, mentre una logica a microservizi divide la logica stateless e la logica stateful che ne conserva un po' quella che è la coerenza. Quindi quando si mette su un container, l’unica cosa di persistente che serve sono magari le configurazioni, ossia la definizione di come deve girare quel particolare microservizio.
Abbiamo quindi visto cosa sono i container di Docker e quanto siano pratici e utili. C’è però da considerare che si può arrivare a dover gestire e orchestrare tantissimi container, che magari si trovano in varie infrastrutture e che, come tutte le macchine e i servizi, possono bloccarsi e presentare i problemi caratteristici. Inoltre i container riflettono le vicende dei server su cui sono in esecuzione, quindi se un host va giù si ferma anche il container. Abbiamo quindi bisogno che se un container va giù sia possibile deployare lo stesso container su un altro server che sia Up. Per fare tutto ciò ci serve un orchestratore e nello specifico di Kubernetes.
Kubernetes è ormai lo standard a livello di cluster di container, seppure ci sono e ci siano state altre soluzioni paragonabili.
Kubernetes è un orchestratore open source per la gestione e distribuzione di applicazioni a container e gestisce i container radunandoli in cluster, ma più in generale gestisce l’intero ciclo di vita dei container.
L’orchestratore va a introdurre una sorta di availability dei container, svolgendo anche funzioni relative alla scalabilità della potenza dei container. L’availability è permessa dalla possibilità di avere “n” container a disposizione per poter eseguire un’applicazione in maniera resiliente.
Quindi l'introduzione di un orchestratore sopra una serie di batterie di host è stata la chiave di volta che ha permesso di portare i container ad essere qualcosa di Enterprise e di destinabile alla produzione.
Kubernetes può essere assimilato al vCenter di VMware, in quanto ne condivide alcune caratteristiche, pur essendo dedicato ai container e non alle macchine virtuali.
L’architettura di Kubernetes è legata al fatto che l’orchestratore di container è un orchestratore di elementi che ne gestisce soprattutto il ciclo di vita.
L’immagine seguente propone i componenti di un generico cluster Kubernetes: a sinistra abbiamo la parte del Control plane e a destra quella dei Node; possiamo chiamare Master Node il Control Plane e Worker Node i nodi veri e propri. I Master Node rappresentano i punti di ingresso a livello sia di gestione che di delivery dei container.
I nodi sono le macchine virtuali e quindi i container host, tutti con il loro Container Engine (Docker, ma Kubernetes può gestire anche altri engine). L’architettura di Kubernetes è quindi formata dai Nodi, che sono il Control Plane e i Worker (Workload Node): all’interno del Control Plane si trovano il Kube API server e il database ETCD.
L’ETCD è un database distribuito basato sul File System e gestisce gli stati persistenti, ma potrebbe utilizzare anche della RAM per velocizzare l’attività. Si potrebbe considerarlo qualcosa di simile al database di supporto a vCenter, che oggi fortunatamente è integrato nella stessa vCenter Appliance.
Il Kube-controller manager si incarica analizzare lo stato del Cluster e rispondere a eventuali cambiamenti.
Il kube scheduler ha una funzione puramente di check-in ed è l’elemento che stabilisce quale sarà il nodo di riferimento, ossia il nodo che accenderà un particolare container (notare che in questo caso non si chiameranno più container).
Il kube API server è la parte fondamentale, che si incarica di comunicare con i nodi e con l’esterno del cluster kubernetes.
Il kube controller manager e il Cloud controller manager sono le due entità che si occupano di gestire il cluster: il primo governa la parte locale e i nodi, mentre il secondo provvede al management e comunicazione con il Cloud se esistono delle risorse al di fuori del cluster.
Il Control Plane serve per l’orchestrazione dei worker (dei nodi) ed è un ambiente che potrebbe essere il parallelo di VMware con vSphere, NSX e tutti gli altri sistemi che utilizza poi per far funzionare le VM.
I Worker Node contengono i servizi di sistema (Kubelet e il Container Runtime) i POD, le Kube Entities (Configmap, Storage Volumes, Ingress) e le External Entities (Load Balancers).
Sotto i nodi c’è l’infrastruttura Cloud, che è quella che si presta meglio a Kubernetess; vedremo più avanti che vSphere è sicuramente una Private Cloud Infrastructure compatibile con questo sistema.
Kubelet è praticamente l’interfaccia di riferimento per la quale il Master Node impartisce direttive; in breve è il demone che girava all'interno del nodo che serve per la comunicazione con il vCenter. Kubelet è molto importante perché senza questo componente il nodo il master non può più comunicare con i nodi del Cluster e non ci sarebbe più il controllo e la gestione dell'intero cluster, il che potrebbe comprometterne la funzionalità.
Il Kube Proxy è praticamente il Network Layer del nodo, ossia il Network Proxy che permette la comunicazione verso l’esterno e all'interno, ovvero che mette in comunicazione i container con l'esterno.
Il container runtime è l’engine che manda in esecuzione i container (tipicamente ma non esclusivamente Docker) e poi abbiamo degli elementi, che non sono strettamente container ma che contengono i container: si tratta dei POD, i quali sono l'unità minima che Kubernetis ti riesce a gestire. All'interno di un POD si trovano quindi le Deploayable Unit of Computing, quindi uno più container; nel POD c'è un’interfaccia di comunicazione di rete che permette la comunicazione, quindi permette la gestione delle connessioni all'interno dei container.
Il POD rappresenta la migliore architettura possibile quando si tratta di scalare i container, perché al suo interno possono girare più container di cui uno sia la replica del container principale.
Per poter comunicare verso l'esterno, il POD ha bisogno di utilizzare tutto il Network Layer, ma questo espone di fatto una porta e la porta del container è la porta del Container Host.
Se vogliamo una gestione più efficiente e far sì che il POD, se acceso su più nodi risponda comunque in maniera univoca a un solo indirizzo, dobbiamo introdurre delle altre strutture che sono dei Cluster interni (quindi dei bilanciatori interni) oppure dei Bilanciatori esterni.
Una modalità molto interessante consiste nell’introdurre un elemento di terze parti fornito da Ngnix che si chiama Ingress: questo ci permette, tramite l'utilizzo di Virtual Host, di stabilire quale dei Pod deve rispondere a seconda del Virtual host che viene chiamato.
Quindi abbiamo un solo punto di ingresso e una serie di nodi sotto, i quali rispondono ognuno per una porta ma il Load Balancer sa che questa decisione spetta poi un altro componente che è l'Ingress, il quale ha un controller e che quindi stabilisce chi sarà l’Host che dovrà rispondere.
Si tratta sostanzialmente di un Reverse Proxy che però gira all'interno di Kubernetes e quindi è integrato con le logiche di Kubernetes.
Infine, quelli che nello schema sono chiamati add-ons sono elementi stateful (persistent volume e storage class) che formano un agglomerato di come il Cloud provisioning risponde. Per esempio vSphere volumes è uno storage class che è stato rilasciato all'interno di kubernetes e quindi permette la comunicazione diretta con gli elementi di vSphere; nello specifico, l'elemento stateful di vSphere sono i vmdk; come questi vengono poi messi a disposizione dipende, perché nelle architetture tradizionali viene fatto il cosiddetto provisioning a mano, mentre nelle architetture vSan il provisioning è automatico e ciò rappresenta un punto di forza delle nuove architetture vSphere ed anche di quelle che sono le architetture basate sull’iperconvergenza, che già espongono primitive utilizzabili direttamente da Kubernetes per la cosiddetta persistenza del dato.
Le Configmap sono nient'altro che unioni di chiave-valore all'interno di un container (di un blocco), mentre i Secrets riguardano le modalità di protezione di parti dei container che si desidera non siano esposte.
Il Namespace è l'agglomerato di tanti POD assimilabile alla fusione di un Resource Group e una Folder nella quale possiamo autorizzare l’accesso e nella quale possiamo far girare n POD.
Ovviamente vige la stessa logica che abbiamo in vSphere, nella quale ogni POD prende delle risorse e se non ne vengono specificati limiti queste risorse sono condivise fino ad esaurimento.
Va notata una differenza con i cluster vSphere: in Kubernetes un POD non può essere migrato, perché nasce e muore all'interno dell'host. Viene quindi da chiedersi come fa l’orchestrator
a girare se succede qualcosa al POD oppure come si fa a portare il mio POD da un nodo all'altro? Ebbene, la cosa è fattibile semplicemente accendendo il POD nel nodo destinazione e spegnendo il POD origine.
L’applicazione deve essere stateless e occorre prevedere alcune cose: per esempio se si tira su un container in un altro host occorre accertarsi che anche lo storage e quindi le parti persistenti siano accessibili in quell’host e se non sono accessibili (quindi c’è una modalità di write all'interno dell’host) sarà necessario gestire in qualche maniera questa concorrenza di fattori.
Quindi non è la stessa cosa che in vSphere, ad eccezione dell’High Availability di vSphere che ha un comportamento molto simile: l’orchestrator stabilisce che se un POD è andato giù per qualsiasi ragione lo si debba tirar su magari in un altro host se l’host originario non è più raggiungibile o nello stesso host se si è trattato solo di un problema intrinseco del container.
Una considerazione importante riguarda il fatto che per operazioni come quella appena descritta e per la cosidetta manutenzione ordinaria e straordinaria, Kubernetes Vanilla non offre un automatismo, quindi tutto quello che occorre va fatto da noi. Per avere una forma di automazione bisognerebbe utilizzare tool di terze parti, come quelli di VMware che agiscono all'interno della stessa infrastruttura e che permettono di deliverare le cose in una modalità un po’ diversa, automatizzando proprio queste procedure.
L’infrastruttura deve essere Cloud e aderire agli standard del Cloud, dove la scalabilità degli elementi non deve essere legata all'hardware sottostante. Da qui VMware mette a disposizione all'interno del suo pacchetto tre prodotti di riferimento che sono vSAN, vSphere e NSX (immagine seguente); permettono di trasformare l’hardware tradizionale, dotato comunque di una struttura a server, quindi con una scalabilità che ha come modello quello del building block a server.
Nello schema dell’immagine precedente, sopra gli strumenti di virtualizzazione e scalabilità di VMware troviamo il concetto di SDDC (Software Defined Data Center) cioè un Data Center che viene definito attraverso delle componenti software, quindi una riaggregazione delle componenti hardware... un'astrazione delle componenti hardware negli ambienti superiori e quindi quelli usati dall'azienda stessa e dai clienti (viene introdotto anche il concetto di tenant).
Sopra al concetto SDDC finalmente troviamo le Cloud-Native Applications, cioè applicazioni che nascono e funzionano meglio all'interno di questo ecosistema.
Dunque Kubernetes è l’ideale per essere eseguito in Cloud, privato o pubblico che sia. È possibile far girare kubernetes anche in un ambiente tradizionale, magari fatto dallo storage classico e così via, però si perde la scalabilità lineare; quindi si è sempre dipendenti dal vendor, che solitamente non consente la scalabilità lineare delle risorse ma offre pacchetti e quindi impone passaggi a gradini.
Con l'adozione di vSAN, in un modello Cloud questo problema non si pone.
Una cosa molto importante in Kubernetes è che si può definire il cosiddetto CCM (Cloud Controller Manager) che è un’interfaccia, o meglio un plugin che viene eseguito e messo a disposizione di qualsiasi nodo VMware, quindi controllato dal Kube Controller Manager, intercettato e messo in comunicazione anche con l’API Server. Ma non solo: è anche possibile anche metterlo in comunicazione (in vSAN, per esempio) anche attraverso la Kubelet dei Workload Node, quindi tutti i Cloud Provider che aderiscono a tale integrazione possono permettere al Cluster Kubernetes un’integrazione e una scalabilità migliori.
Sappiamo che ogni POD si prende un suo indirizzo IP, ma in che modo si va a gestire la comunicazione tra POD senza ricorrere al NAT? La risposta è che si utilizza un overlay. Kubernetes si appoggia a degli SDN (Software-Defined Network) cioè, più che altro sono degli overlay di network. Lo schema dell’integrazione di rete in Kubernetes è proposto dall’immagine seguente.
Quando diventa necessario gestire la security, in base all’overlay che si sceglie si applicano determinati strumenti. A riguardo va notato che NSX-T, che toglie quelli che sono i boundaries con l'infrastruttura e che quindi nasce come un prodotto singolo non dipendente dall'infrastruttura vSphere, ha una sua CNI, ossia un suo driver; questo significa che è possibile integrare questo driver.
Per esempio, è possibile installare NSX-T su un Bare Metal e implementare una SDN su di esso.
A questo punto è opportuno precisare che si può anche deliverare Kubernetes direttamente su Bare Metal, però si perdono alcuni elementi di resilienza che un'infrastruttura virtuale fornisce; molti vendor nell’infrastruttura iperconvergente fanno girare kubernetes nativo, però si tratta pur sempre di prendere un'applicazione tradizionale che non era nata con questo concetto e indurla a girare in questa infrastruttura: non sarà mai efficiente ci arriveremo a un certo punto un altro Breaking Point col tempo perché al momento che la dovremmo scalare non sarà possibile scalarla come possiamo scalare un microservizio.
Va ricordato che per migrare un’applicazione Cloud Native da un cluster a un altro, l’unico modo è accenderla all'interno dell’altro cluster e poi utilizzare il bilanciatore L4 o L7 visibile nell’immagine precedente (che è un elemento esterno al cluster kubernetes) per commutare su questa nuova applicazione.
Quindi dal momento in cui si inizia un modello integrazione bisogna decidere se investire nella modalità svincolata da vSphere o in una modalità un po’ più legata a vSphere. Tenete presente che NSX-T all'inizio era un prerequisito, ma nella versione vSphere 7.1 non lo è più.
Dunque, se volete provare a usare i container con vSphere, partite dalla versione 7.1.
Passiamo ora alla Storage Integration: a livello generale possiamo integrare con NFS, i-SCSI, Ceph, Gluster FS, vSAN (direttamente nativo). Molti Storage Vendor mettono a disposizione il loro CSI driver per far sì che i vostri POD lavorino direttamente con il loro Storage e questo diventa obbligatorio se ci si trova in un’infrastruttura fisica, ma tenete presente che questa integrazione con lo storage sottostante vi permette anche di, per esempio, usare un persistent volume tra un cluster Kubernetes e un altro. In questo modo si dovrebbe facilitare alcuni processi di migrazione. Poi bisogna vedere sempre quali sono le dipendenze, perché poi anche questo driver dev’essere affidabile. Quindi prima di andare a integrare un qualcosa è sempre meglio sfruttare vSAN piuttosto che, alla peggio, il datastore che VMware mette a disposizione; teniamo sempre presente che i driver nativi degli storage vanno bene, però nella maggior parte dei casi è meglio utilizzare quelli dell’infrastruttura virtuale.
Ora passiamo finalmente a spiegare come VMware utilizza i Kubernetes Cluster: già dalla versione 7.0, vSphere aveva introdotto la parte del Kubernetes Layer fusa all’interno del Virtual Environment; sopra ci potevano girare come workload, quindi come se fossero i Worker Node (i Master Node sono a un livello inferiore a quello dei Worker Node).
Ma attenzione a una differenza: anziché avere i POD ci sono i vSphere POD, insieme alle VM e insieme a quelli che si chiamano Tanzu Kubernetes Cluster.
I vSphere POD sono di fatto delle VM, quindi VMware ha stravolto il concetto del POD di Kubernetes introducendo un concetto un po’ differente che è quello di una VM formata guardacaso da un container host formato da un kernel (Photon) e comunque da uno o più container Linux. Quindi si tratta di una VM essenziale che esegue uno o più container, proprio come nei POD originali. I container girano nello stesso host e sono in comunicazione sia all'interno che all'esterno grazie a NSX.
Poi è stato inventato un altro elemento che si chiama Tanzu Kubernetes Cluster: è una distribuzione completamente gestita da VMware che combina Cluster kubernetes con la logica ancora kubernetes ma nello strato superiore (immagine seguente)e non sono di fatto dei cluster kubernetes veri e propri, cioè non si va a consumare in tutto e per tutto delle VM di Master per andare a gestire questo cluster ma ci si appoggia ancora unicamente a quello che si chiama il Supervisor Cluster, che è ancora fuso all'interno della realtà vSphere e quindi ha tutti gli elementi che servono per poter comunicare.
Da qui esistono tutte le integrazioni a livello di UI con vCenter Server. La catasta di blocchi che vedete nell’immagine è integrata nativamente in vSphere e permette anche delle ulteriori integrazioni, ovvero di gestire più realtà come se fossero multitenant.
Quindi per far girare dei POD e Kubernetes Cluster c’è ancora bisogno delle VM, come visto nelle architetture Kubernetes tradizionali.
Il POD è un contenitore all’interno del quale si trovano container e un'altra serie di elementi e dal punto di vista infrastrutturale vero e proprio (quindi da quello di VMware) è una macchina virtuale; VMware ha semplificato tutto perché chiaramente spostare una macchina virtuale usa già tutta l’infrastruttura sottostante. Si è fatto ricorso a tale artificio perché così diventava più facile utilizzare gli stessi concetti che c'erano nelle macchine virtuali.
Però NSX-T poteva costituire una limitazione perché per esempio non tutti vogliono a utilizzare NSX, perché può aumentare il livello di complicazione dell’infrastruttura.
In realtà questo concetto riguarda NSX-T e non NSX-V.
NSX-V nasce con la virtualizzazione di vSphere ed è un elemento che deriva dalle ceneri del vCloud Network and Security, cioè introduce overlay dei Virtual switch Virtual networking e elementi di Edge come Virtual Firewall, che sfruttano l'ambiente di vSphere per andare a deliverare questi componenti aggiuntivi.
All'inizio l’adozione potrebbe complicare un po’ le cose, ma nella realtà no. Per esempio guardandola dal punto di vista di un Cloud Provider che deve deliverare 150 milioni di reti per ogni cliente, al quale lascia il compito di deliverare le sue reti come vuole e quindi che deve anche gestire l’overlapping e l’overlay e così via delle delle reti, comincia a diventare un grosso problema perché NSX risolve il problema all'origine introducendo il Software Layer sopra il network Layer. Di fatto il Phisical Layer con NSX diventano tre reti; c’è poi un mega tunnel fra i tre diversi Host e tutto il resto è gestito on top a questo tunnel.
Il vSphere POD è una modalità che Tanzu Kubernetes Cluster in realtà ci dà qualcosa di self-provvisioned, ossia di più semplice; si può considerare una versione da utilizzare in un Private Cloud di ciò che troviamo in Amazon o in Azure quando compriamo Kubernetes; è già pronto con template di macchine virtuali.
Diciamo che dietro un Tanzu Kubernetes Cluster c’è un componente chiamato Tanzu Kubernetes Grid Resource che non fa nient'altro (una sorta di kickstarter) che originare il primo cluster. Quindi questo ha già dei template è già mette a posto all'interno del template tutte le varie componenti che girano all'interno di kubernetes e che permettono la comunicazione col Supervisor Cluster.
A questo punto può essere interessante spendere due righe per descrivere Tanzu Mission Control: si tratta di un elemento presente nel portale di VMware Cloud Services quindi non è un qualcosa da deliverare on premise ma è a disposizione del VMware Cloud Services; praticamente è un SaaS.
Centralizza tutta la gestione on-premise ma in aggiunge anche parte del supporto multi Cloud, perché essendo un elemento esterno e svincolato da architetture, aggiunge un layer in più che permette di controllare e comandare tutto il ciclo di vita non solo dei cluster, ma anche del software che gira all'interno di essi.
Quindi Cluster kubernetes deliverati in AWS, Google Cloud Platform, Azure, ma anche Cluster vShere che girano in locale e anche Cluster di terze parti che girano in locale purché il Cluster Kubernetes abbia le API Kubernetes. Infatti in Kubernetes qualsiasi cluster lo stesso subset di API; se poi ha più o meno integrazioni con la parte di vSphere, AWS, Azure ecc. è un elemento in più, ma di base Kubernetes ha le sue API, altrimenti non è Kubernetes.
Quindi gestire tanti Cluster kubernetes, siano questi in AWS, Azure ecc. non è un lavoro così grosso, dal momento che il set di API per richiamare i vari cluster Kubernetes alla fine è sempre lo stesso. Ciò vale anche per la parte di autenticazione iniziale e questo non va visto come un problema ma può essere anche un’opportunità, perché tale integrazione è utile ad esempio quando si ha un container che deve chiamare un elemento infrastrutturali AWS e quindi ne assume diritti diretti senza che questo si porti dietro le credenziali.
Andiamo ora nel dettaglio dell’update 1 della versione 7 di vSphere, ossia VCF con vSphere, che è l’architettura in verde nell’immagine seguente: è ancora quella che usavamo prima ma che va a integrare a livello di Tanzu Runtime Service l’Hybrid Infrastructure Services.
Tanzu Runtime Service è ciò che abbiamo già visto, ma ora entra in quella che si chiama VMware Cloud Foundation Service. Quindi quell'elemento fatto con Tanzu Kubernetes Grid Services visto prima e la parte di vSphere POD Service entrano in un elemento comune che è il rettangolo che li raggruppa nell’immagine precedente.
Lo strato sottostante è composto da vSphere, NSX-T, vSAN e magari vRealize per andare a fare il controllo delle Operation all'interno di questo sistema. Questo se volete le cose gestite alla VMware, quindi avete i vostri vSphere Admin che non vogliono uscire dal vSphere Server e i vostri developer che vogliono un'interfaccia per poter dialogare, quindi l'interfaccia standard come Kubernetes comanda.
Poi è arrivata vSphere with Tanzu: come mostra l’immagine seguente c’è ancora runtime service questa volta Grid Service con Tanzu Kubernetes Service ma a livello Infrastructure Service. introduce Network Service e Master Service e sotto c'è ancora vSphere, però al posto di NSX e vSAN ci sono le distribuzioni rispettivamente BYO Storage e BYO Network.
Tra le distribuzioni disponibili c’è anche BYO Load Balancer, che ha una certa versatilità: ad esempio se si ha un contratto con F5, che mette a disposizione il Load Balancer, con questa distribuzione si può andarlo a integrare direttamente.
Per c’è una gestione di vCenter e se gli elementi sottostanti si integrano bene, sennò sono comunque disponibili. Quindi se da un lato dissocia la componente di Kubernetes rispetto alle parti di infrastruttura di vSphere, dall’altro accelera comunque la messa in produzione dei cluster vSphere.
Analizziamo ora le principali differenze tra Vsphere Cloud Foundation con Tanzu e vSphere con Tanzu: nel primo caso sono richiesti sia VCF (chiaramente) sia NSX-T; la necessità di NSX-T, che pur presenta un costo non indifferente, non va vista come un male, perché NSX-T automatizzata tutta una serie di componenti che rendono il sistema più Cloud-compliant. Per esempio fornisce anche l’overlay tra POD e overlay, cosa che l'architettura tradizionale è decisamente più complessa, giacché bisognerebbe comunque passare attraverso del routing o del NATing e comunque in qualche maniera occorrerebbe passare attraverso la macchina virtuale e l’ Ingress, quindi altre strutture aggiuntive.
Con NSX-T questo livello si assottiglia e diventa un ponte di comunicazione unico.
La cosa importante da precisare è che l’architettura con Tanzu introduce vSphere POD però si può anche utilizzare la parte dei container e dei POD tradizionali.
Invece vSphere senza Tanzu richiede che ci si porti dietro i propri elementi: non è richiesto NSX-T e non c’è supporto nativo VDS networking. Inoltre usa HaProxy come Virtual appliance in sostituzione dei Load Balancer di NSX-T e integra poi CNI con Tanzu kubernetes Grid, che comunque è tutta la parte di Calico.
Un’altra particolarità importante è Harbor, che utilizza un registry privato, quindi non più Docker o comunque non più un registro deliverato così come una macchina virtuale separata: non è vSphere ma solo un contenitore di immagini, né più né meno; VCF con Tanzu il registry è privato e gestito in una particolare maniera. È integrato direttamente con la distribuzione. Nel vSphere con Tanzu non è integrato, però non fa una grossa differenza né costituisce un elemento tale da compromettere la funzionalità del cluster Kubernetes.
Ultimo ma non ultimo dettaglio da prendere in considerazione è Ranchel Lab, che è una UI fortemente integrata in vSphere (immagine seguente) ad eccezione di NSX, che non è gestito attualmente in maniera coerente con Kubernetes.
Ma una cosa molto interessante è che ha le stesse funzionalità di Mission Control ma è deliverato on-premise, quindi abbiamo un prodotto che di fatto si porta dietro non solo un elemento che prende in carico i Kubernetes cluster deliverati on-premise (non prende in carico ma addirittura delivera i componenti per Kubernetes cluster) ma si prende anche in carico componenti di altri cloud provider o componenti di terze parti, ossia cluster deliverati da terze parti come potrebbero essere quelli di Digital Ocean.
Rancher è molto facile da usare, è un'interfaccia utente molto interessante e di facile apprendimento, il che rende più agevole il passaggio da vSphere Admin a Kubernetes Cluster Admin.
Rancher è una completa piattaforma di gestione di container costruita su Kubernetes.
VMware con Hands On Labs mette a disposizione un ambiente dove operare su istanze vSphere, NSX e tutto quello che serve in una modalità “automatica”; per esempio è possibile provare NSX-T senza doverlo installare: basta entrare in Hands On Labs (https://www.vmware.com/it/try-vmware/try-sai-hands-on-labs.html) e scegliere un “laboratorio”. Ogni laboratorio ha un tempo prestabilito, cioè si può provare un prodotto per un tempo predefinito e non all’infinito, ovvero è possibile avere un laboratorio permanente ma non gratis.
Però, gratuitamente è possibile testare le funzionalità d’interesse e questo è molto interessante soprattutto per chi vuole testare prodotti per capire se possono andare bene alle sue applicazioni.
La cosa molto molto interessante è che potete provare Tanzu Mission Control direttamente, sebbene non possiate interagire dall'esterno all'interno del Lab, il che è normale perché non si tratterebbe più di un ambiente dimostrativo ma di un'infrastruttura che consuma e che quindi va pagata.
Nell’immagine seguente è proposta l’interfaccia web di Rancher UI, la cui pagina iniziale è Global e riporta la situazione complessiva e quindi le attività.
Cliccando sul comando di toolbar Clusters si accede alla pagina riepilogativa dei cluster già presenti e alla relativa Dashboard, un esempio della quale è proposto nell’immagine seguente.
La dashboard riporta il riepilogo del cluster con risorse impiegate (RAM, CPU, POD) e via di seguito.
È possibile entrare in ciascun POD per vederne le funzionalità, cliccando sul pulsante con i tre puntini e aprendo il menu corrispondente, quindi scegliendo Edit (immagine seguente); notare che un nodo può essere Master, Worker o entrambi, però in produzione non si imposta mai un nodo con entrambe le modalità e i nodi devono essere Master o Worker, con una regola: i nodi Worker possono essere da 1 a crescere, ma i nodi Master devono essere uno o tre o multipli. Rancher fa in modo che non si esca da questi paletti.
All’interno della pagina del POD è possibile vedere i vari parametri del cluster, come per esempio la versione di Kubernetes e la CNI impiegata: il fatto che questa cosa sia integrata con un Cloud provider è quello che permette di comunicare e di far sì che il Cluster kubernetes vada a comunicare direttamente con l'infrastruttura.
La manutenzione sui nodi è la stessa di vSphere e un nuovo nodo può essere scalato agevolmente con il tasto “più”.
