Note di rilascio di VMware vSphere IaaS Control Plane 8.0

Contenuto delle note di rilascio

Le note di rilascio contemplano i seguenti argomenti:

• Novità

• Installazione e aggiornamenti per questa versione

• Problemi noti

Novità

• Novità del 25 giugno 2024
• Novità del 26 marzo 2024
• Novità del 29 febbraio 2024
• Novità del 21 settembre 2023
• Novità del 27 luglio 2023
• Novità del 18 aprile 2023
• Novità del 30 marzo 2023
• Novità del 14 febbraio 2023
• Novità del 15 dicembre 2022
• Novità del 11 ottobre 2022

Novità del 25 giugno 2024

VMware vSphere 8.0 Update 3 | 25 GIU 2024  vCenter Server 8.0 Update 3 | 25 GIU 2024 | Build ISO 24022515 VMware ESXi 8.0 Update 3 | 25 GIU 2024 | Build ISO 24022510 VMware NSX Advanced Load Balancer avi-22.1.5 | 11 OTT 2023 HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0 Tanzu Kubernetes Grid 3.0 | 25 GIU 2024

In vSphere IaaS Control Plane 8.0 Update 3 sono disponibili le nuove funzionalità e i miglioramenti seguenti:

• Rotazione automatica dei certificati TKG e del supervisore: questa versione include un nuovo meccanismo di rotazione dei certificati. I certificati del supervisore e del cluster TKG vengono ruotati automaticamente prima della scadenza. Se la rotazione automatica non riesce, viene visualizzata una notifica nel vCenter e sarà necessario rinnovare i certificati manualmente.

• Supporto per il pod supervisore e vSphere e il cluster TKG nel cluster vSAN esteso: a partire da questa versione, è possibile configurare il supervisore per l'esecuzione in un cluster vSAN esteso. Questa configurazione è supportata solo in un ambiente greenfield. Questo significa che il cluster vSAN deve essere esteso e la gestione del carico di lavoro e la libreria di contenuti non sono ancora state configurate. Questi due componenti devono essere configurati con criteri di storage del cluster esteso vSAN. Per ulteriori informazioni, vedere la documentazione.

• La classe di macchine virtuali per le macchine virtuali del Servizio macchina virtuale è ora nell'ambito dello spazio dei nomi: in questa versione, quando si utilizza kubectl per elencare le classi di macchine virtuali, è possibile visualizzare solo le classi di macchine virtuali che hanno come ambito lo spazio dei nomi di vSphere specifico. In precedenza, le classi di macchine virtuali erano una risorsa con il cluster come ambito ed era difficile stabilire quali classi di macchine virtuali fossero assegnate e disponibili per uno spazio dei nomi specifico.

• Backup e ripristino del supervisore: il backup e il ripristino del supervisore sono ora supportati in vSphere. È ora possibile configurare i backup per un supervisore come parte di un backup vCenter e ripristinare un supervisore da un backup in caso di ripristino di emergenza, errore di aggiornamento, interruzione e altri scenari di ripristino. Vedere Backup e ripristino del piano di controllo del supervisore.

• Backup e ripristino della macchina virtuale del Servizio macchina virtuale: il backup e il ripristino delle macchine virtuali del Servizio macchina virtuale sono ora supportati in vSphere. Ora è possibile utilizzare qualsiasi fornitore di backup basato su VADP per proteggere le macchine virtuali del Servizio macchina virtuale. In caso di interruzione o di altri scenari che comportano la perdita di dati, è possibile ripristinare le macchine virtuali nello spazio dei nomi di vSphere da un backup.

• L'API dell'operatore macchina virtuale v1alpha2 è ora disponibile: la versione successiva dell'API dell'operatore della macchina virtuale è ora disponibile con il rilascio dell'operatore della macchina virtuale v1alpha2. Questa versione sblocca il supporto avanzato del provider di bootstrap, incluso il supporto per Cloud-Init e Windows inline, la configurazione avanzata dei servizi di rete guest, le funzionalità migliorate sullo stato, il supporto dei gate di preparazione definiti dall'utente, la nuova API VirtualMachineWebConsoleRequest, la documentazione dell'API migliorata e altre funzionalità. 

• Utilizzo di Fluent Bit per l'inoltro dei registri nel supervisore: è ora possibile inoltrare i registri del piano di controllo del supervisore e i registri di sistema a una piattaforma di monitoraggio dei registri esterna. Per ulteriori informazioni, vedere la documentazione.

• Supporto del registro privato per i servizi supervisore: è ora possibile definire i dettagli del registro privato che consentiranno ai carichi di lavoro distribuiti come servizio supervisore di estrarre immagini e pacchetti da un registro privato. Questo è un requisito comune per il supporto di un ambiente air gap. Per ulteriori informazioni, vedere la documentazione.

• Miglioramenti del workflow di aggiornamento del supervisore: è ora possibile avviare verifiche preliminari dell'aggiornamento del supervisore quando si avvia un aggiornamento della versione di Kubernetes del supervisore. Solo quando tutte le verifiche preliminari hanno esito positivo, viene eseguito l'aggiornamento effettivo. Questa versione consente di riprendere il processo di aggiornamento del componente dal punto in cui in precedenza non era riuscito. Per ulteriori informazioni, vedere Aggiornamento del supervisore.

• Supporto del supervisore per Kubernetes 1.28: in questa versione è stato aggiunto il supporto del supervisore per Kubernetes 1.28 ed è stato rimosso il supporto per Kubernetes 1.25.

Versioni di Kubernetes supportate per i supervisori:

Le versioni di Kubernetes supportate in questa versione sono 1.28, 1.27 e 1.26. I supervisori in esecuzione nella versione 1.25 di Kubernetes verranno aggiornati automaticamente alla versione 1.26 per garantire che tutti i supervisori siano in esecuzione in versioni di Kubernetes supportate.

Tanzu Kubernetes Grid Service for vSphere

• TKG Service come servizio supervisore: questa versione separa i componenti di TKG Service da vCenter e li include come servizio supervisore in un pacchetto che è possibile aggiornare e gestire indipendentemente dalle versioni di vCenter e del supervisore. Le note di rilascio di TKG Service sono disponibili qui.

• Supporto per la distribuzione dei cluster TKG Service in cluster vSAN estesi: questa versione supporta la distribuzione dei cluster TKG Service nella topologia del cluster esteso vSAN. Per ulteriori informazioni su come configurare HA per i cluster TKG Service in un cluster esteso vSAN, vedere la documentazione.

• Ridimensionamento automatico dei cluster TKG Service: questa versione supporta l'installazione del pacchetto di Cluster Autoscaler in un cluster TKG Service per abilitare la scalabilità orizzontale e verticale automatizzate dei nodi worker. 

• Backup e ripristino dei cluster TKG: questa versione supporta il backup e il ripristino del database del supervisore, che include l'oggetto spazio dei nomi di vSphere e le macchine virtuali del cluster TKG. Si tenga presente che il backup e il ripristino dei carichi di lavoro del cluster TKG devono essere eseguiti separatamente.

• Supporto per l'integrazione di Antrea-NSX e il servizio proxy di gestione NSX: questa versione supporta l'integrazione dei cluster TKG utilizzando la CNI di Antrea con NSX Manager per l'osservabilità e il controllo della rete del cluster.

• MachineHealthCheck configurabile: questa versione supporta la configurazione di MachineHealthCheck per i cluster v1beta1.

• Configurazione di PSA a livello di cluster: questa versione supporta la configurazione di PSA a livello di cluster durante la creazione o l'aggiornamento del cluster.

• Aggiornamenti dell'installazione del pacchetto standard: questa versione include gli aggiornamenti della documentazione per l'installazione del pacchetto standard nei cluster TKG Service. 

• Aggiornamenti dell'API v1beta1 per il provisioning dei cluster TKG: questa versione include le seguenti modifiche dell'API v1beta1:

  • Aggiunta di podSecurityStandard per l'implementazione di PSA a livello di cluster

  • Aggiornamento di controlPlaneCertificateRotation 

• Supporto per la scalabilità dei volumi dei nodi del piano di controllo per un cluster TKG.

Aggiornamenti dell'internazionalizzazione

A partire dalla prossima versione principale, verrà ridotto il numero di lingue di localizzazione supportate. Le tre lingue supportate saranno:

• Giapponese

• Spagnolo

• Francese

Le seguenti lingue non saranno più supportate:

• italiano, tedesco, portoghese brasiliano, cinese tradizionale, coreano, cinese semplificato

Impatto:

• Gli utenti che utilizzano le lingue deprecate non riceveranno più aggiornamenti o supporto in queste lingue.

• Tutte le interfacce utente, la documentazione di guida e l'assistenza clienti saranno disponibili solo in inglese o nelle tre lingue supportate menzionate sopra.

Novità del 26 marzo 2024

VMware vSphere 8.0 Update 2c | 26 MAR 2024  ESXi 8.0 Update 2b | 29 FEB 2024 | Build ISO 23305546 vCenter Server 8.0 Update 2c | 26 MAR 2024 | Build ISO 23504390 VMware NSX Advanced Load Balancer avi-22.1.5 | 11 OTT 2023 HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0 Tanzu Kubernetes Grid 2.2.0 | 18 MAG 2023

In vSphere IaaS Control Plane 8.0 Update 2c sono disponibili le nuove funzionalità e i miglioramenti seguenti:

Nuove funzionalità

• Supporto per TKr 1.27: questa versione include modifiche necessarie per supportare TKr 1.27 in vSphere 8.x, quando verrà rilasciato in futuro. Per informazioni, vedere le Note di rilascio delle versioni di VMware Tanzu Kubernetes.

• Supporto per l'aggiornamento da vCenter 7.x a vCenter 8.x: per gli utenti che eseguono TKr 1.27.6 vSphere 7.x, questa versione fornisce un percorso per l'aggiornamento a vCenter 8.x. In precedenza, TKr 1.27.6 rilasciato per vSphere 7.x non era compatibile con vCenter 8.x. Consulta l'articolo della Knowledge Base 96501.

Problemi risolti

• Dopo l'aggiornamento a vCenter 8.0 Update 2b, è possibile che il wcp del servizio gestito da vmon si trovi nello stato STOPPED e che l'installazione delle patch nel vCenter non riesca.

• Se si scollega una libreria o si elimina uno spazio dei nomi con una libreria condivisa, gli elementi associati vengono eliminati dalla libreria di contenuti.

Novità del 29 febbraio 2024

VMware vSphere 8.0 Update 2b | 29 FEB 2024  ESXi 8.0 Update 2b | 29 FEB 2024 | Build ISO 23305546 vCenter Server 8.0 Update 2b | 29 FEB 2024 | Build ISO 23319993 VMware NSX Advanced Load Balancer avi-22.1.5 | 11 OTT 2023 HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0 Tanzu Kubernetes Grid 2.2.0 | 18 MAG 2023

In vSphere IaaS Control Plane 8.0 Update 2b sono disponibili le nuove funzionalità e i miglioramenti seguenti:

Nuove funzionalità

• Supporto per la configurazione delle classi di macchine virtuali del Servizio macchina virtuale tramite vSphere Client: il Servizio macchina virtuale nel supervisore supporta la distribuzione di macchine virtuali con qualsiasi configurazione attualmente supportata con le macchine virtuali vSphere. Per configurare CPU, memoria, hardware, dispositivi di sicurezza e dispositivi passthrough per le classi di macchine virtuali, è ora possibile utilizzare la procedura guidata per le classi di macchine virtuali in vSphere Client. Utilizzando vSphere Client, è possibile semplificare il processo di definizione e gestione delle macchine virtuali del Servizio macchina virtuale utilizzate per l'esecuzione dei carichi di lavoro AI/ML.

