È possibile utilizzare vSphere IaaS control plane per trasformare vSphere in una piattaforma per l'esecuzione nativa dei carichi di lavoro Kubernetes a livello di hypervisor. Quando è abilitato nei cluster vSphere, vSphere IaaS control plane offre la possibilità di eseguire i carichi di lavoro di Kubernetes direttamente negli host ESXi e di creare cluster Kubernetes upstream in spazi dei nomi dedicati denominati Spazio dei nomi vSphere.

Le sfide dello stack di applicazioni attuale

I sistemi distribuiti attuali sono creati da microservizi multipli che in genere eseguono un gran numero di macchine virtuali e pod Kubernetes. Uno stack tipico non basato su vSphere IaaS control plane è costituito da un ambiente virtuale sottostante, con l'infrastruttura Kubernetes distribuita nelle macchine virtuali e rispettivamente dai pod Kubernetes in esecuzione in queste macchine virtuali. Tre ruoli distinti operano in ogni parte dello stack, ovvero sviluppatori di applicazioni, amministratori di cluster Kubernetes e amministratori di vSphere.

Figura 1. Lo stack di applicazioni attuale
Sack con 3 livelli: carico di lavoro Kubernetes, cluster Kubernetes, ambiente virtuale. Vengono gestiti dai tre ruoli: sviluppatore, amministratore cluster, amministratore vSphere.
I diversi ruoli non hanno visibilità o controllo sugli ambienti degli altri:
  • Lo sviluppatore di applicazioni può eseguire pod Kubernetes e distribuire e gestire applicazioni basate su Kubernetes. Non si dispone di visibilità sull'intero stack che sta eseguendo centinaia di applicazioni.
  • Il tecnico di DevOps o l'amministratore del cluster controlla solo l'infrastruttura di Kubernetes, senza gli strumenti per gestire o monitorare l'ambiente virtuale e risolvere eventuali problemi relativi alle risorse e altri problemi.
  • L'amministratore di vSphere ha il controllo completo sull'ambiente virtuale sottostante, ma non ha visibilità sull'infrastruttura Kubernetes, sul posizionamento dei diversi oggetti Kubernetes nell'ambiente virtuale e sul modo in cui questi utilizzano le risorse.

Eseguire operazioni sull'intero stack può essere difficile, perché richiederebbe la comunicazione tra tutti e tre i ruoli. Anche la mancanza di integrazione tra i diversi livelli dello stack può comportare delle problematiche. Ad esempio, l'utilità di pianificazione di Kubernetes non ha visibilità sull'inventario di vCenter Server e non può posizionare i pod in modo intelligente.

Quali sono i vantaggi offerti da vSphere IaaS control plane?

vSphere IaaS control plane crea un piano di controllo di Kubernetes direttamente al livello dell'hypervisor. Un amministratore di vSphere attiva i cluster vSphere esistenti per vSphere IaaS control plane creando così un livello Kubernetes negli host ESXi che fanno parte dei cluster. I cluster vSphere attivati per vSphere IaaS control plane sono denominati Supervisori.

Figura 2. vSphere IaaS control plane

Lo stack della piattaforma IaaS con carichi di lavoro si trova nella parte superiore, lo stack dell'ambiente virtuale è nella parte inferiore. Vengono gestiti da due ruoli: sviluppatore e amministratore vSphere.
La presenza di un piano di controllo Kubernetes a livello di hypervisor consente di ottenere le seguenti funzionalità in vSphere:
  • L'amministratore di vSphere può creare spazi dei nomi nel Supervisore, denominati Spazi dei nomi vSphere, e configurarli con quantità di memoria, CPU e storage specificate. Gli Spazi dei nomi vSphere vengono forniti ai tecnici di DevOps.
  • Un tecnico di DevOps può eseguire carichi di lavoro Kubernetes nella stessa piattaforma dei pool di risorse condivisi in uno Spazio dei nomi vSphere. È possibile distribuire e gestire più cluster Kubernetes upstream creati utilizzando Tanzu Kubernetes Grid. È inoltre possibile distribuire container Kubernetes direttamente nel Supervisore in un tipo specifico di macchina virtuale denominato Pod vSphere. È inoltre possibile distribuire macchine virtuali normali.
  • L'amministratore di vSphere può gestire e monitorare Pod vSphere, macchine virtuali e cluster di Tanzu Kubernetes Grid utilizzando vSphere Client.
  • L'amministratore di vSphere ha piena visibilità su Pod vSphere, macchine virtuali e cluster di Tanzu Kubernetes Grid in esecuzione in spazi dei nomi diversi, sul loro posizionamento nell'ambiente e sul modo in cui utilizzano le risorse.