• I supervisori supportano l'impostazione del cloud AVI: se si utilizza NSX Advanced Load Balancer, noto anche come Avi Load Balancer, è ora possibile configurare un cloud AVI per ogni supervisore. Ciò consente a più istanze di vCenter Server e data center di utilizzare una singola istanza di AVI, eliminando la necessità di configurare un'istanza AVI per ogni vCenter Server o data center che distribuisce un supervisore.

• Supporto dell'accesso FQDN: per i cluster supervisore e TKG, è ora possibile sostituire l'IP nel kubeconfigs generato con un nome di dominio completo valido. Per garantire la corretta risoluzione del nome host, è necessario aggiungere il DNS del nome di dominio completo e l'indirizzo IP.

• I supervisori supportano Kubernetes 1.27: il supervisore ora supporta Kubernetes 1.27 e interrompe il supporto per Kubernetes 1.24.

Versioni del Kubernetes supportate

• Le versioni del Kubernetes supportate in questa versione sono 1.27, 1.26 e 1.25. I supervisori in esecuzione in Kubernetes 1.24 eseguiranno l'aggiornamento automatico alla versione 1.25 per garantire la compatibilità.

Aggiornamento a 8.0 Update 2b

L'aggiornamento da qualsiasi versione vSphere 8.x precedente alla versione 8.0 Update 2 alla versione 8.0 Update 2b avvierà un aggiornamento in sequenza di tutti i cluster TKGS con provisioning per propagare le seguenti modifiche:

• 8.0 Update 2 contiene modifiche per le TKR di vSphere 7 e vSphere 8 nel controller TKGS come parte della ClusterClass.

• Poiché i cluster TKGS dalla versione 1.23 e successive sono compatibili con 8.0 Update 2b, tutti i cluster TKGS verranno sottoposti a un aggiornamento in sequenza.

Problemi risolti

• Il processo di aggiornamento del supervisore si è bloccato al 20%.

Novità del 21 settembre 2023

VMware vSphere 8.0.2 | 21 SET 2023 ESXi 8.0.2 | 21 SET 2023 | Build 22380479 vCenter Server 8.0.2 | 21 SET 2023 | Build 22385739 VMware NSX Advanced Load Balancer avi-22.1.3 | 31 GEN 2023 HAProxy Community Edition 2.2.2, Data Plane API 2.1.0 Tanzu Kubernetes Grid 2.2.0 | 18 MAG 2023

In vSphere IaaS Control Plane 8.0 Update 2 sono disponibili le nuove funzionalità e i miglioramenti seguenti:

Supervisore

• Il servizio delle macchine virtuali ora supporta macchine virtuali con sistema operativo Windows, GPU e tutte le altre opzioni disponibili per le macchine virtuali vSphere tradizionali: il servizio delle macchine virtuali ora supporta la distribuzione di macchine virtuali con qualsiasi configurazione attualmente supportata con le macchine virtuali vSphere. In questo modo, il comportamento è uguale a quello delle macchine virtuali vSphere tradizionali ma solo per le macchine virtuali distribuite nell'infrastruttura IaaS (Infrastructure as a Service) nel supervisore. Ciò include il supporto per il provisioning delle macchine virtuali Windows insieme alle macchine virtuali Linux, nonché qualsiasi hardware, sicurezza, dispositivo, supporto personalizzato o multi-NIC e dispositivi passthrough supportati in vSphere. Ora è possibile eseguire il provisioning delle macchine virtuali dei carichi di lavoro utilizzando le GPU per supportare i carichi di lavoro AI/ML.

• Servizio immagini macchina virtuale: i team DevOps, gli sviluppatori e altri utenti delle macchine virtuali possono pubblicare e gestire le immagini delle macchine virtuali in modalità self-service utilizzando il servizio immagini della macchina virtuale. Il servizio consente agli utenti di pubblicare, modificare ed eliminare immagini utilizzando le API K8s all'interno di un registro immagini lo spazio dei nomi supervisore come ambito. Il servizio immagini macchina virtuale viene creato automaticamente in ogni regione CCS e in ogni progetto CCS e il popolamento delle immagini nel registro immagini viene eseguito in base all'utente e al livello di consumo, a livello globale o di progetto. Le immagini possono essere utilizzate per la distribuzione di macchine virtuali tramite il servizio macchina virtuale.

  Si noti che questa funzionalità introduce un nuovo formato per il nome dell'immagine della macchina virtuale. Per informazioni su come risolvere i potenziali problemi causati dalla modifica del nome, vedere Modifica nel formato del nome dell'immagine della macchina virtuale in vSphere 8.0 U2.

• Importazione ed esportazione della configurazione del supervisore: nelle versioni precedenti, l'attivazione del supervisore era un processo manuale che non consentiva il salvataggio di alcuna configurazione. Nella versione corrente, è ora possibile esportare e condividere la configurazione del supervisore con i peer in formato leggibile o all'interno di un sistema di controllo dell'origine, importare configurazioni in un nuovo supervisore e replicare una configurazione standard in più supervisori. Per informazioni dettagliate su come esportare e importare la configurazione del supervisore, consultare la documentazione.

• Miglioramento dell'utilizzo della GPU riducendo la frammentazione : il posizionamento dei carichi di lavoro è ora sensibile alla GPU e DRS tenterà di posizionare i carichi di lavoro con requisiti di profilo simili nello stesso host. Ciò migliora l'utilizzo delle risorse, riducendo i costi in quanto è necessario acquisire meno risorse hardware della GPU per ottenere il livello di prestazioni desiderato.

• Il supervisore supporta Kubernetes 1.26: in questa versione è stato aggiunto il supporto per Kubernetes 1.26 ed è stato rimosso il supporto per Kubernetes 1.23. Le versioni di Kubernetes supportate in questa versione sono 1.26, 1.25 e 1.24. I supervisori in esecuzione nella versione 1.23 di Kubernetes verranno aggiornati automaticamente alla versione 1.24 per garantire che tutti i supervisori siano in esecuzione nelle versioni supportate di Kubernetes.

• Supporto di NSX Advanced Load Balancer per un supervisore configurato con rete NSX: ora è possibile abilitare un supervisore con NSX Advanced Load Balancer (Avi Networks) per il bilanciamento del carico L4, nonché il bilanciamento del carico per i nodi del piano di controllo dei cluster supervisore e Tanzu Kubernetes Grid con rete NSX. Per istruzioni sulla configurazione di NSX Advanced Load Balancer con NSX, consultare la pagina della documentazione.

• Supporto di Telegraf per lo streaming di metriche ed eventi: ora è possibile configurare Telegraf tramite API Kubernetes per eseguire il push delle metriche del supervisore in tutti i servizi di metriche compatibili con la versione di Telegraf incorporata. Per configurare Telegraf, vedere la documentazione.

Tanzu Kubernetes Grid nel supervisore

• Conformità STIG per i TKR in vSphere 8.0: con vSphere U2, tutti i cluster Tanzu Kubernetes Grid superiori alla versione 1.23.x sono conformi a STIG (Guida all'implementazione tecnica della sicurezza) e la documentazione delle eccezioni è disponibile qui. Questi miglioramenti rappresentano un passo significativo verso la semplificazione del processo di conformità e consentono di soddisfare i requisiti di conformità in modo molto più semplice, così che sia possibile utilizzare Tanzu Kubernetes Grid in modo rapido e sicuro nel mercato federale degli Stati Uniti e in altri settori industriali regolamentati.

• Attivazione dell'implementazione del piano di controllo per i certificati in scadenza: l'API v1beta1 per il provisioning dei cluster TKG in base a una ClusterClass è stata aggiornata per consentire ai cluster di rinnovare automaticamente i certificati della macchina virtuale dei nodi del piano di controllo prima della scadenza. Questa configurazione può essere aggiunta come variabile alla specifica del cluster. Fare riferimento alla

  documentazione dell'API v1beta1 del cluster per ulteriori informazioni.

• Supporto degli snapshot CSI per i TKR: i cluster TKG il cui provisioning viene eseguito da Tanzu Kubernetes versione 1.26.5 o successive supportano gli snapshot dei volumi CSI consentendo di soddisfare i requisiti di protezione dei dati. Gli snapshot dei volumi offrono una procedura standard per copiare il contenuto di un volume in un momento specifico senza creare un volume completamente nuovo. 

• Installazione e gestione dei pacchetti Tanzu: nuove funzionalità di repository e pubblicazione consolidate per l'installazione e la gestione dei pacchetti Tanzu nei cluster TKG. Per informazioni sui requisiti dei pacchetti, fare riferimento alla pubblicazione "Installazione e utilizzo dei pacchetti di VMware Tanzu".

• Miglioramenti della ClusterClass personalizzata: il workflow per l'implementazione di cluster ClusterClass personalizzati è semplificato per vSphere 8 U2.

• Aggiornamenti in sequenza per i cluster TKG: quando si esegue l'aggiornamento a vSphere 8 U2, è possibile che vengano eseguiti aggiornamenti in sequenza per i cluster TKG con provisioning negli scenari seguenti:

  • Quando si esegue l'aggiornamento da una versione di vSphere 8 rilasciata in precedenza a vSphere 8 U2, perché:

    • vSphere 8 U2 contiene modifiche di STIG a livello di Kubernetes per i TKR come parte della classe del cluster

    • I cluster TKG con versione 1.23 o successiva verranno sottoposti a un aggiornamento in sequenza per essere resi compatibili con v8.0 U2

  • Quando si esegue l'aggiornamento da una versione qualsiasi di vSphere 7 a vSphere 8 U2, perché:

    • I provider CAPI sottostanti devono essere spostati da CAPW a CAPV

    • I cluster esistenti devono essere migrati dai cluster CAPI senza classe ai cluster CAPI basati sulla classe

Problemi risolti

• I file di registro di controllo in /var/log/audit/ nelle macchine virtuali del piano di controllo del supervisore possono raggiungere dimensioni molto grandi e riempire il disco root. Nei registri journald sono presenti messaggi di errore di tipo "spazio esaurito nel dispositivo" che riflettono questo stato. Questo comportamento può causare la mancata riuscita di varie funzionalità del piano di controllo del supervisore (come le API kubernetes).

Novità del 27 luglio 2023

VMware vSphere 8.0.1c | 27 LUG 2023 ESXi 8.0.1c | 27 LUG 2023 | Build 22088125 vCenter Server 8.0.1c | 27 LUG 2023 | Build 22088981 VMware NSX Advanced Load Balancer avi-22.1.3 | 31 GEN 2023 HAProxy Community Edition 2.2.2, Data Plane API 2.1.0 Tanzu Kubernetes Grid 2.2.0 | 18 MAG 2023

Nuove funzionalità

• Il supervisore supporta Kubernetes 1.25: in questa versione è stato aggiunto il supporto per Kubernetes 1.25 ed è stato rimosso il supporto per Kubernetes 1.22.

• Tanzu Kubernetes Grid 2.2.0 nel supervisore : gestione dei cluster Tanzu Kubernetes Grid 2.2.0 nel supervisore.

Versioni del Kubernetes supportate

• Le versioni di Kubernetes supportate in questa versione sono 1.25, 1.24 e 1.23. I supervisori in esecuzione nella versione 1.22 di Kubernetes verranno aggiornati automaticamente alla versione 1.23 per garantire che tutti i supervisori siano in esecuzione nelle versioni supportate di Kubernetes.

Supporto

• Deprecazione della creazione di vRegistry: la creazione dell'istanza Harbor incorporata, ossia vRegistry, è deprecata. Le istanze di vRegistry esistenti continueranno a funzionare, ma la creazione di nuove istanze di vRegistry è deprecata. Le API di creazione di vRegistry sono state contrassegnate come obsolete e la possibilità di distribuire nuove istanze di vRegistry verrà rimossa in una versione futura. È invece consigliabile utilizzare Harbor come servizio supervisore per gestire le immagini e i repository dei container per migliorare le prestazioni e le funzionalità. Per eseguire la migrazione di vRegistry esistente a Harbor come servizio supervisore, vedere "Migrazione di immagini dal registro incorporato a Harbor" per i dettagli della migrazione.

Problemi risolti

• In vSphere Client verrà visualizzato un nuovo messaggio di avviso per avvisare della scadenza del certificato nei cluster supervisore o TKG. L'avviso fornirà informazioni dettagliate, tra cui il nome del supervisore e la data di scadenza del certificato. Conterrà inoltre un collegamento all'articolo KB 90627 che spiega in modo dettagliato come sostituire i certificati interessati.

• Il comando kubectl get clustervirtualmachineimages restituisce un errore o No resources found. Nelle versioni precedenti, quando si utilizzava il comando kubectl get clustervirtualmachineimages, si verificava un errore. Tuttavia, dopo l'aggiornamento a 8.0 Update 1c, il comando ora restituisce il messaggio seguente: No resources found. Per recuperare informazioni sulle immagini delle macchine virtuali, utilizzare invece il comando seguente: kubectl get virtualmachineimages

• La CNI con antrea-nsx-routed non funziona con i cluster Tanzu Kubernetes v1alpha3 nelle versioni vSphere IaaS Control Plane 8.x.

• Il timeout di svuotamento dei nodi non viene propagato correttamente per i cluster v1beta1.

Novità del 18 aprile 2023

VMware vSphere 8.0.1 | 18 APR 2023 ESXi 8.0.1 | 18 APR 2023 | Build 21495797 vCenter Server 8.0.1 | 18 APR 2023 | Build 21560480 VMware NSX Advanced Load Balancer avi-22.1.3 | 31 GEN 2023 HAProxy Community Edition 2.2.2, Data Plane API 2.1.0 Tanzu Kubernetes Grid 2.0 | 11 OTT 2022

Nuove funzionalità

Supervisore

• I Servizi supervisore sono ora disponibili nei supervisori basati su VDS: in precedenza, la disponibilità dei Servizi supervisore era limitata solo ai supervisori basati su NSX. Con la versione corrente è possibile distribuire Harbor, Contour, storage di oggetti S3 e servizi supervisore Velero nei supervisori basati su VDS. Nota: le funzionalità del servizio supervisore nei supervisori basati su VDS richiedono un aggiornamento di ESXi alla versione 8.0 U1.

• Supporto del servizio macchina virtuale per tutte le immagini Linux: ora è possibile utilizzare CloudInit per personalizzare qualsiasi immagine Linux in formato OVF conforme alla specifica dell'immagine del servizio macchina virtuale, nonché utilizzare i modelli OVF tramite vAppConfig per abilitare la distribuzione di immagini Linux legacy.

• Supporto della console Web per le macchine virtuali del servizio macchina virtuale: dopo aver distribuito una macchina virtuale del servizio macchina virtuale, un tecnico DevOps potrà avviare una sessione della console Web per tale macchina virtuale utilizzando la CLI kubectl per abilitare la risoluzione dei problemi e il debug nel sistema operativo guest senza coinvolgere l'amministratore di vSphere per ottenere l'accesso alla macchina virtuale guest.

• Conformità supervisore: Guide all'implementazione tecnica della sicurezza (STIG) per le versioni del supervisore vSphere IaaS Control Plane 8. Per informazioni dettagliate, vedere Protezione avanzata STIG di Tanzu.

Tanzu Kubernetes Grid 2.0 nel supervisore

• Classe di cluster personalizzata: creare una classe di cluster personalizzata per i cluster TKG nel supervisore. Per informazioni, vedere https://kb.vmware.com/s/article/91826.

• Immagine personalizzata per il nodo TKG: creare immagini dei nodi personalizzate utilizzando vSphere TKG Image Builder (Ubuntu e Photon).

  Nota: per utilizzare una TKR specifica con l'API v1alpha1, usare fullVersion.

• Nuove immagini TKR: Fare riferimento alle Note di rilascio di Tanzu Kubernetes per maggiori dettagli.

REQUISITO CRITICO per i clienti di vSphere IaaS Control Plane 8.0.0 GA

Nota: Questo requisito non si applica alle librerie di contenuti utilizzate per le macchine virtuali con provisioning effettuato tramite il servizio della macchina virtuale. Si applica solo alla libreria di contenuti TKR.

Se è stato distribuito vSphere IaaS Control Plane 8.0.0 GA, prima di eseguire l'aggiornamento a vSphere IaaS Control Plane 8 U1 è necessario creare una libreria di contenuti TKR temporanea per evitare un problema noto che causa il passaggio dei pod del controller TKG in CrashLoopBackoff quando viene eseguito il push dei TKR di TKG 2.0 nella libreria di contenuti esistente. Per evitare questo problema, completare i passaggi seguenti.

1. Creare una nuova libreria di contenuti con sottoscrizione con un URL di sottoscrizione temporaneo che punta a https://wp-content.vmware.com/v2/8.0.0/lib.json.

2. Sincronizzare tutti gli elementi nella libreria di contenuti temporanea.

3. Associare la libreria di contenuti temporanea a ogni spazio dei nomi di vSphere in cui è stato distribuito un cluster TKG 2.

4. Eseguire il comando kubectl get tkr e verificare che siano stati creati tutti i TKr.

5. A questo punto, il controller TKG deve trovarsi in uno stato di esecuzione, che è possibile verificare elencando i pod nello spazio dei nomi del supervisore.

6. Se lo stato del controller TKG è CrashLoopBackOff (CLBO), riavviare la distribuzione del controller TKG utilizzando il comando seguente:

   kubectl rollout restart deployment -n vmware-system-tkg vmware-system-tkg-controller-manager

7. Eseguire l'aggiornamento a vSphere IaaS Control Plane 8 Update 1.

8. Aggiornare ogni spazio dei nomi di vSphere in modo che utilizzi la libreria di contenuti con sottoscrizione originale all'indirizzo https://wp-content.vmware.com/v2/latest/lib.json.

Problemi risolti

• I cluster Tanzu Kubernetes Grid 2.0 forniti con l'API v1beta1 devono essere basati sulla ClusterClass predefinita

  Se si crea un cluster Tanzu Kubernetes Grid 2.0 in un supervisore utilizzando l'API v1beta1, il cluster deve essere basato sulla ClusterClass tanzukubernetescluster predefinita. Il sistema non riconcilia un cluster basato su una ClusterClass diversa.

Novità del 30 marzo 2023

ESXi 8.0.0c | 30 MAR 2023 | Build 21493926 vCenter Server 8.0.0c | 30 MAR 2023 | Build 21457384 VMware NSX Advanced Load Balancer avi-22.1.3 | 31 GEN 2023 HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0 Tanzu Kubernetes Grid 2.0 | 11 OTT 2022

Problemi risolti:

• Problema relativo alla configurazione predefinita non sicura di Harbor

  In questa versione è stato risolto il problema relativo alla configurazione predefinita non sicura di Harbor che si verifica se è stato abilitato il registro Harbor incorporato nel supervisore 7.0 o 8.0.

  Il problema è stato risolto in questa versione di vCenter, 8.0.0c. Vedere l'articolo 91452 della Knowledge Base di VMware per informazioni dettagliate su questo problema e su come risolverlo installando questa versione o applicando una soluzione temporanea.

• Dopo un aggiornamento a vCenter Server 8.0b, i tentativi di accesso a un cluster supervisore e TKG non riescono

  I componenti in esecuzione in vCenter Server 8.0b non sono compatibili con i supervisori distribuiti utilizzando vCenter Server nelle versioni precedenti.

  Soluzione: aggiornare vCenter Server a una versione più recente o aggiornare tutti i supervisori distribuiti.

Novità del 14 febbraio 2023

ESXi 8.0.0b | 14 FEB 2023 | Build 21203435 vCenter Server 8.0.0b | 14 FEB 2023 | Build 21216066 VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 15 LUGLIO 2022 HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0 Tanzu Kubernetes Grid 2.0 | 11 OTT 2022

Nuove funzionalità:

• Aggiunto il supporto dell'emittente del cluster CA Cert-Manager: consente agli amministratori di definire e distribuire un emittente CA con il cluster come ambito in un supervisore come servizio supervisore. La distribuzione di un'emittente CA con il cluster come ambito consente agli utenti che usano lo spazio dei nomi supervisore di richiedere e gestire i certificati firmati dall'emittente CA. 

Oltre a questa nuova funzionalità, la versione include correzioni di bug.

Problemi risolti:

• Il disco root delle macchine virtuali del piano di controllo del supervisore si riempie

  I file di registro di controllo in /var/log/audit/ nelle macchine virtuali del piano di controllo del supervisore possono raggiungere dimensioni molto grandi e riempire il disco root. Nei registri journald sono presenti messaggi di errore di tipo "spazio esaurito nel dispositivo" che riflettono questo stato. Questo comportamento può causare la mancata riuscita di varie funzionalità del piano di controllo del supervisore (come le API kubernetes).

  Il problema è stato risolto in questa versione, vSphere 8.0.0b

Novità del 15 dicembre 2022

ESXi 8.0 | 11 OTT 2022 | Build 20513097 vCenter Server 8.0.0a | 15 DIC 2022 | Build 20920323 VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 15 LUGLIO 2022 HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0 Tanzu Kubernetes Grid 2.0 | 11 OTT 2022

Nuove funzionalità

• Aggiunto Harbor come servizio supervisore: include un'istanza completa di Harbor (registro immagini OCI) in esecuzione nel supervisore. L'istanza di Harbor consente agli amministratori di Harbor di creare e gestire progetti e utenti, nonché di configurare la scansione delle immagini.

• Deprecazione di vRegistry: l'istanza di Harbor incorporata nota come vRegistry verrà rimossa in una versione futura. Al suo posto sarà possibile utilizzare Harbor come servizio supervisore. Per informazioni dettagliate sulla migrazione, vedere "Migrazione delle immagini dal registro incorporato ad Harbor".

• I supervisori supportano Kubernetes 1.24: in questa versione è stato aggiunto il supporto per Kubernetes 1.24 ed è stato rimosso il supporto per Kubernetes 1.21. Le versioni di Kubernetes supportate in questa versione sono 1.24, 1.23 e 1.22. I cluster supervisore in esecuzione nella versione 1.21 di Kubernetes vengono aggiornati automaticamente alla versione 1.22 per fare in modo che tutti i cluster supervisore vengano eseguiti nelle versioni supportate.

• API delle zone vSphere: una zona vSphere è un costrutto che consente di assegnare zone di disponibilità ai cluster vSphere per rendere i cluster supervisore e i cluster Tanzu Kubernetes ad alta disponibilità. In vSphere 8.0, la funzionalità di creazione e gestione delle zone vSphere era disponibile in vSphere Client. Con la versione vSphere 8.0.0a, gli utenti possono creare e gestire zone vSphere utilizzando DCLI o Esplora API di vSphere Client. Il supporto completo del binding SDK (ad esempio Java, Python e così via) sarà disponibile in una versione futura.

Considerazioni sull'aggiornamento:

• Un aggiornamento in sequenza dei cluster Tanzu Kubernetes si verificherà nei seguenti scenari di aggiornamento del supervisore:

  • Quando si esegue l'aggiornamento dalla versione 8.0 alla versione 8.0.0a seguito dall'aggiornamento di un supervisore da qualsiasi versione di Kubernetes a Kubernetes 1.24 del supervisore e quando viene soddisfatta una di queste condizioni.

    • Se si utilizzano impostazioni del proxy con un elenco noProxy non vuoto in un cluster Tanzu Kubernetes

    • Se vRegistry è abilitato nel supervisore. Questa configurazione è disponibile solo nei supervisori basati su NSX.

  • Quando si esegue l'aggiornamento da una versione di vSphere 7.0 a vSphere 8.0.0a.

Problemi risolti:

• In vSphere 8 sono supportate le chiavi di licenza di Tanzu 7 anziché le chiavi di licenza di Tanzu 8

  vCenter 8.0 supporta le chiavi di licenza di Tanzu 7 anziché le chiavi di licenza di Tanzu 8. Questo problema non impedisce di utilizzare completamente le funzionalità di Tanzu in vCenter 8.0. Per ulteriori dettagli, vedere l'articolo 89839 della Knowledge Base di VMware prima di modificare le licenze di Tanzu nella distribuzione di vCenter 8.0.

• I bilanciamenti del carico e i cluster guest non vengono creati quando sono presenti due gruppi SE in NSX-ALB.

  Se in NSX-ALB viene aggiunto un secondo gruppo SE con o senza SE o servizi virtuali assegnati, la creazione di nuovi cluster supervisore o guest non riesce e i cluster supervisore esistenti non possono essere aggiornati. La creazione del servizio virtuale nel controller NSX-ALB non riesce e viene visualizzato il seguente messaggio di errore:

  get() returned more than one ServiceEngineGroup – it returned 2

  Di conseguenza, i nuovi bilanciamenti del carico non sono utilizzabili e non è possibile creare correttamente nuovi cluster del carico di lavoro. Per ulteriori informazioni, vedere l'articolo 90386 della Knowledge Base di VMware.

Novità del 11 ottobre 2022

VMware vSphere 8.0 | 11 OTT 2022 ESXi 8.0 | 11 OTT 2022 | Build 20513097 vCenter 8.0 | 11 OTT 2022 | Build 20519528 VMware NSX Advanced Load Balancer 21.1.4 | 07 APR 2022 HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0 Tanzu Kubernetes Grid 2.0 | 11 OTT 2022

In vSphere IaaS Control Plane 8.0 sono disponibili le nuove funzionalità e i miglioramenti seguenti:

• Monitoraggio della configurazione della gestione del carico di lavoro: è ora possibile monitorare lo stato di attivazione, disattivazione e aggiornamento del supervisore in modo più dettagliato. Una volta avviata l'operazione di attivazione, disattivazione o aggiornamento, il supervisore tenta di raggiungere lo stato desiderato raggiungendo varie condizioni associate ai diversi componenti del supervisore, ad esempio le macchine virtuali del piano di controllo. È possibile monitorare lo stato di ogni condizione, visualizzare gli avvisi associati, riprovare lo stato, nonché visualizzare le condizioni raggiunte e i relativi timestamp.

• Zone vSphere: una zona vSphere è un nuovo costrutto che consente di assegnare zone di disponibilità ai cluster vSphere. La distribuzione di un supervisore nelle zone vSphere consente di eseguire il provisioning dei cluster Tanzu Kubernetes Grid in zone di disponibilità e domini di errore specifici. In questo modo, i carichi di lavoro possono estendersi in più cluster aumentando la resilienza agli errori hardware e software.

• Supervisore multi-cluster: utilizzando le zone vSphere è possibile distribuire un supervisore in più cluster vSphere per fornire alta disponibilità e domini di errore per i cluster Tanzu Kubernetes Grid. È possibile aggiungere un cluster vSphere a una zona vSphere separata e attivare un supervisore che si estende in più zone vSphere. Questo fornisce failover e resilienza agli errori hardware e software localizzati. Quando una zona o un cluster vSphere passa alla modalità offline, il supervisore rileva l'errore e riavvia i carichi di lavoro in un'altra zona vSphere. È possibile utilizzare le zone vSphere in ambienti che si estendono su distanze purché non vengano superati i valori massimi di latenza. Per ulteriori informazioni sui requisiti della latenza, vedere Requisiti per la distribuzione del supervisor in zone.

• Il supervisore supporta Kubernetes 1.23: in questa versione è stato aggiunto il supporto per Kubernetes 1.23 ed è stato rimosso il supporto per Kubernetes 1.20. Le versioni di Kubernetes supportate in questa versione sono 1.23, 1.22 e 1.21. I supervisori in esecuzione nella versione 1.20 di Kubernetes verranno aggiornati automaticamente alla versione 1.21 per garantire che tutti i supervisori siano in esecuzione nelle versioni supportate di Kubernetes.

• Criteri di rete coerenti con le definizioni di risorse personalizzate (CRD) di SecurityPolicy: le definizioni di risorse personalizzate di SecurityPolicy offre la possibilità di configurare i controlli di sicurezza di rete per le macchine virtuali e i pod vSphere in uno spazio dei nomi supervisore.

• Tanzu Kubernetes Grid 2.0 nel supervisore - Tanzu Kubernetes Grid è ora passato alla versione 2.0. Tanzu Kubernetes Grid 2.0 rappresenta una grande innovazione nella community Tanzu e Kubernetes e fornisce le fondamenta per un insieme comune di interfacce tra cloud privati e pubblici con Tanzu Kubernetes Grid. Le novità di questa versione sono le due funzionalità principali:

  • ClusterClass: Tanzu Kubernetes Grid 2.0 ora supporta ClusterClass. ClusterClass fornisce un'interfaccia allineata con upstream che sostituisce il cluster Tanzu Kubernetes e offre funzionalità di personalizzazione alla piattaforma Tanzu Kubernetes Grid. ClusterClass consente agli amministratori di definire modelli che funzioneranno con i requisiti dell'ambiente aziendale riducendo la tariffa e abilitando la personalizzazione delegata.

  • Carvel: Carvel fornisce un set di strumenti di composizione affidabili e monouso che consentono di creare, configurare e distribuire le applicazioni a Kubernetes. In particolare, kapp e kapp-controller forniscono gestione dei pacchetti, compatibilità e ciclo di vita tramite un set di strumenti dichiarativi, allineati con upstream. In combinazione con ytt per la creazione di modelli, si ottiene una funzione di gestione dei pacchetti flessibile ma gestibile.

• Nuova struttura della documentazione e pagina di arrivo in vSphere 8: la documentazione di vSphere IaaS Control Plane ora ha una struttura migliorata che riflette meglio i workflow con il prodotto e consente un'esperienza più incentrata sui contenuti. È anche possibile accedere a tutta la documentazione tecnica disponibile per vSphere IaaS Control Plane dalla nuova pagina di arrivo della documentazione.

Installazione e aggiornamenti per questa versione

Consultare la documentazione Installazione e configurazione di vSphere IaaS Control Plane per istruzioni sull'installazione e la configurazione di vSphere IaaS Control Plane. Per informazioni sull'aggiornamento di vSphere IaaS Control Plane, vedere la documentazione Aggiornamento di vSphere IaaS Control Plane.

Quando si eseguono gli aggiornamenti, tenere presente quanto segue:

• Prima di eseguire l'aggiornamento alla versione vCenter Server 8.0, assicurarsi che la versione di Kubernetes di tutti i supervisori sia almeno 1.21, preferibilmente la versione più recente supportata. La versione di rilascio di Tanzu Kubernetes dei cluster Tanzu Kubernetes Grid deve essere 1.21, preferibilmente la versione più recente supportata.

• Gli aggiornamenti da TKGS TKr legacy a TKG 2 TKr sono consentiti a partire dalla versione vSphere IaaS Control Plane 8.0 MP1. Per la matrice delle versioni supportate, fare riferimento alle note di rilascio di Tanzu Kuberentes. Per informazioni sull'aggiornamento, fare riferimento alla documentazione Uso di TKG nel supervisore con vSphere IaaS Control Plane.

Problemi noti

• Problemi noti del supervisore
• Problemi noti di TKG nel supervisore
• Problemi noti di rete
• Problemi noti dello storage

Problemi noti del supervisore

• In vSphere 8.0 Update 3 le opzioni di sostituzione della rete non sono più presenti nella pagina di creazione dello spazio dei nomi di vSphere

  Nelle versioni precedenti alla 8.0 Update 3, un amministratore di vSphere può specificare una configurazione di rete personalizzata anziché la configurazione di rete predefinita utilizzata quando viene creato uno spazio dei nomi di vSphere. Nella versione 8.0 Update 3, l'opzione dell'interfaccia utente per sostituire la configurazione di rete non è disponibile.

  Soluzione: per creare lo spazio dei nomi di vSphere con una configurazione di rete personalizzata, è possibile utilizzare DCLI.

• Occasionalmente, è possibile che gli host ESXi non vengano inseriti in un cluster supervisore perché il modulo vds-vsip non può essere caricato

  Quando gli host ESXi non vengono inseriti in un cluster supervisore, è possibile che nel file di registro degli host ESXi venga visualizzato il messaggio di errore seguente /var/run/log/spherelet.log:

  cannot load module vds-vsip: cmd '/bin/vmkload_mod /usr/lib/vmware/vmkmod/vds-vsip' failed with status 1: stderr: '', stdout:'vmkmod: VMKModLoad: VMKernel_LoadKernelModule(vds-vsip): Failure\nCannot load module /usr/lib/vmware/vmkmod/vds-vsip: Failure\n'

  Questo problema può verificarsi durante un aggiornamento del cluster supervisore, un aggiornamento del certificato o qualsiasi altra modifica della configurazione del supervisore che causa il riavvio di Spherelet.

  Soluzione: riavviare gli host ESXi in cui non è possibile caricare il modulo vds-vsip.

• I tentativi di aggiornare l'ambiente del piano di controllo di vSphere IaaS dalla versione 7.0 Update 3o alla versione 8.0 Update 3 con un supervisore che utilizza macchine virtuali del piano di controllo di tipo Molto piccola non riescono e viene visualizzato un messaggio di errore

  Dopo aver aggiornato vCenter dalla versione 7.0 Update 3o alla versione 8.0 Update 3, il supervisore configurato con macchine virtuali del piano di controllo di tipo Molto piccola non può eseguire l'aggiornamento da Kubernetes v1.26.8 alla versione v1.27.5.

  È possibile che vengano visualizzati i messaggi di errore seguenti: Waiting for deployment \"snapshot-validation-deployment\" rollout to finish: 2 out of 3 new replicas have been updated...'kubectl get pods' in namespaces starting with the name 'vmware-system-' show pods in OutOfCpu state.

  Soluzione: prima dell'aggiornamento, aumentare le dimensioni delle macchine virtuali del piano di controllo da Molto piccola a Piccola o maggiori. Vedere Modifica delle dimensioni del piano di controllo di un supervisore.

• Dopo aver aggiornato vCenter e l'ambiente del piano di controllo di vSphere IaaS a vSphere 8.0 U3, i tentativi di creazione di pod vSphere non riescono se il supervisore utilizza la versione 1.26 di Kubernetes

  Dopo aver aggiornato l'ambiente a vSphere 8.0 U3 e il supervisore alla versione 1.26 di Kubernetes, le operazioni di creazione di pod vSphere non riescono mentre il sistema tenta di estrarre l'immagine. È possibile che venga visualizzato il messaggio di errore failed to configure device eth0 with dhcp: getDHCPNetConf failed for interface anche se il cluster è abilitato con rete statica.

  Soluzione: aggiornare il supervisore e il piano di controllo di vSphere IaaS alla versione 1.27 o successiva di Kubernetes.

• Occasionalmente, quando si tenta di eliminare uno snapshot di volume eseguendo contemporaneamente un'operazione di ripristino di PVC, le operazioni non vengono completate a causa di dipendenze interne

  I problemi possono verificarsi nelle circostanze seguenti. Si avvia un'operazione di ripristino per uno snapshot di volume e l'operazione di ripristino richiede più tempo per essere completata o viene riprovata per motivi interni diversi. Nel frattempo, si attiva l'eliminazione dello snapshot di origine. Di conseguenza, le operazioni sono in conflitto e rimangono incomplete. L'eliminazione dello snapshot continua a non riuscire a causa dell'operazione di ripristino in corso per questo snapshot, mentre l'operazione di ripristino non viene avviata perché è stata attivata l'eliminazione dello snapshot.

  Soluzione: per risolvere questo problema, è necessario eliminare il PVC ripristinato per interrompere l'operazione di ripristino e consentire il completamento dell'operazione di eliminazione dello snapshot. In questo caso, i dati dello snapshot andranno persi e non potranno essere ripristinati perché lo snapshot viene eliminato dopo l'eliminazione del PVC ripristinato.

• Le macchine virtuali del servizio macchina virtuale non possono utilizzare PVC in cui il parametro volumeBindingMode nella classe di storage è impostato su WaitForFirstConsumer

  Quando si utilizza questo tipo di PVC per le macchine virtuali del servizio macchina virtuale, si verificano errori e comportamenti imprevisti. Ad esempio, viene visualizzato il messaggio di errore Waiting for first consumer to be created before binding.

  Soluzione: le macchine virtuali del servizio macchina virtuale supportano PVC con volumeBindingMode immediato nella classe di storage, ma non supportano WaitForFirstConsumer.

• Un nuovo modello di licenza modifica il comportamento di NSX Container Plugin (NCP) nell'ambiente del piano di controllo di VMware vSphere IaaS

  Nella versione 8.0 Update 3, la licenza di NSX Distributed Firewall (DFW) viene offerta come licenza di componente aggiuntivo separata. Senza questa licenza, NCP nell'ambiente del piano di controllo di VMware vSphere IaaS modificherà le regole DFW in NSX causando un comportamento imprevisto.

  Ad esempio, senza la licenza DFW, i nuovi criteri di sicurezza e di rete creati per il piano di controllo di VMware vSphere IaaS non funzionano perché NCP non può aggiungere regole in NSX Manager. Inoltre, le risorse come i pod in uno spazio dei nomi appena creato possono essere raggiungibili da un altro spazio dei nomi. Con la licenza DFW, uno spazio dei nomi appena creato non deve invece essere accessibile da un altro spazio dei nomi per impostazione predefinita.

  Soluzione: la licenza di NSX Distributed Firewall (DFW) viene offerta come licenza di componente aggiuntivo separata in NSX Manager. Per evitare problemi, aggiungere la licenza in NSX Manager.

• Velero vSphere Operator viene installato correttamente, ma è possibile che i tentativi di creare un'istanza di Velero non riescano

  Velero vSphere Operator distribuisce i propri pod operatore nelle macchine virtuali del piano di controllo, mentre le istanze di Velero vengono distribuite come pod vSphere.

  Il problema di distribuzione può verificarsi quando vCenter viene aggiornato alla versione 8.x e il supervisore utilizza la rete VDS. Tuttavia, gli host ESXi per tale supervisore non sono stati aggiornati e utilizzano una versione asincrona precedente alla 8.x. In questo scenario, gli host ESXi non possono distribuire pod vSphere. Di conseguenza, mentre Velero vSphere Operator viene installato correttamente, non riesce a creare un'istanza di Velero quando l'amministratore tenta di utilizzarla.

  Soluzione: per assicurarsi che il servizio supervisore di Velero funzioni correttamente, è innanzitutto necessario aggiornare ESXi alla versione 8.x, quindi aggiornare vCenter e il supervisore alla stessa versione 8.x.

• Il pod dell'operatore della macchina virtuale si arresta in modo anomalo a causa di risorse insufficienti su larga scala

  Se le risorse della macchina virtuale stanno impiegando molto tempo per essere realizzate su larga scala, ad esempio migliaia di macchine virtuali, è possibile che si verifichi un arresto anomalo del pod dell'operatore della macchina virtuale a causa di memoria insufficiente.

  Soluzione: per la soluzione e ulteriori informazioni, vedere l'articolo 88442 della Knowledge Base.

• Dopo l'aggiornamento a vCenter 8.0 Update 2b, è possibile che il wcp del servizio gestito da vmon si trovi nello stato STOPPED e che l'installazione delle patch nel vCenter non riesca

  Questo problema si verifica solo quando si aggiorna vCenter 8.0 Update 1 o versione successiva a vCenter 8.0 Update 2b e si dispone di almeno un supervisore che utilizza la topologia dei servizi di rete VDS e Kubernetes 1.24.

  Soluzione: Per evitare questo problema, aggiornare il supervisore a Kubernetes 1.25 o versione successiva prima di aggiornare vCenter alla versione 8.0 Update 2b. Per ulteriori informazioni, rivolgersi all'assistenza clienti.

• Le operazioni supervisore non riescono quando le dimensioni dei certificati di vCenter personalizzati sono maggiori di 8K

  In vSphere 8.0 Update 2b, le dimensioni massime della chiave di una richiesta CSR in un sistema vCenter sono ridotte a 8192 bit da 16384 bit. Quando le dimensioni della chiave del certificato superano 8192 bit, è possibile che si verifichi un comportamento imprevedibile delle operazioni del supervisore. Ad esempio, operazioni come l'abilitazione o l'aggiornamento del supervisore potrebbero non riuscire.

  Soluzione:

  Rigenerare qualsiasi certificato vCenter con una chiave di dimensioni superiori a 8192 bit.

  1. Identificare tutti i certificati con dimensioni chiave maggiori di 8192 bit.

     for store in TRUSTED_ROOTS MACHINE_SSL_CERT vpxd-extension wcp ; do echo $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store "$store" --text | grep Public-Key; done

  2. Sostituire tutti i certificati la cui dimensione della chiave è superiore a 8192 bit.

  3. Registrare nuovamente vCenter in NSX (se si utilizza NSX).

  4. Riavviare il servizio WCP.

  Per ulteriori informazioni, vedere l'articolo della Knowledge base96562.

• I modelli potrebbero essere eliminati dalla libreria di contenuti in vCenter quando la libreria è collegata a più spazi dei nomi vSphere

  È possibile osservare questo problema quando una libreria è collegata a più spazi dei nomi in vSphere IaaS Control Plane e la libreria è scollegata da uno spazio dei nomi oppure viene eliminato uno spazio dei nomi.

  Soluzione:

  Evitare di utilizzare una libreria locale se si desidera collegare la libreria a più spazi dei nomi. Creare invece una libreria pubblicata in vCenter e caricare tutti i modelli nella libreria pubblicata. Creare quindi una libreria con sottoscrizione che sincronizzi i modelli della libreria pubblicata nello stesso vCenter e colleghi questa libreria con sottoscrizione a più spazi dei nomi. In questo caso, anche quando una libreria viene scollegata da uno spazio dei nomi o viene eliminato uno spazio dei nomi, gli elementi della libreria non verranno eliminati da vCenter.

• Si verificano errori quando si utilizzano le REST API di VMware vSphere Automation per creare o aggiornare una classe di macchine virtuali e includere campi numero intero in configSpec

  È possibile osservare i seguenti errori quando configSpec include campi numero intero, ad esempio numCPU o memoryMB:

  Unknown error - vcenter.wcp.vmclass.configspec.invalid: json: unsupported discriminator kind: struct.

  Unknown error - vcenter.wcp.vmclass.configspec.invalid: json: cannot unmarshal string into Go struct field VirtualMachineConfigSpec.<fieldName> of type int32.

  Questo problema si verifica a causa di un problema noto nell'endpoint VAPI che analizza il file JSON CONFIGSpec REST non elaborato con numeri interi e passa i numeri interi come stringhe, causando errori. Il problema si verifica solo quando si utilizzano le REST API tramite il Centro sviluppatori VMware.

  Soluzione: Anziché le REST API, utilizzare DCLI o vSphere Client per creare o aggiornare le classi di macchine virtuali.

  In alternativa, è possibile utilizzare vSphere Automation SDK per python/java. Nel seguente esempio viene illustrato come utilizzare il servizio di transcoder del protocollo pubblico per convertire un oggetto VirtualMachineConfigSpec (vim.vm.ConfigSpec) ottenuto da vCenter utilizzando pyvmomi. L'ultima voce dell'esempio mostra come analizzare un file JSON creato manualmente. L'oggetto può quindi essere inviato all'API VirtualMachineClasses.

• Dopo aver applicato una licenza vSphere VMware Foundation valida a un supervisore, la pagina Gestione carico di lavoro continua a mostrare la licenza di valutazione precedente con un avviso di scadenza

  È possibile riscontrare questo problema se il supervisore è abilitato con una licenza di valutazione e si applica la licenza di vSphere VMware Foundation al supervisore. Tuttavia, la nuova licenza non viene visualizzata nella pagina Gestione carico di lavoro in vSphere Client in vCenter > Gestione carico di lavoro > Supervisori > Supervisore. vSphere Client continua a mostrare l'avviso con la data di scadenza della licenza di valutazione precedente anche se la nuova chiave di licenza è stata applicata correttamente.

  Soluzione: nessuna. La nuova licenza viene visualizzata correttamente in vSphere Client in Amministrazione > Licenze > Asset > Supervisori.

• L'aggiornamento della regola del criterio di sicurezza nel CRD del criterio di sicurezza non viene applicata se la regola aggiunta o eliminata non è l'ultima

  In qualità di DevOps, è possibile configurare il CRD del criterio di sicurezza per applicare un criterio di sicurezza basato su NSX a uno spazio dei nomi del cluster supervisore. Quando si aggiorna il CRD e si aggiunge o si elimina una regola del criterio di sicurezza, la regola aggiornata non viene applicata a meno che non sia l'ultima regola nell'elenco delle regole.

  Soluzione: aggiungere la regola alla fine dell'elenco di regole oppure utilizzare un criterio di sicurezza separato per l'aggiunta o l'eliminazione della regola.

• Le modifiche al formato del nome dell'immagine della macchina virtuale in vSphere 8.0 U2 possono causare problemi quando si utilizzano nomi di immagini di macchine virtuali precedenti

  Prima di vSphere 8.0 Update 2, il nome di una risorsa di immagine della macchina virtuale derivava dal nome di un elemento della libreria di contenuti. Ad esempio, se un elemento della libreria di contenuti era denominato photonos-5-x64, anche la risorsa VirtualMachineImage corrispondente veniva denominata photonos-5-x64. Ciò ha causato problemi quando gli elementi di librerie diverse avevano gli stessi nomi.

  In vSphere 8.0 Update 2, è stato introdotto il servizio immagini delle macchine virtuali per gestire le immagini delle macchine virtuali in modalità self-service. Vedere Creazione e gestione delle librerie di contenuti per le macchine virtuali autonome in vSphere IaaS Control Plane.

  Questa nuova funzionalità consente di associare le librerie di contenuti a uno spazio dei nomi o all'intero cluster supervisore e richiede che i nomi delle risorse delle immagini delle macchine virtuali nei cluster Kubernetes siano univoci e deterministici. Di conseguenza, per evitare potenziali conflitti con i nomi degli elementi della libreria, le immagini delle macchine virtuali seguono ora il nuovo formato di denominazione vmi-xxx. Tuttavia, questa modifica può causare problemi nella versione vSphere 8.0 Update 2 se si utilizzano file YAML di macchine virtuali precedenti che fanno riferimento ai nomi di immagini precedenti, ad esempio photonos-5-x64 o centos-stream-8.

  Soluzione:

  1. Utilizzare i comandi seguenti per recuperare informazioni sulle immagini delle macchine virtuali:

     • Per visualizzare le immagini associate ai rispettivi spazi dei nomi, eseguire kubectl get vmi -n <namespace>.

     • Per recuperare le immagini disponibili nel cluster, eseguire kubectl get cvmi.

  2. Dopo aver ottenuto il nome della risorsa immagine elencato nella colonna NAME, aggiornare il nome nella specifica di distribuzione della macchina virtuale.

• Durante un aggiornamento automatico del supervisore, il processo del servizio WCP in vSphere può causare un errore grave e un arresto imprevisto

  È possibile notare un file dump principale generato per il processo del servizio WCP.

  Soluzione: nessuna. Il processo VMON riavvia automaticamente il servizio WCP e il servizio WCP riprende l'aggiornamento senza ulteriori problemi.

• L'aggiornamento del supervisore viene sospeso con ErrImagePull e stato Non riuscito del provider nei pod vSphere. È possibile che i volumi persistenti collegati ai pod vSphere (inclusi i servizi supervisori) non possano essere scollegati in caso di errori ErrImagePull.

  È possibile che i volumi persistenti non possano essere scollegati in caso di errore dei pod vSphere con ErrImagePull. Ciò può causare una cascata di pod vSphere non riusciti perché i volumi persistenti necessari sono collegati all'istanza non riuscita. Durante l'aggiornamento del supervisore, è possibile che i pod vSphere nel supervisore passino allo stato provider failed e che quindi non rispondano.

  Soluzione: eliminare le istanze dei pod vSphere non riusciti a cui sono collegati volumi persistenti. È importante tenere presente che le richieste di volume persistente (PVC) e i volumi persistenti associati ai pod vSphere possono essere conservati. Dopo aver completato l'aggiornamento, ricreare i pod vSphere utilizzando lo stesso PodSpecPVC per mantenere l'integrità dei dati e la funzionalità. Per ovviare a questo problema, creare pod vSphere utilizzando ReplicaSets (DaemonSet, Distribuzione) per mantenere un set di pod vSphere di replica stabile in esecuzione in qualsiasi momento.

• L'aggiornamento del supervisore è bloccato al 50% e l'aggiornamento di Pinniped non riesce a causa della selezione del leader

  I pod Pinniped sono bloccati con stato in sospeso durante il rollout e l'aggiornamento del supervisore non riesce durante l'aggiornamento del componente Pinniped.

  I passaggi per risolvere il problema sono:

  1. Eseguire kubectl get pods -n vmware-system-pinniped per verificare lo stato dei pod Pinniped.

  2. Eseguire kubectl get leases -n vmware-system-pinniped pinniped-supervisor -o yaml per verificare che holderIdentity non sia uno dei pod Pinniped con stato in sospeso.

  3. Eseguire kubectl delete leases -n vmware-system-pinniped pinniped-supervisor per rimuovere l'oggetto lease per il supervisore Pinniped che ha un pod inattivo come holderIdentity.

  4. Eseguire di nuovo kubectl get pods -n vmware-system-pinniped per verificare che tutti i pod in vmware-system-pinniped siano attivi e in esecuzione.

• Non è possibile attivare la modalità di manutenzione del nodo host ESXi quando la macchina virtuale del piano di controllo del supervisore è accesa

  Nella configurazione di un supervisore con NSX Advanced Load Balancer, l'attivazione della modalità di manutenzione dell'host ESXi non riesce se la macchina virtuale del motore di servizio AVI è accesa. Questo influisce sull'aggiornamento dell'host ESXi e di NSX con la modalità di manutenzione.

  Soluzione: spegnere la macchina virtuale del motore di servizio AVI in modo che sia possibile attivare la modalità di manutenzione di ESXi.

• Non è possibile ricevere il traffico in loop utilizzando ClusterIP con pod vSphere in VDIS

  Se un'applicazione in un pod vSphere tenta di raggiungere un ClusterIP incluso nello stesso pod vSphere (in un container diverso), DLB all'interno di VSIP non è in grado di instradare il traffico di nuovo al pod vSphere.

  Soluzione: nessuna.

• I criteri di rete non vengono applicati in un supervisore basato su VDS

  Il codice YAML del servizio esistente che utilizza NetworkPolicy non richiede alcuna modifica. NetworkPolicy non verrà applicato se è presente nel file.

  Soluzione: è necessario impostare regole basate su criteri nella rete per VDS. Per il supporto di NetworkPolicy, è necessario il supporto della rete di NSX.

• È possibile che lo spazio dei nomi di un servizio Carvel continui a essere visualizzato in vSphere Client dopo aver disinstallato il servizio dal supervisore

  Se la disinstallazione del servizio Carvel dal supervisore impiega più di 20 minuti, è possibile che lo spazio dei nomi venga visualizzato in vSphere Client anche dopo che è stato disinstallato.

  I tentativi di reinstallazione del servizio nello stesso supervisore non riescono finché lo spazio dei nomi non viene eliminato. E durante la reinstallazione viene visualizzato il messaggio ns_already_exist_error.

  Nel file di registro viene visualizzata la voce seguente:

  /var/log/vmware/wcp/wcpsvc.log should have the message - "Time out for executing post-delete operation for Supervisor Service with serviceID '<service-id>' from cluster '<cluster-id>'. Last error: <error>"

  Soluzione: eliminare manualmente lo spazio dei nomi da vSphere Client.

  1. Dal menu home di vSphere Client selezionare Gestione carico di lavoro.

  2. Fare clic sulla scheda Spazi dei nomi.

  3. Nell'elenco degli spazi dei nomi, selezionare lo spazio dei nomi e fare clic sul pulsante RIMUOVI per eliminare lo spazio dei nomi.

• L'aggiornamento degli host ESXi da 7.0 Update 3 a 8.0 senza l'aggiornamento del supervisore comporta la visualizzazione degli host ESXi come non pronti e la disconnessione dei carichi di lavoro.

  Quando si aggiornano gli host ESXi che fanno parte di un supervisore da vSphere 7.0 Update 3 a vSphere 8.0 e non si aggiorna la versione Kubernetes del supervisore, gli host ESXi vengono visualizzati come non pronti e i carichi di lavoro in esecuzione sugli host vengono disconnessi.

  Soluzione: aggiornare la versione Kubernetes del supervisore ad almeno 1.21, 1.22 o 1.23.

• Dopo l'aggiornamento di vCenter Server con un solo clic, il supervisore non viene aggiornato automaticamente

  Se la versione di Kubernetes del supervisore è precedente alla 1.22, dopo l'aggiornamento con un clic di vCenter Server a 8.0, il supervisore non è in grado di eseguire l'aggiornamento automatico alla versione minima supportata di Kubernetes per la versione 8.0, ovvero la 1.23.

  Soluzione: prima di aggiornare vCenter Server per 8.0, aggiornare la versione di Kubernetes del supervisore alla versione 1.22. Se si dispone già di un aggiornamento vCenter Server alla versione 8.0, aggiornare manualmente la versione di Kubernetes del supervisore alla versione 1.23.

• Se si modificano le regole in una risorsa personalizzata del criterio di sicurezza, è possibile che le regole obsolete non vengano eliminate

  Questo problema può verificarsi quando si aggiorna il criterio di sicurezza. Ad esempio, si crea una risorsa personalizzata del criterio di sicurezza che contiene le regole A e B e quindi si aggiorna il criterio specificando le regole B e C. Di conseguenza, la regola A non viene eliminata. Il piano di gestione di NSX continua a visualizzare la regola A, oltre a B e C.

  Soluzione: eliminare il criterio di sicurezza e quindi creare lo stesso criterio.

• Dopo un aggiornamento di vCenter Server e vSphere IaaS Control Plane, un cluster Tanzu Kubernetes Grid non può completare l'aggiornamento perché esistono volumi che vengono visualizzati come collegati ai nodi del cluster

  Quando l'aggiornamento del cluster Tanzu Kubernetes Grid non viene eseguito correttamente, un volume viene visualizzato come collegato ai nodi del cluster e non viene cancellato. Questo problema potrebbe essere causato da un errore in Kubernetes upstream.

  Soluzione:

  1. recuperare informazioni sul nodo del cluster TKG con la pianificazione disabilitata utilizzando il comando seguente:

     kubectl get node tkc_node_name -o yaml

     Esempio:

     # kubectl get node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 -o yaml
     apiVersion: v1
     kind: Node
     metadata:
       annotations:
         cluster.x-k8s.io/cluster-name: gcm-cluster-antrea-1
         cluster.x-k8s.io/cluster-namespace: c1-gcm-ns
         cluster.x-k8s.io/machine: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
         cluster.x-k8s.io/owner-kind: MachineSet
         cluster.x-k8s.io/owner-name: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7
         csi.volume.kubernetes.io/nodeid: '{"csi.vsphere.vmware.com":"gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"}'
         kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
         node.alpha.kubernetes.io/ttl: "0"
         volumes.kubernetes.io/controller-managed-attach-detach: "true"
     ….
     ….
       volumesAttached:
       - devicePath: ""
         name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

     Controllare se questo nodo include volumi CSI di vSphere nella proprietà status.volumeAttached. Se sono presenti volumi, procedere con il passaggio successivo.

  2. Verificare che nel nodo identificato nel passaggio 1 non sia in esecuzione alcun pod. Utilizzare questo comando:

     kubectl get pod -o wide | grep tkc_node_name

     Esempio:

     kubectl get pod -o wide | grep gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

     L'output vuoto di questo comando indica che non sono presenti pod. Procedere con il passaggio successivo perché l'output del passaggio 1 indica un volume collegato al nodo che non include alcun pod.

  3. Recuperare informazioni su tutti gli oggetti nodo per assicurarsi che lo stesso volume sia collegato a un altro nodo:

     kubectl get node -o yaml

     Esempio:

     Lo stesso nome di volume è presente in due oggetti nodo del cluster TKG.

     On old node - "gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"
       volumesAttached:
       - devicePath: ""
         name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
     
     On new node "gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88"
       volumesAttached:
       - devicePath: ""
         name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
         ...
       volumesInUse:
       - kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
       ...

  4. Cercare il PV in base all'handle del volume nel nome del volume.

     Nell'esempio precedente, il nome del volume è kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd e l'handle del volume è 943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd.

     Recuperare tutti i PV e cercare l'handle del volume precedente utilizzando questo comando:

     kubectl get pv -o yaml

     Nell'esempio precedente, il PV con tale handle del volume è pvc-59c73cea-4b75-407d-8207-21a9a25f72fd.

  5. Utilizzare il comando volumeattachment per cercare il PV trovato nel passaggio precedente:

     kubectl get volumeattachment | grep pv_name

     Esempio:

     # kubectl get volumeattachment | grep pvc-59c73cea-4b75-407d-8207-21a9a25f72fd
     NAME                                                                   ATTACHER                 PV                                         NODE                                                 ATTACHED   AGE
     csi-2ae4c02588d9112d551713e31dba4aab4885c124663ae4fcbb68c632f0f46d3e   csi.vsphere.vmware.com   pvc-59c73cea-4b75-407d-8207-21a9a25f72fd   gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88   true       3d20h

     È possibile osservare un collegamento di volume collegato al nodo gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88 anziché al nodo gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95. Ciò indica che status.volumeAttached in gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 non è corretto.

  6. Eliminare la voce volumeAttached obsoleta dall'oggetto nodo:

     kubectl edit node tkc_node_name

     Esempio:

     kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

     Rimuovere la voce del volume obsoleta da status.volumeAttached.

  7. Ripetere i passaggi precedenti per tutti i volumi obsoleti nella proprietà status.volumeAttached.

  8. Se l'elemento WCPMachines è ancora presente, eliminarlo manualmente e attendere alcuni minuti per riconciliare il cluster.

     # kubectl get wcpmachines -n c1-gcm-ns
     NAMESPACE   NAME                                       ZONE   PROVIDERID                                       IPADDR
     c1-gcm-ns   gcm-cluster-antrea-1-workers-jrc58-zn6wl          vsphere://423c2281-d1bd-9f91-0e87-b155a9d291a1   192.168.128.17
     
     # kubectl delete wcpmachine gcm-cluster-antrea-1-workers-jrc58-zn6wl -n c1-gcm-ns
     wcpmachine.infrastructure.cluster.vmware.com "gcm-cluster-antrea-1-workers-jrc58-zn6wl" deleted

• Se un amministratore di vSphere configura un modello di spazio dei nomi self-service con limiti di risorse che superano la capacità del cluster, non viene attivato alcun avviso.

  Quando gli amministratori di vSphere configurano limiti delle risorse che superano la capacità del cluster, i tecnici di DevOps potrebbero utilizzare il modello per distribuire i pod vSphere con risorse elevate. Di conseguenza, i carichi di lavoro potrebbero non riuscire.

  Soluzione: Nessuno

• Quando si elimina uno spazio dei nomi supervisore che contiene un cluster Tanzu Kubernetes Grid, lo stato delle richieste di volume persistente presenti nel supervisore potrebbe rimanere Completamento in corso

  È possibile osservare questo problema quando si verifica un conflitto di risorse mentre il sistema elimina lo spazio dei nomi e scollega i volumi dai pod nel cluster Tanzu Kubernetes Grid.

  L'eliminazione dello spazio dei nomi supervisore rimane incompleta e lo stato dello spazio dei nomi è Completamento in corso in vSphere Client. Anche lo stato delle richieste di volume persistente collegate ai pod nel cluster Tanzu Kubernetes Grid rimane Completamento in corso.

  Se si eseguono i comandi seguenti è possibile che venga visualizzato il messaggio di errore Operation cannot be fulfilled on persistentvolumeclaims:

  kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

  kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c vsphere-syncer

  failed to update PersistentVolumeClaim: \\\"<pvc-name>\\\" on namespace: \\\"<supervisor-namespace>\\\". Error: Operation cannot be fulfilled on persistentvolumeclaims \\\"<pvc-name>\\\": the object has been modified; please apply your changes to the latest version and try again\

  Soluzione:

  utilizzare i comandi seguenti per risolvere il problema:

  kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

  kubectl patch pvc <pvc-name> -n <supervisor-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge

• Quando si eliminano più FCD e volumi da datastore condivisi come vSAN, è possibile che le prestazioni cambino

  Le modifiche delle prestazioni possono essere causate da un problema risolto. Finché non è stato risolto, il problema faceva sì che FCD e volumi obsoleti rimanessero nel datastore dopo un'operazione di eliminazione di FCD non riuscita.

  Soluzione: nessuna. L'operazione di eliminazione funziona come di consueto nonostante la modifica delle prestazioni.

• Se un utente di DevOps avvia operazioni relative al volume o distribuzioni di applicazioni stateful durante il riavvio di vCenter Server, le operazioni potrebbero non riuscire

  Il problema si verifica perché l'account utente di gestione dello storage del carico di lavoro viene bloccato e il plug-in vSphere CSI eseguito nel supervisore non riesce a eseguire l'autenticazione. Di conseguenza, le operazioni relative al volume non riescono con errori InvalidLogin.

  Nel file di registro /var/log/vmware/vpxd/vpxd.log viene visualizzato il messaggio seguente:

  Authentication failed: The account of the user trying to authenticate is locked. :: The account of the user trying to authenticate is locked. :: User account locked: {Name: workload_storage_management-<id>, Domain: <domain>})

  Soluzione:

  1. recuperare il tempo di sblocco dell'account.

     1. In vSphere Client, passare ad Amministrazione e fare clic su Configurazione in Single Sign-On.

     2. Fare clic sulla scheda Account.

     3. In Criterio di blocco, recuperare il tempo di sblocco in secondi.

  2. Eseguire l'autenticazione nel supervisore utilizzando il plug-in vSphere per kubectl.

     kubectl vsphere login –server IP-ADDRESS --vsphere-username USERNAME

  3. Prendere nota del numero di repliche originali per la distribuzione di vsphere-csi-controller in vmware-system-csi-namespace.

     kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'

     original-replica-count

  4. Ridurre il numero di repliche della distribuzione di vsphere-csi-controller a zero.

     kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi

  5. Attendere il numero di secondi indicato in Tempo di sblocco.

  6. Aumentare il numero di repliche della distribuzione di vsphere-csi-controller fino al valore originale.

     kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi

Problemi noti di TKG nel supervisore

• Quando si aggiorna l'ambiente di vSphere IaaS Control Plane 7.0.x a vSphere 8.0.x, tutti i cluster TKG di v1.27.6 diventano incompatibili

  vSphere 8.0.x non supporta TKR 1.27.6.

  Di conseguenza, i cluster TKG di v1.27.6 diventano incompatibili dopo l'aggiornamento di vSphere IaaS Control Plane 7.0.x a vSphere 8.0.x. Durante l'aggiornamento del supervisore non verrà visualizzato alcun avviso di verifica preliminare.

  Soluzione:

  • Se sono in esecuzione cluster TKGS v1.27.6 in vSphere 7.0.x, non eseguire l'aggiornamento a vCenter 8.0.x, in particolare a vCenter 8.0 Update 2b. Per ulteriori informazioni, vedere Note di rilascio delle versioni di VMware Tanzu Kubernetes e l'articolo 96501 della Knowledge Base.

  • Se si intende aggiornare l'ambiente vSphere 7.x a vCenter 8.x, non eseguire l'aggiornamento a TKR 1.27.6.

• I nodi di lavoro del cluster TKG non si accendono con VIF restore activity already completed for attachment ID del registro degli errori dal pod nsx-ncp

  I nodi di lavoro del cluster TKG non si accendono con l'errore seguente:

  nsx-container-ncp Generic error occurred during realizing network for VirtualNetworkInterface

  NCP registra un errore:

  VIF restore activity already completed for attachment ID

  Quando una macchina virtuale di un nodo del cluster TKG creato dopo che un backup di NSX esegue la migrazione tramite vMotion immediatamente dopo il ripristino di NSX, NCP non può ripristinare la porta per la macchina virtuale perché l'ID del collegamento verrà riutilizzato in vMotion e bloccherà la richiesta di ripristino di NCP.

  Soluzione:

  1. Passare a NSX Manager per ottenere le porte del segmento che devono essere eliminate. Il nome visualizzato è nel formato <vm name>.vmx@<attachment id>

  2. Prima di eliminare la porta appena creata, individuare l'host in cui è in esecuzione la macchina virtuale e disattivare l'ops-agent eseguendo /etc/init.d/nsx-opsagent stop nell'host.

  3. Eliminare la porta utilizzando NSX API https://<nsx-mgr>/api/v1/logical-ports/<logical switch port id>?detach=true

  4. Attivare l'ops-agent eseguendo /etc/init.d/nsx-opsagent start nell'host.

  5. Attendere che NCP ripristini la porta.