La presenza di Kubernetes in esecuzione a livello di hypervisor semplifica anche la collaborazione tra gli amministratori di vSphere e i team di DevOps, poiché entrambi i ruoli lavorano con gli stessi oggetti.

Cos'è un carico di lavoro?

In vSphere IaaS control plane, i carichi di lavoro sono applicazioni distribuite in uno dei modi seguenti:

  • Applicazioni costituite da container in esecuzione in Pod vSphere.
  • Carichi di lavoro sottoposti a provisioning tramite il servizio della macchina virtuale.
  • Cluster Tanzu Kubernetes Grid distribuiti utilizzando Tanzu Kubernetes Grid.
  • Applicazioni eseguite nei cluster Tanzu Kubernetes Grid.

Che cosa sono le zone vSphere?

Le zone vSphere forniscono ai carichi di lavoro distribuiti in vSphere IaaS control plane l'alta disponibilità quando si verificano errori a livello del cluster. Un amministratore di vSphere può creare zone vSphere in vSphere Client e quindi mappare i cluster vSphere alle zone. Le zone vengono utilizzate per distribuire Supervisori nell'ambiente vSphere IaaS control plane.

Per garantire l'alta disponibilità a livello del cluster, è possibile distribuire un Supervisore in tre zone vSphere. In alternativa, è possibile distribuire un Supervisore in un singolo cluster vSphere, che creerà automaticamente una zona vSphere e la mapperà al cluster, oppure è possibile utilizzare un cluster già mappato a una zona. Per ulteriori informazioni, vedere Architettura di Supervisore e Distribuzioni a più zone e a cluster singolo del Supervisore.

Cos'è un cluster di Tanzu Kubernetes Grid?

Un cluster Tanzu Kubernetes Grid è una distribuzione completa di Kubernetes creata, firmata e supportata da VMware. È possibile eseguire il provisioning di cluster Tanzu Kubernetes Grid upstream, nonché utilizzarli nei Supervisori tramite Tanzu Kubernetes Grid.

Un cluster Tanzu Kubernetes Grid di cui Tanzu Kubernetes Grid ha eseguito il provisioning ha le caratteristiche seguenti:
Le caratteristiche del cluster TKG, da sinistra a destra, sono basate su un criterio ben integrato, pronto per la produzione, completamente supportato e gestito da Kubernetes
  • Installazione convenzionale di Kubernetes. Tanzu Kubernetes Grid fornisce valori predefiniti ponderati e ottimizzati per consentire a vSphere di eseguire il provisioning di cluster Tanzu Kubernetes Grid. Utilizzando Tanzu Kubernetes Grid, è possibile risparmiare il tempo e le risorse normalmente dedicati alla distribuzione e all'esecuzione di un cluster Kubernetes di livello aziendale
  • Integrato con l'infrastruttura di vSphere. Un cluster di Tanzu Kubernetes Grid è integrato con lo stack dell'SDDC di vSphere, incluso storage, rete e autenticazione. Un cluster Tanzu Kubernetes Grid è inoltre basato su un Supervisore mappato ai cluster vSphere. Grazie alla stretta integrazione, l'esecuzione di un cluster di Tanzu Kubernetes Grid rappresenta un'esperienza di prodotto unificata.
  • Pronto per la produzione. Tanzu Kubernetes Grid esegue il provisioning di cluster Tanzu Kubernetes Grid pronti per la produzione. È possibile eseguire carichi di lavoro di produzione senza la necessità di eseguire alcuna configurazione aggiuntiva. È inoltre possibile garantire la disponibilità e consentire aggiornamenti di software Kubernetes in sequenza ed eseguire versioni diverse di Kubernetes in cluster separati.
  • Alta disponibilità per i carichi di lavoro Kubernetes. I cluster Tanzu Kubernetes Grid distribuiti in un Supervisore a tre zone vSphere sono protetti dagli errori a livello del cluster vSphere. I nodi dei carichi di lavoro e dei piani di controllo dei cluster Tanzu Kubernetes Grid vengono distribuiti in tutte e tre le zone vSphere. I carichi di lavoro Kubernetes eseguiti in tali nodi sono quindi ad alta disponibilità. I cluster Tanzu Kubernetes Grid in esecuzione in un Supervisore a una zona sono protetti dagli errori a livello dell'host ESXi mediante vSphere HA.
  • Completamente supportato da VMware. I cluster Tanzu Kubernetes Grid utilizzano il sistema di VMware basato su Linux open source, sono distribuiti nell'infrastruttura di vSphere e vengono eseguiti negli host ESXi. Se si verificano problemi con uno qualsiasi dei livelli dello stack, dall'hypervisor al cluster Kubernetes, VMware è l'unico fornitore da contattare.
  • Gestito da Kubernetes. I cluster di Tanzu Kubernetes Grid sono creati al di sopra del Supervisore, che a sua volta è un cluster Kubernetes. Un cluster di Tanzu Kubernetes Grid viene definito nel Spazio dei nomi vSphere utilizzando una risorsa personalizzata. È possibile eseguire il provisioning dei cluster Tanzu Kubernetes Grid in modalità self-service utilizzando i comandi noti di kubectl e CLI di Tanzu. Il sistema degli strumenti è coerente, sia che si eseguito il provisioning di un cluster sia che si distribuiscano carichi di lavoro, si utilizzano gli stessi comandi, YAML conosciuti e workflow comuni.