• È possibile che pod, PV e PVC in un cluster TKG si blocchino nello stato Terminating durante la pulizia del cluster TKG o durante il ripristino dall'inattività degli host ESXi

  Nell'ambito del normale processo di eliminazione e pulizia del cluster TKG, tutte le distribuzioni, i set stateful, i PVC, i PV e gli altri oggetti simili vengono eliminati. Tuttavia, per i cluster TKG basati su TKR v1.24 e versioni precedenti, è possibile che alcuni PV si blocchino nello stato Terminating a causa di errori DetachVolume. Il problema si verifica quando gli errori DetachVolume in un oggetto VolumeAttachment causano la mancata rimozione dei finalizzatori in VolumeAttachment, causando la mancata eliminazione degli oggetti correlati. Questo scenario può verificarsi anche se si verifica un tempo di inattività negli host ESXi.

  Soluzione: eseguire il comando seguente nel cluster TKG per rimuovere i finalizzatori dai VolumeAttachment con un detachError:

  kubectl get volumeattachments \
  -o=custom-columns='NAME:.metadata.name,UUID:.metadata.uid,NODE:.spec.nodeName,ERROR:.status.detachError' \
  --no-headers | grep -vE '<none>$' | awk '{print $1}' | \
  xargs -n1 kubectl patch -p '{"metadata":{"finalizers":[]}}' --type=merge volumeattachments

• Il cluster TGK non è raggiungibile dopo il backup e il ripristino

  Se uno spazio dei nomi vSphere viene creato dopo un backup di NSX e configurato con un CIDR in entrata/uscita personalizzato, dopo che NSX viene ripristinato da un backup, NCP non riesce a completare il processo di ripristino e i cluster TKG nello spazio dei nomi vSphere non sono disponibili. NCP non riesce durante il processo di ripristino e viene visualizzato un messaggio di errore simile al seguente:

  NSX IP Pool ipp_<supervisor_namespace_id>_ingress not found in store

  Soluzione: se un backup del supervisore è stato eseguito circa alla stessa ora del backup di NSX, ma prima della creazione dello spazio dei nomi vSphere interessato, ripristinare anche il supervisore dal backup. In alternativa, eliminare lo spazio dei nomi vSphere e i cluster TKG associati, attendere che NCP venga nuovamente sincronizzato e quindi ricreare le risorse eliminate.

• Il cluster TKG non è raggiungibile dopo il backup e il ripristino di NSX

  Quando un supervisore è configurato con un CIDR in entrata personalizzato, dopo il backup e il ripristino di NSX, i cluster TKG potrebbero diventare non disponibili perché il componente NCP non è in grado di convalidare correttamente il VIP in entrata dei cluster TKG.

  Soluzione: utilizzando la NSX API, configurare manualmente i VIP per i cluster TKG in NSX per ripristinare l'accesso.