Per ulteriori informazioni, vedere Architettura e componenti di Tanzu Kubernetes Grid e Utilizzo del servizio TKG con vSphere IaaS Control Plane.

Cos'è Pod vSphere?

vSphere IaaS control plane include un costrutto chiamato Pod vSphere, che equivale a un pod Kubernetes. Un Pod vSphere è una macchina virtuale con un footprint ridotto che esegue uno o più container Linux. Ogni Pod vSphere è dimensionato esattamente per il carico di lavoro che ospita e presenta prenotazioni di risorse esplicite per tale carico di lavoro. Esso alloca la quantità esatta di storage, memoria e risorse CPU necessarie per l'esecuzione del carico di lavoro. I Pod vSphere sono supportati solo con i Supervisori configurati con NSX come stack di rete.

Figura 3. Pod vSphere
Host ESXi contenente due caselle del pod vSphere. Ogni pod vSphere include contenitori in esecuzione al suo interno, un kernel Linux, una memoria, una CPU e risorse di storage.
I Pod vSphere sono oggetti in vCenter Server e abilitano le funzionalità seguenti per i carichi di lavoro:
  • Isolamento elevato. Un Pod vSphere è isolato allo stesso modo di una macchina virtuale. Ogni Pod vSphere ha il proprio kernel Linux univoco basato sul kernel utilizzato in Photon OS. Anziché molti container che condividono un kernel, come in una configurazione bare metal, in un Pod vSphere ciascun contenitore ha un kernel Linux univoco.
  • Gestione delle risorse. vSphere DRS gestisce il posizionamento dei Pod vSphere nel Supervisore.
  • Prestazioni elevate. I Pod vSphere ricevono lo stesso livello di isolamento delle risorse delle macchine virtuali, eliminando i problemi causati dai router adiacenti, mantenendo un rapido tempo di avvio e un ridotto sovraccarico dei container.
  • Diagnostica. L'amministratore di vSphere può utilizzare tutti gli strumenti di monitoraggio e analisi sui carichi di lavoro disponibili con vSphere.
I Pod vSphere sono compatibili con Open Container Initiative (OCI) e possono eseguire container da qualsiasi sistema operativo, purché anche questi contenitori siano compatibili con OCI.
Figura 4. Rete e storage di Pod vSphere
Il pod vSphere con contenitori, motore di contenitore e motore di pod all'interno. Il pod si connette all'immagine del contenitore, allo storage, al commutatore NSX, a spherelet e a hostd.

I Pod vSphere utilizzano tre tipi di storage in base agli oggetti archiviati, che sono VMDK temporanei, VMDK di volumi persistenti e VMDK delle immagini dei container. Un amministratore di vSphere configura i criteri di storage per il posizionamento della cache delle immagini dei container e dei VMDK temporanei a livello del Supervisore. A livello dello Spazio dei nomi vSphere, è possibile configurare criteri di storage per il posizionamento dei volumi persistenti. Vedere Storage persistente per i carichi di lavoro per i dettagli sui requisiti di storage e sui concetti relativi a vSphere IaaS control plane.

Per la rete, i Pod vSphere e le macchine virtuali dei cluster Tanzu Kubernetes Grid utilizzano la topologia fornita da NSX. Per i dettagli, vedere Rete di Supervisore.

Spherelet è un processo aggiuntivo che viene creato in ogni host. Si tratta di un kubelet per il quale è stato eseguito un porting nativo in ESXi e che consente all'host ESXi di diventare parte del cluster Kubernetes.