• I cluster Tanzu Kubernetes Grid esistenti configurati con un server proxy non possono essere aggiornati a un supervisore vSphere 8

  RISOLTO: questo problema noto è stato risolto nella versione vSphere 8 con Tanzu MP1.

  Se è stato configurato un cluster Tanzu Kubernetes Grid esistente con un server proxy, non è possibile aggiornare tale cluster da un supervisore vSphere 7 a Tanzu Kubernetes Grid 2.0 in un supervisore vSphere 8.

  Soluzione: il contenuto del campo noProxy è in conflitto con le verifiche dell'aggiornamento. Poiché questo campo è obbligatorio se la stanza del proxy viene aggiunta alla specifica del cluster, è necessario rimuovere la configurazione del proxy nella sua interezza prima di eseguire l'aggiornamento a vSphere 8.

• Il pod antrea-resource-init si blocca nello stato In sospeso

  Dopo aver aggiornato la versione di Tanzu Kubernetes di un cluster Tanzu Kubernetes Grid, lo stato del pod antrea-resource-init potrebbe essere In sospeso.

  Soluzione: riavviare il pod nel supervisore.

• I cluster Tanzu Kubernetes Grid v1.21.6 potrebbero passare allo stato FALSE e alcune macchine potrebbero non eseguire la migrazione

  Dopo l'aggiornamento a vCenter Server 8 e l'aggiornamento del supervisore, i cluster Tanzu Kubernetes Grid v1.21.6 potrebbero passare allo stato FALSE e alcune wcpmachines potrebbero non migrare a vspheremachines.

  Soluzione: nessuna

• Per impostazione predefinita, la password dell'account vmware-system-user scade dopo 60 giorni per i cluster TKG che eseguono la versione di TKR v1.23.8---vmware.2-tkg.2-zshippable

  Come parte della protezione avanzata STIG, per i cluster TKG che eseguono la versione di TKR v1.23.8---vmware.2-tkg.2-zshippable, l'account vmware-system-user è configurato per scadere dopo 60 giorni. Questo comportamento può influire sugli utenti che utilizzano l'account vmware-system-user per accedere tramite SSH ai nodi del cluster.

  Fare riferimento al seguente articolo della Knowledge Base per aggiornare la scadenza della password di vmware-system-user, consentendo sessioni SSH nei nodi del cluster TKG, se necessario: https://kb.vmware.com/s/article/90469

• Il pod tanzu-capabilities-controller-manager viene continuamente riavviato e diretto a CLBO nel TKC in vSphere Iaas Control Plane 8.0.0a

  In seguito a problemi di autorizzazione dell'account di servizio, il pod tanzu-capabilities-controller-manager nel cluster TKG si blocca in CLBO (Crash Loop back off) quando si utilizza TKR con versione v1.23.8+vmware.2-tkg.2-zshippable.

  Soluzione: aggiungere le autorizzazioni necessarie all'account del servizio della funzionalità tanzu-capabilities-manager-sa in TKC.

  1. Sospendere la riconciliazione del pacchetto delle funzionalità in TKC:

     kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"spec":{"paused": true}}' --type=merge

  2. Creare un nuovo file capabilities-rbac-patch.yaml:

     apiVersion: v1
     kind: Secret
     metadata:
       name: tanzu-capabilities-update-rbac
       namespace: vmware-system-tkg
     stringData:
       patch-capabilities-rbac.yaml: |
         #@ load("@ytt:overlay", "overlay")
         #@overlay/match by=overlay.subset({"kind":"ClusterRole", "metadata": {"name": "tanzu-capabilities-manager-clusterrole"}}),expects="1+"
         ---
         rules:
           - apiGroups:
             - core.tanzu.vmware.com
             resources:
               - capabilities
             verbs:
               - create
               - delete
               - get
               - list
               - patch
               - update
               - watch
           - apiGroups:
               - core.tanzu.vmware.com
             resources:
               - capabilities/status
             verbs:
               - get
               - patch
               - update-rbac

  3. Applicare la patch al ruolo del cluster delle funzionalità in TKC:

     //Replace tkc with the name of the Tanzu Kubernetes Grid cluster: kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"metadata":{"annotations":{"ext.packaging.carvel.dev/ytt-paths-from-secret-name.0":"tanzu-capabilities-update-rbac"}}}' --type=merge

  4. Eliminare tanzu-capabilities-controller-manager in TKC.

• I cluster Tanzu Kubernetes Grid 2.0 in un supervisore distribuito in tre zone vSphere non supportano le macchine virtuali con vGPU e storage di istanze.

  I cluster Tanzu Kubernetes Grid 2.0, forniti su un'istanza di supervisore distribuita su tre zone di vSphere, non supportano le macchine virtuali con vGPU e storage dell'istanza.

  Soluzione: nessuna

• La versione v1.22.9 di TKR è elencata nell'immagine della libreria di contenuti ma non nel comando kubectl

  La libreria di contenuti per le immagini TKR include TKR v1.22.9. Il comando kubectl get tkr non segnala questa immagine come disponibile perché TKR v1.22.9 non è disponibile per l'uso e non deve essere utilizzato. Questa immagine viene visualizzata nella libreria di contenuti per errore.

  Soluzione: utilizzare un TKR diverso da TKR v1.22.9. Per un elenco dei TKR disponibili, fare riferimento alle Note di rilascio diTKR.

• Non è possibile eseguire il provisioning di un TKC utilizzando l'API v1alpha1 e un TKR v1.23.8 in vSphere IaaS Control Plane 8.0.0a

  quando si utilizza l'API v1alpha1 di TKC per eseguire il provisioning di TKC con versione v1.23.8. La richiesta non riesce e viene visualizzato il messaggio "impossibile trovare un suggerimento di versione corrispondente alla versione completa compatibile "1.23.8" ed etichette predefinite del sistema operativo: "os-arch=amd64,os-name=photon,os-type=linux,os-version=3.0".

  Soluzione: quando si effettua il provisioning dei TKC, utilizzare l'API v1alpha2 o v1alpha3 di TKC

• I cluster Tanzu Kubernetes Grid 2.0 forniti con l'API v1beta1 devono essere basati sulla ClusterClass predefinita

  Se si crea un cluster Tanzu Kubernetes Grid 2.0 in un supervisore utilizzando l'API v1beta1, il cluster deve essere basato sulla ClusterClass tanzukubernetescluster predefinita. Il sistema non riconcilia un cluster basato su una ClusterClass diversa.

  Soluzione: a partire dalla versione vSphere 8 U1, è possibile eseguire il provisioning di un cluster v1beta1 basato su una ClusterClass personalizzata. Fare riferimento all'articolo della KB https://kb.vmware.com/s/article/91826.

Problemi noti di rete

• Nella configurazione di NSX Advanced Load Balancer non è presente alcuna sezione usage.ingressCIDRUsage in clusternetworkinfo o namespacenetworkinfo

  Nella configurazione di NSX Advanced Load Balancer, l'IP in entrata viene allocato dal controller Avi e l'utilizzo per ingressCIDR non viene visualizzato nell'output clusternetworkinfo o namespacenetworkinfo.

  Soluzione: recuperare l'utilizzo di ingressCIDR dall'interfaccia utente del controller Avi in Applicazioni > VIP VS.

• Il CIDR del pod nell'elenco di prefissi di livello 0 non viene rimosso dopo l'eliminazione dello spazio dei nomi per un supervisore instradato

  Nel supervisore instradato, il CIDR del pod in un elenco di prefissi di livello 0 non viene eliminato dopo l'eliminazione dello spazio dei nomi.

  Soluzione: eliminare l'oggetto prefix-lists:

  curl -k -u ‘admin:U2.HzP7QZ9Aw’ -X PATCH -d ‘{“prefixes”:[{“network” : “10.246.0.0/16”,“le” : 28,“action” : “PERMIT”}]}’ https://<IP ADDRESS>/policy/api/v1/infra/tier-0s/ContainerT0/prefix-lists/pl_domain-c9:45c1ce8d-d2c1-43cb-904f-c526abd8fffe_deny_t1_subnets -H ‘X-Allow-Overwrite: true’ -H ‘Content-type: application/json

• Le risorse Kubernetes clusternetworkinfo e namespacenetworkinfo non contengono usage.ingressCIDRUsage quando si utilizza NSX Advanced Load Blanacer.

  Quando si utilizza NSX Advanced Load Balancer in un supervisore basato su NSX, le risorse Kubernetes clusternetworkinfo e namespacenetworkinfo non contengono più i campi usage.ingressCIDRUsage. Questo significa che l'esecuzione di kubectl get clusternetworkinfo <supervisor-cluster-name> -o json o kubectl get namespacenetworkinfo <namespace-name> -n <namespace-name> -o json non conterrà l'oggetto di utilizzo ingressCIDR nell'output.

  Soluzione: usare la pagina dell'interfaccia utente del controller Avi per accedere all'utilizzo di ingressCIDR.

• Sono presenti segmenti di livello 1 obsoleti per alcuni spazi dei nomi dopo il backup e il ripristino di NSX

  Dopo una procedura di backup e ripristino di NSX, i segmenti di livello 1 obsoleti con schede NIC del motore di servizio non vengono puliti.

  Quando uno spazio dei nomi viene eliminato dopo un backup di NSX, l'operazione di ripristino ripristina i segmenti di livello 1 obsoleti associati alle NIC del motore di servizio del controller di NSX Advanced Load Balancer.

  Soluzione: eliminare manualmente i segmenti di livello 1.

  1. Accedere a NSX Manager.

  2. Selezionare Rete > Segmenti.

  3. Individuare i segmenti obsoleti associati allo spazio dei nomi eliminato.

  4. Eliminare le NIC obsolete del motore di servizio dalla sezione Porte/Interfacce.

• È possibile che il monitoraggio del bilanciamento del carico smetta di funzionare e che il supervisore si blocchi nello stato "configurazione in corso" in vSphere Client

  Se NSX Advanced Load Balancer è abilitato, a causa della presenza di più punti di applicazione in NSX, è possibile che NCP non riesca a richiamare lo stato del bilanciamento del carico. Questo influisce sui supervisori esistenti configurati con NSX Advanced Load Balancer una volta che viene abilitato in NSX. Questo problema riguarda i nuovi supervisori che utilizzano NSX Advanced Load Balancer. I supervisori interessati da questo problema continueranno a funzionare, ad eccezione della funzionalità di monitoraggio del bilanciamento del carico.

  Soluzione: disabilitare NSX Advanced Load Balancer in NSX. Questo può limitare la possibilità di distribuire supervisori con NSX Advanced Load Balancer negli ambienti WCP in cui i supervisori esistenti eseguono NSX Advanced Load Balancer.

• Non è possibile utilizzare NSX Advanced Load Balancer con un vCenter Server in una topologia con modalità collegata incorporata.

  Quando si configura il controller NSX Advanced Load Balancer, è possibile configurarlo in più cloud. Tuttavia, non è possibile selezionare più cloud durante l'abilitazione del piano di controllo IaaS di vSphere perché supporta solo l'opzione Default-Cloud. Di conseguenza, non è possibile utilizzare NSX Advanced Load Balancer con una versione di vCenter Server in una topologia con modalità collegata incorporata.

  Configurare NSX Advanced Load Balancer per ogni vCenter Server.

Problemi noti dello storage

• In un ambiente in cui un datastore viene condiviso tra sistemi vCenter, si verificano più errori di sincronizzazione del volume CNS

  La migrazione tra vCenter non è supportata da CNS. Tuttavia, la sincronizzazione periodica di CNS viene eseguita automaticamente e crea un conflitto di blocco per i volumi nel datastore condiviso.

  Soluzione: per evitare questo problema, configurare un intervallo di tempo elevato per la sincronizzazione periodica di CNS.

  1. Individuare il file di configurazione di CNS in vCenter:

     /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml

  2. Passare alla seguente riga:

     <newSyncInterval>60</newSyncInterval>

     Per impostazione predefinita, la sincronizzazione periodica è impostata su 60 secondi.

  3. Impostare un periodo di tempo più lungo, ad esempio 31536000 per 1 anno.

• Non è possibile modificare il tipo di allocazione del volume per i dischi in un datastore vSAN Direct

  Una volta deciso il tipo di allocazione del volume per i dischi nel datastore vSAN Direct, non è possibile modificarlo. Questo è dovuto al fatto che i livelli sottostanti non supportano la conversione del tipo. Tuttavia, la modifica del tipo di allocazione del volume per il nuovo disco è consentita per operazioni come la clonazione e il trasferimento.

  Soluzione: nessuna

• Una macchina virtuale eliminata causa il blocco delle attività CNS nello stato In coda.

  Le operazioni inviate a CNS restituiscono un ID attività, ma lo stato dell'attività rimane sempre In coda. Le attività sono relative ai volumi collegati a una macchina virtuale appena eliminata.

  Soluzione: se è possibile correggere l'ordine di chiamata a livello dell'applicazione, non è necessario eseguire alcuna operazione in CNS. In caso contrario, disabilitare la nuova serializzazione di CNS eseguendo i passaggi seguenti:

  1. Aprire /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml in vCenter.

  2. Modificare la configurazione seguente impostandola su false: <newSerializationEnabled>true</newSerializationEnabled>

  3. Riavviare vsan-health con vmon-cli -r vsan-health

  Per ulteriori dettagli, vedere l'articolo 93903 della Knowledge Base.

• Lo stato dei PV rimane Terminato dopo l'eliminazione dei PVC

  Dopo aver eliminato un PersistentVolumeClaim (PVC), è possibile che lo stato del PersistentVolume (PV) corrispondente rimanga Terminato nel supervisore. È inoltre possibile che in vSphere Client vengano visualizzate più attività di deleteVolume non riuscite.

  Soluzione:

  1. eseguire l'autenticazione nel supervisore:

     kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

  2. Recuperare il nome del volume persistente con stato Terminato:

     kubectl get pv

  3. Prendere nota dell'handle del volume dal volume persistente:

     kubectl describe pv <pv-name>

  4. Utilizzando l'handle del volume del passaggio precedente, eliminare la risorsa personalizzata CnsVolumeOperationRequest nel supervisore:

     kubectl delete cnsvolumeoperationrequest delete-<volume-handle>

  Nota:

  Prima di eliminare un PV, assicurarsi che non sia utilizzato da altre risorse nel cluster.