Per informazioni sull'utilizzo dei Pod vSphere in Supervisori, vedere Distribuzione dei carichi di lavoro in pod vSphere nella documentazione Servizi e carichi di lavoro di vSphere IaaS Control Plane.

Utilizzo delle macchine virtuali in vSphere IaaS control plane

vSphere IaaS control plane offre una funzionalità di servizio della macchina virtuale che consente ai tecnici di DevOps di distribuire ed eseguire macchine virtuali, oltre ai contenitori, in un ambiente Kubernetes condiviso e comune. Sia i container che le macchine virtuali condividono le stesse risorse Spazio dei nomi vSphere e possono essere gestiti tramite un'unica interfaccia di vSphere IaaS control plane.

Il servizio macchina virtuale risponde alle esigenze dei team DevOps che utilizzano Kubernetes ma hanno carichi di lavoro basati su macchine virtuali esistenti che non possono essere facilmente containerizzati. Consente inoltre agli utenti di ridurre il sovraccarico della gestione di una piattaforma non Kubernetes insieme a una piattaforma container. Quando si eseguono container e macchine virtuali in una piattaforma Kubernetes, i team DevOps possono consolidare il proprio footprint di carico di lavoro in un'unica piattaforma.

Nota: Oltre alle macchine virtuali autonome, il servizio macchina virtuale gestisce le macchine virtuali che costituiscono il cluster di Tanzu Kubernetes Grid. Per informazioni sui cluster, vedere la documentazione Utilizzo del servizio TKG con vSphere IaaS Control Plane.
L'illustrazione mostra il servizio delle macchine virtuali come supervisore componente che gestisce le macchine virtuali autonome e le macchine virtuali che costituiscono i cluster Tanzu Kubernetes Grid.

Ogni macchina virtuale distribuita tramite il servizio macchina virtuale funziona come una macchina completa che esegue tutti i componenti, incluso il proprio sistema operativo, al di sopra dell'infrastruttura di vSphere IaaS control plane. La macchina virtuale può accedere alla rete e allo storage forniti da un Supervisore ed è gestita utilizzando il comando kubectl standard di Kubernetes. La macchina virtuale viene eseguita come un sistema completamente isolato che è immune alle interferenze provenienti da altre macchine virtuali o carichi di lavoro nell'ambiente Kubernetes.

Quando utilizzare macchine virtuali su una piattaforma Kubernetes?

In genere, la decisione di eseguire i carichi di lavoro in un container o in una macchina virtuale dipende dalle esigenze e dagli obiettivi dell'azienda. Di seguito sono elencate le ragioni per cui sono utilizzate le macchine virtuali:

  • Le applicazioni non possono essere containerizzate.
  • Le applicazioni sono progettate per un kernel personalizzato o un sistema operativo personalizzato.
  • Le applicazioni sono più adatte all'esecuzione in una macchina virtuale.
  • Si desidera disporre di un'esperienza Kubernetes coerente ed evitare sovraccarico. Anziché eseguire set separati di infrastruttura per le piattaforme non Kubernetes e container, è possibile consolidare questi stack e gestirli con un comando di kubectl ben conosciuto.

Per informazioni sulla distribuzione e la gestione di macchine virtuali autonome nel Supervisore, vedere Distribuzione e gestione di macchine virtuali nella documentazione Servizi e carichi di lavoro di vSphere IaaS Control Plane.

Servizi supervisori in vSphere IaaS control plane

Servizi supervisori sono gli operatori Kubernetes certificati vSphere che forniscono i componenti Infrastructure as a Service e i servizi dei fornitori di software indipendenti strettamente integrati per gli sviluppatori. È possibile installare e gestire i Servizi supervisori nell'ambiente vSphere IaaS control plane in modo da renderli disponibili per l'uso con i carichi di lavoro Kubernetes. Quando i Servizi supervisori sono installati in Supervisori, gli ingegneri DevOps possono utilizzare le API del servizio di per creare istanze nei Supervisori nei relativi spazi dei nomi degli utenti. Queste istanze possono quindi essere utilizzate nei cluster Pod vSphere e Tanzu Kubernetes Grid.

Ulteriori informazioni sui Servizi supervisori supportati e su come scaricare i file YAML dei servizi sono disponibili all'indirizzo http://vmware.com/go/supervisor-service.

Per informazioni su come utilizzare i Servizi supervisori, vedere Gestione dei servizi supervisore nella documentazione Servizi e carichi di lavoro di vSphere IaaS Control Plane.