Note di rilascio di VMware Tanzu Kubernetes Grid v2.2

Se non diversamente indicato, queste note di rilascio si applicano a tutte le versioni patch v2.2.x di Tanzu Kubernetes Grid (TKG).

TKG v2.2 viene distribuito come pacchetto della CLI di Tanzu scaricabile che distribuisce un cluster di gestione autonomo TKG con versione. TKG v2.2 supporta la creazione e la gestione di cluster del carico di lavoro con un cluster di gestione autonomo che può essere eseguito in più infrastrutture, tra cui vSphere 6.7, 7 e 8, AWS e Azure.

Tanzu Kubernetes Grid v2.0, v2.2 e supervisore vSphere with Tanzu in vSphere 8

Importante
Il supervisore vSphere with Tanzu in vSphere 8.0.1c o versioni successive esegue TKG v2.2 Le versioni precedenti di vSphere 8 eseguono TKG v2.0, che non è stato rilasciato indipendentemente dal supervisore. I cluster di gestione autonomi che eseguono TKG 2.x sono disponibili a partire da TKG 2.1. Le versioni future di TKG verranno incorporate nel supervisore nelle prossime versioni di aggiornamento di vSphere. Di conseguenza, la versione di TKG incorporata nella versione più recente di vSphere with Tanzu in un determinato momento potrebbe non essere uguale alla versione autonoma di TKG che si sta utilizzando. Tuttavia, le versioni della CLI di Tanzu compatibili con tutte le versioni di TKG v2.x sono completamente supportate per l'utilizzo con il supervisore in tutte le versioni di vSphere 8.

Tanzu Kubernetes Grid v2.2 e vSphere with Tanzu in vSphere 7

Attenzione
Le versioni della CLI di Tanzu compatibili con TKG 2.x e con il supervisore vSphere with Tanzu in vSphere 8 non sono compatibili con il cluster supervisore in vSphere 7. Per utilizzare la CLI di Tanzu con un cluster supervisore vSphere with Tanzu in vSphere 7, utilizzare la versione della CLI di Tanzu da TKG v1.6. Per utilizzare le versioni della CLI di Tanzu compatibili con TKG 2.x con Supervisore, eseguire l'aggiornamento a vSphere 8. È possibile distribuire un cluster di gestione autonomo TKG 2.x in vSphere 7 se non è presente un cluster supervisore vSphere with Tanzu. Per informazioni sulla compatibilità tra la CLI di Tanzu e i prodotti VMware, vedere la documentazione della CLI di Tanzu.

Novità

Tanzu Kubernetes Grid v2.2.x include le nuove funzionalità seguenti:

Supporto per Kubernetes v1.25.7, 1.24.11 e 1.23.17. Vedere Versioni di Kubernetes supportate in Tanzu Kubernetes Grid v2.2 di seguito.
Per i cluster di gestione autonomi e i cluster del carico di lavoro basati sulla classe, è possibile configurare l'attendibilità per più registri di immagini privati utilizzando le variabili di ADDITIONAL_IMAGE_REGISTRY* in un file di configurazione del cluster o le impostazioni di additionalImageRegistries in una specifica di oggetto Cluster. Vedere Registri attendibili per un cluster basato sulla classe.
È stata rimossa la richiesta di volume persistente jobservice.scandataExports da Harbor v2.7.1. Se in precedenza è stato applicato l'overlay Harbor Scandata Volume EmptyDir al pacchetto di Harbor, vedere Aggiornamento di una distribuzione Harbor in esecuzione prima di aggiornare il pacchetto di Harbor alla versione v2.7.1.
A partire da TKG 2.2.0, VMware offre supporto a livello di runtime per i pacchetti supportati da VMware come Harbor, Contour e Velero, quando vengono distribuiti in Tanzu Kubernetes Grid.
Il pacchetto di vSphere CSI supporta la configurazione vsphereCSI.netpermissions.

Versioni di Kubernetes e TKG supportate

Con TKG v2.2, il criterio di supporto di VMware cambia per le versioni patch precedenti di TKG e TKr, che includono in un pacchetto le versioni di Kubernetes per TKG. I criteri di supporto per TKG v2.1 e le versioni secondarie precedenti di TKG non vengono modificati.

Le sezioni seguenti includono un riepilogo del supporto per tutte le versioni di TKG e TKr attualmente supportate nell'ambito dei criteri di supporto applicabili a ciascuna versione.

Versioni di Kubernetes supportate

In ogni versione di Tanzu Kubernetes Grid viene aggiunto il supporto per la versione di Kubernetes del relativo cluster di gestione, oltre ad altre versioni di Kubernetes distribuite come versioni di Tanzu Kubernetes (TKr), ad eccezione dei casi indicati come Problemi noti.

Versioni secondarie: VMware supporta TKG v2.2 con Kubernetes v1.25, v1.24 e v1.23 al momento del rilascio e finché è supportato anche TKG v2.1. Quando TKG v2.1 raggiungerà la fine del supporto generale, VMware non supporterà più Kubernetes v1.23 e v1.24 con TKG.

Versioni patch: dopo che VMware pubblica una nuova versione patch di TKr per una linea secondaria, mantiene il supporto per le versioni patch precedenti per due mesi. In questo modo, i clienti hanno 2 mesi di tempo per eseguire l'aggiornamento alle nuove versioni patch di TKr. A partire da TKG v2.2, VMware non supporta tutte le versioni patch di TKr delle linee secondarie precedenti di Kubernetes.

Versioni di TKG e TKr supportate

Le versioni patch di TKG attualmente supportate supportano le versioni patch di TKr come indicato di seguito.

Versione di Tanzu Kubernetes Grid	Versione di Kubernetes del cluster di gestione	Versioni di Kubernetes (TKr) fornite
2.2.0	1.25.7	1.25.7, 1.24.11, 1.23.17
2.1.1	1.24.10	1.24.10, 1.23.16, 1.22.17
2.1.0	1.24.9	1.24.9, 1.23.15, 1.22.17
1.6.1	1.23.10	1.23.10, 1.22.13, 1.21.14
1.6.0	1.23.8	1.23.8, 1.22.11, 1.21.14

Versioni di TKr supportate con TKG v2.2.0

TKG v2.2.0 supporta le versioni patch di TKr elencate nella tabella seguente, in base alle date di rilascio seguenti:

v2.2.0: 18 maggio 2023
v2.1.1: 21 marzo 2023

Versione secondaria di Kubernetes	Versione patch di Kubernetes	Rilasciata con TKG	Data di fine supporto (se non più recente)
v1.25	v1.25.7	v2.2.0	Più recente supportato
v1.24	v1.24.11	v2.2.0	Più recente supportato
	v1.24.10	v2.1.1	11 luglio 2023
	v1.24.9	v2.1.0	21 maggio 2023
v1.23	v1.23.17	v2.2.0	Più recente supportato
	v1.23.16	v2.1.1	11 luglio 2023
	v1.23.15	v2.1.0	21 maggio 2023

Versioni di Tanzu Kubernetes Grid supportate

VMware supporta le versioni di TKG come segue:

Versioni secondarie: VMware supporta TKG seguendo il criterio del ciclo di vita N-2, che si applica alla versione più recente e alle due versioni secondarie precedenti di TKG. Con la versione di TKG v2.2.0, TKG v1.5 non è più supportato. Per ulteriori informazioni, vedere Matrice del ciclo di vita dei prodotti VMware.

Versioni patch: VMware non supporta tutte le versioni patch di TKG precedenti. Dopo che VMware rilascia una nuova versione patch di TKG, continua a supportare la versione patch precedente per due mesi. In questo modo, i clienti hanno 2 mesi di tempo per eseguire l'aggiornamento alla nuova versione patch di TKG.

Ad esempio, il supporto per TKG v2.2.0 terminerà due mesi dopo il rilascio della versione General Availability di TKG v2.2.1.

Chiarimento relativo al supporto del pacchetto del repository di Tanzu Standard

VMware fornisce il supporto seguente per i pacchetti facoltativi forniti nel repository di VMware Tanzu Standard:

VMware fornisce la convalida dell'installazione e dell'aggiornamento per i pacchetti inclusi nel repository di VMware Tanzu Standard facoltativo quando vengono distribuiti in Tanzu Kubernetes Grid. Questa convalida è limitata all'installazione e all'aggiornamento del pacchetto, ma include tutti gli aggiornamenti disponibili necessari per risolvere i CVE. Tutte le correzioni di bug, i miglioramenti delle funzionalità e le correzioni per la sicurezza vengono forniti nelle nuove versioni dei pacchetti quando sono disponibili nel progetto del pacchetto upstream.
VMware non fornisce il supporto a livello di runtime per i componenti del repository di Tanzu Standard. Il debug della configurazione e dei problemi relativi alle prestazioni, nonché il debug e la correzione del pacchetto stesso non vengono forniti da VMware.

Per ulteriori informazioni sul supporto di VMware per i pacchetti standard di Tanzu, vedere la sezione Novità precedente e la sezione Avvisi relativi alle modifiche del comportamento future di seguito.

Snapshot del prodotto per Tanzu Kubernetes Grid v2.2

Tanzu Kubernetes Grid v2.2 supporta le piattaforme e i sistemi operativi dell'infrastruttura seguenti, nonché i componenti per la creazione e la gestione, la rete, lo storage, l'autenticazione, il backup, la migrazione e l'osservabilità dei cluster. Le versioni dei componenti elencate tra parentesi sono incluse in Tanzu Kubernetes Grid v2.2.0. Per ulteriori informazioni, vedere Versioni dei componenti.

	vSphere	AWS	Azure
Piattaforma dell'infrastruttura	vSphere 6.7U3 vSphere 7 vSphere 8 VMware Cloud on AWS** Azure VMware Solution Oracle Cloud VMware Solution(OCVS) Google Cloud VMware Engine (GCVE)	AWS nativo	Azure nativo
CLI, API e infrastruttura dei pacchetti	Tanzu Framework v0.29.0
Creazione e gestione di cluster	Core Cluster API (v1.2.8), Cluster API Provider vSphere (v1.5.3)	Core Cluster API (v1.2.8), Cluster API Provider AWS (v2.0.2)	Core Cluster API (v1.2.8), Cluster API Provider Azure (v1.6.3)
Sistema operativo del nodo Kubernetes distribuito con TKG	Photon OS 3, Ubuntu 20.04	Amazon Linux 2, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
Creazione di un'immagine personalizzata	Photon OS 3, Red Hat Enterprise Linux 7*** e 8, Ubuntu 18.04, Ubuntu 20.04, Windows 2019	Amazon Linux 2, Ubuntu 18.04, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
Runtime del container	Containerd (v1.6.18)
Rete dei container	Antrea (v1.9.0), Calico (v3.24.1)
Registro dei container	Harbor (v2.7.1)
Ingresso	NSX Advanced Load Balancer Essentials e controller Avi **** (v21.1.5-v21.1.6, v22.1.2-v22.1.3), Contour (v1.23.5)	Contour (v1.23.5)	Contour (v1.23.5)
Storage	vSphere Container Storage Interface (v2.7.1*) e vSphere Cloud Native Storage	Driver Amazon EBS CSI (v1.16.0) e provider di cloud nella struttura	Driver Azure Disk CSI (v1.27.0), driver Azure File CSI (v1.26.1), e provider di cloud nella struttura
Autenticazione	OIDC tramite Pinniped (v0.12.1), LDAP tramite Pinniped (v0.12.1) e Dex
Osservabilità	Fluent Bit (v1.9.5), Prometheus (v2.37.0)***, Grafana (v7.5.17)
Backup e migrazione	Velero (v1.9.7)

* Versione di vsphere_csi_driver. Per un elenco completo dei componenti di vSphere Container Storage Interface inclusi in Tanzu Kubernetes Grid v2.2, vedere Versioni dei componenti.

** Per un elenco delle versioni dell'SDDC di VMware Cloud on AWS compatibili con questa versione, vedere la matrice di interoperabilità dei prodotti VMware.

*** Tanzu Kubernetes Grid v1.6 è l'ultima versione che supporta la creazione di immagini di Red Hat Enterprise Linux 7.

**** In vSphere 8 o versione successiva di NSX Advanced Load Balancer con un cluster di gestione TKG e i relativi cluster di lavoro sono necessari NSX ALB v22.1.2 o versioni successive e TKG v2.1.1 o versione successiva.

***** Se si aggiorna un cluster a Kubernetes v1.25, è necessario aggiornare Prometheus alla versione 2.37.0+vmware.3-tkg.1. Le versioni precedenti del pacchetto di Prometheus, ad esempio la versione 2.37.0+vmware.1-tkg.1, non sono compatibili con Kubernetes 1.25.

Per un elenco completo delle versioni di Kubernetes disponibili con Tanzu Kubernetes Grid v2.2, vedere l'argomento Versioni di Kubernetes supportate in Tanzu Kubernetes Grid v2.2 precedente.

Versioni dei componenti

Le versioni di Tanzu Kubernetes Grid v2.2.x includono le versioni dei componenti software seguenti:

Componente	TKG v2.2
aad-pod-identity	v1.8.15+vmware.1^*
addons-manager	v2.2+vmware.1^*
ako-operator	v1.8.0_vmware.1^*
alertmanager	v0.25.0_vmware.1^*
antrea	v1.9.0_vmware.2-tkg.1-advanced^*
aws-ebs-csi-driver	v1.16.0_vmware.1-tkg.1^*
azuredisk-csi-driver	v1.27.0_vmware.2-tkg.1^*
azurefile-csi-driver	v1.26.1_vmware.2-tkg.1^*
calico	v3.24.1_vmware.1-tkg.2^*
capabilities-package	v0.29.0-dev-capabilities^*
carvel-secretgen-controller	v0.11.2+vmware.1
cloud-provider-azure	v1.1.26+vmware.1, v1.23.23+vmware.1, v1.24.10+vmware.1
cloud_provider_vsphere	v1.25.1+vmware.2^*
cluster-api-provider-azure	v1.6.3_vmware.2^*
cluster_api	v1.2.8+vmware.2^*
cluster_api_aws	v2.0.2+vmware.2^*
cluster_api_vsphere	v1.5.3+vmware.2^*
cni_plugins	v1.1.1+vmware.20^*
configmap-reload	v0.7.1+vmware.2
containerd	v1.6.18+vmware.1^*
contour	v1.23.5+vmware.1-tkg.1^*
coredns	v1.9.3_vmware.8^*
crash-diagnostics	v0.3.7+vmware.6
cri_tools	v1.24.2+vmware.8^*
csi_attacher	v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1
csi_livenessprobe	v2.7.0+vmware.1, v2.6.0+vmware.1, v2.5.0+vmware.1, v2.4.0+vmware.1
csi_node_driver_registrar	v2.5.1+vmware.1, v2.5.0+vmware.1, v2.3.0+vmware.1
csi_provisioner	v3.2.1+vmware.1, v3.1.0+vmware.2, v3.0.0+vmware.1
dex	v2.35.3_vmware.3^*
envoy	v1.24.5_vmware.1^*
external-dns	v0.12.2+vmware.5^*
external-snapshotter	v6.0.1+vmware.1, v5.0.1+vmware.1
etcd	v3.5.6+vmware.9^*
fluent-bit	v1.9.5+vmware.1
gangway	v3.2.0+vmware.2
grafana	v7.5.17+vmware.2
guest-cluster-auth-service	v1.3.0^*
harbor	v2.7.1+vmware.1^*
image-builder	v0.1.13+vmware.3^*
image-builder-resource-bundle	v1.25.7+vmware.2-tkg.1^*
imgpkg	v0.31.1+vmware.1
jetstack_cert-manager	v1.10.2+vmware.1^*
k8s-sidecar	v1.15.6+vmware.5^, v1.12.1+vmware.6^
k14s_kapp	v0.53.2+vmware.1
k14s_ytt	v0.43.1+vmware.1
kapp-controller	v0.41.7_vmware.1-tkg.1^*
kbld	v0.35.1+vmware.1
kube-state-metrics	v2.7.0+vmware.2^*
kube-vip	v0.5.7+vmware.2^*
kube-vip-cloud-provider^*	v0.0.4+vmware.4^*
kube_rbac_proxy	v0.11.0+vmware.2
kubernetes	v1.25.7+vmware.2^*
kubernetes-csi_external-resizer	v1.4.0+vmware.1, v1.3.0+vmware.1
kubernetes-sigs_kind	v1.25.7+vmware.2-tkg.2_v0.17.0^*
kubernetes_autoscaler	v1.25.0+vmware.1^*
load-balancer-and-ingress-service (AKO)	v1.9.3_vmware.1-tkg.1^*
metrics-server	v0.6.2+vmware.1
multus-cni	v3.8.0+vmware.3^*
pinniped	v0.12.1_vmware.3-tkg.4^*
pinniped-post-deploy	v0.12.1+vmware.2-tkg.3
prometheus	v2.37.0+vmware.3^*
prometheus_node_exporter	v1.4.0+vmware.3^*
pushgateway	v1.4.3+vmware.3^*
sonobuoy	v0.56.16+vmware.1^*
standalone-plugins-package	v0.29.0-dev-standalone-plugins^*
tanzu-framework	v0.29.0^*
tanzu-framework-addons	v0.29.0^*
tanzu-framework-management-packages	v0.29.0-tf^*
tkg-bom	v2.2.0^*
tkg-core-packages	v1.25.7+vmware.2-tkg.1^*
tkg-standard-packages	v2.2.0^*
tkg-storageclass-package	v0.29.0-tkg-storageclass^*
tkg_telemetry	v2.2.0+vmware.1^*
velero	v1.9.7+vmware.1^*
velero-mgmt-cluster-plugin^*	v0.1.0+vmware.1
velero-plugin-for-aws	v1.5.5+vmware.1^*
velero-plugin-for-csi	v0.3.5+vmware.1^*
velero-plugin-for-microsoft-azure	v1.5.5+vmware.1^*
velero-plugin-for-vsphere	v1.4.3+vmware.1^*
vendir	v0.30.1+vmware.1
vsphere_csi_driver	v2.7.1+vmware.2^*
whereabouts	v0.5.4+vmware.2^*

^* Indica un nuovo componente o un bump di versione rispetto alla versione precedente. TKG v2.1.1 è precedente a v2.2.0.

Per un elenco completo delle versioni dei componenti software disponibili con TKG v2.2, utilizzare imgpkg per estrarre il bundle del repository e quindi elencarne il contenuto. Per TKG v2.2.0, ad esempio:

imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.2.0 -o standard-2.2.0
cd standard-2.2.0/packages
tree

I file BOM locali come il seguente elencano anche le versioni dei pacchetti, ma potrebbero non essere correnti:

~/.config/tanzu/tkg/bom/tkg-bom-v2.2.0.yaml
~/.config/tanzu/tkg/bom/tkr-bom-v1.25.7+vmware.1-tkg.1.yaml

Percorsi di aggiornamento supportati

Nel percorso di aggiornamento di TKG, v2.2 segue immediatamente v2.1.1.

È possibile eseguire l'aggiornamento a Tanzu Kubernetes Grid v2.2.x solo dalla versione v2.1.x. Se si desidera eseguire l'aggiornamento a Tanzu Kubernetes Grid v2.2.x da una versione precedente alla v2.1.x, è innanzitutto necessario eseguire l'aggiornamento alla versione v2.1.x.

Quando si aggiornano le versioni di Kubernetes nei cluster del carico di lavoro, non è possibile ignorare le versioni secondarie. Ad esempio, non è possibile aggiornare un cluster Tanzu Kubernetes direttamente dalla versione v1.23.x alla versione v1.25.x. Il cluster v1.23.x deve essere aggiornato alla versione v1.24.x prima di poter essere aggiornato alla versione v1.25.x.

Date di rilascio

Le date di rilascio di Tanzu Kubernetes Grid v2.2 sono:

v2.2.0: 9 maggio 2023

Modifiche del comportamento in Tanzu Kubernetes Grid v2.2

Tanzu Kubernetes Grid v2.2 non include alcun nuovo comportamento rispetto alla versione v2.1.1, ovvero la versione precedente più recente.

Avvisi relativi alle modifiche del comportamento future

In questa sezione vengono forniti avvisi anticipati delle modifiche del comportamento che verranno applicate nelle versioni future, dopo la versione TKG v2.2.

Repository di VMware Tanzu Standard

Importante
Tanzu Kubernetes Grid v2.2.x è la versione secondaria finale di TKG in cui il repository di VMware Tanzu Standard è incluso nel pacchetto della versione. TKG v2.2.x e versioni precedenti includono un set di pacchetti facoltativi nel repository di Tanzu Standard, che possono essere distribuiti nei cluster per aggiungere funzionalità come l'inoltro dei registri, il controllo dell'ingresso, un registro di container e così via. In una versione secondaria di TKG v2.x futura, il repository di Tanzu Standard non verrà scaricato automaticamente quando si installa la CLI di Tanzu e si distribuisce un cluster di gestione. Per utilizzare questo set di pacchetti facoltativo, si utilizzerà la CLI di Tanzu per scaricarli e aggiungerli manualmente. La separazione dei pacchetti facoltativi dalle versioni di TKG consentirà a VMware di fornire aggiornamenti incrementali dei pacchetti esterni alle versioni di TKG per rispondere più rapidamente ai CVE.

Avvisi di deprecazione

In una versione futura di TKG, il componente Dex verrà rimosso, perché non è più necessario per l'utilizzo di Pinniped con i provider LDAP. In seguito a questa modifica, le seguenti variabili di configurazione del cluster per l'autenticazione LDAP diventeranno obbligatorie: LDAP_BIND_DN e LDAP_BIND_PASSWORD. Per ulteriori informazioni, vedere Provider di identità - LDAP in Informazioni di riferimento sulle variabili del file di configurazione.

Documentazione per l'utente

Distribuzione e gestione di cluster di gestione autonomi TKG 2.2 include argomenti specifici dei cluster di gestione autonomi che non sono pertinenti per l'utilizzo di TKG con un supervisore vSphere with Tanzu.

Per ulteriori informazioni, vedere Documentazione di TKG appropriata per la distribuzione in uso nella pagina della documentazione di VMware Tanzu Kubernetes Grid.

Problemi risolti

I seguenti problemi indicati come problemi noti nelle versioni precedenti di Tanzu Kubernetes Grid sono stati risolti in Tanzu Kubernetes Grid v2.2.0.

La creazione di un file di configurazione ClusterClass da un file di configurazione legacy e --dry-run include una configurazione di Antrea vuota

La creazione di un file di configurazione ClusterClass utilizzando tanzu cluster create --dry-run -f con un file di configurazione legacy che include una voce ANTREA_NODEPORTLOCAL comporta la generazione automatica di una configurazione di Antrea che non include alcuna etichetta e causa la mancata riconciliazione di Antrea.
i pacchetti non sono conformi al profilo PSA baseline predefinito

Con i controller PSA in TKG, nello stato Anteprima tecnica non supportato, alcuni pacchetti TKG non sono conformi al profilo baseline predefinito.
Errore di convalida quando si esegue tanzu cluster create

Per impostazione predefinita, quando si passa un file di configurazione di tipo Kubernetes all'opzione --file di tanzu cluster create il comando converte il file di configurazione in un file di specifiche di oggetti in stile Kubernetes e poi esce. Questo comportamento è controllato dalla funzionalità auto-apply-generated-clusterclass-based-configuration impostata su false per impostazione predefinita. In alcuni casi quando si passa il file della specifica di oggetto Kubernetes generato dall'opzione --file su tanzu cluster create il comando fallisce con un errore simile al seguente:
```
Error: workload cluster configuration validation failed...
```
Questo errore può verificarsi anche quando si passa un file di specifica di tipo Kubernetes generato dall'opzione --dry-run per tanzu cluster create.
tanzu cluster create non convalida correttamente le specifiche del cluster generate con versioni di Kubernetes non predefinite

Quando si crea un cluster del carico di lavoro basato sulla classe da un file di configurazione utilizzando uno dei processi in due passaggi descritti in Creazione di un cluster basato sulla classe e si specifica un valore --tkr nel primo passaggio per basare il cluster su una versione non predefinita di Kubernetes, è possibile che il secondo passaggio non riesca a causa di errori di convalida.

Problemi noti

Di seguito sono elencati i problemi noti di Tanzu Kubernetes Grid v2.2.x. Tutti i problemi noti presenti nella versione v2.2.0 che sono stati risolti in una versione patch v2.2.x successiva sono elencati nella sezione Problemi risolti della versione patch in cui sono stati risolti.

Ulteriori soluzioni ai problemi che si verificano di frequente sono disponibili in Risoluzione dei problemi relativi al cluster di gestione e Risoluzione dei problemi relativi al cluster del carico di lavoro oppure negli articoli della Knowledge Base di VMware.

Pacchetti
Operazioni relative al cluster
Rete
Gestione di identità e accessi
Storage
CLI
vSphere
AWS
Image Builder
AVS

Pacchetti

L'installazione di Grafana non riesce in vSphere 6.7 con NSX ALB v21.1.4 o una versione precedente

Non è possibile installare il pacchetto di Grafana v7.5.17 nei cluster del carico di lavoro TKG v2.2 di vSphere v6.7U3 che utilizzano NSX ALB v21.1.4 o una versione precedente come servizio di bilanciamento del carico.

Soluzione: se i cluster del carico di lavoro utilizzano Grafana e NSX ALB, aggiornare vSphere alla versione v7.0 o successiva e NSX ALB alla versione v21.1.5 o successiva prima di aggiornare TKG alla versione v2.2.
È possibile che l'esportazione di CVE di Harbor non riesca quando l'ID esecuzione è maggiore di 1000000

In Harbor v2.7.1, che è la versione fornita nel pacchetto per TKG v2.2, è presente un problema noto per cui l'esportazione di CVE genera l'errore "404 pagina non trovata" quando l'ID con incremento automatico della chiave primaria dell'esecuzione diventa maggiore di 1000000.

Questo problema di Harbor è stato risolto nelle versioni successive di Harbor che verranno incluse nelle versioni successive di TKG.
Vulnerabilità di Golang nel componente Notary di Harbor

In Notary è presente CVE-2021-33194. Il componente Notary è stato deprecato in Harbor v2.6+ e verrà rimosso in una versione futura, come indicato nelle Note di rilascio di Harbor v2.6.0. VMware consiglia di utilizzare Sigstore Cosign anziché Notary per la firma e la verifica del container.
L'aggiunta del repository standard non riesce per i cluster a nodo singolo

L'esecuzione di tanzu package repository add per aggiungere il repository tanzu-standard a un cluster a nodo singolo del tipo descritto in Cluster a nodo singolo su vSphere (anteprima tecnica) potrebbe non riuscire.

Questo problema si verifica perché i cluster a nodo singolo vengono avviati con cert-manager come componente aggiuntivo core, in conflitto con il pacchetto cert-manager diverso nel repository tanzu-standard.

Soluzione: Prima di aggiungere il repository di tanzu-standard, applicare patch alle annotazioni del pacchetto cert-manager come descritto in Installazione di cert-manager.

Operazioni relative al cluster

Non è possibile creare nuovi cluster del carico di lavoro basati su versioni di TKr non correnti con la CNI di Antrea

Non è possibile creare un nuovo cluster del carico di lavoro che utilizza la CNI di Antrea ed esegue versioni di Kubernetes fornite con le versioni precedenti di TKG, ad esempio Kubernetes v1.23.10, che è la versione predefinita di Kubernetes in TKG v1.6.1 come indicato in Versioni di Kubernetes supportate in Tanzu Kubernetes Grid v2.2 .

Soluzione: creare un cluster del carico di lavoro che esegue Kubernetes 1.25.7, 1.24.11 o 1.23.17. Il progetto Kubernetes consiglia di eseguire componenti nella versione patch più recente di una versione secondaria corrente.
La scalabilità automatica per i cluster basati sulla classe richiede annotazioni manuali

A causa di un problema di propagazione dell'etichetta in Cluster API, le impostazioni AUTOSCALER_MIN_SIZE_* e AUTOSCALER_MAX_SIZE_* nel file di configurazione del cluster per i cluster del carico di lavoro basati sulla classe non vengono specificate negli oggetti MachineDeployment del cluster.

Soluzione: dopo aver creato un cluster del carico di lavoro basato sulla classe con la scalabilità automatica del cluster abilitata, aggiungere manualmente l'impostazione del numero di macchine minimo e massimo per ogni ZD, come descritto in Aggiunta manuale delle annotazioni delle dimensioni minima e massima.
Impossibile modificare labels e altre proprietà di configurazione del pool di nodi

Non è possibile aggiungere o modificare le proprietà labels, az, nodeMachineType o vSphere di un pool di nodi esistente, come indicato in Proprietà di configurazione.

Soluzione: creare un nuovo pool di nodi nel cluster con le proprietà desiderate, eseguire la migrazione dei carichi di lavoro nel nuovo pool di nodi ed eliminare l'originale.
Non è possibile impostare il numero di nodi del piano di controllo del cluster di gestione su un numero pari

Se si esegue tanzu cluster scale in un cluster di gestione e si passa un numero pari all'opzione --controlplane-machine-count, TKG non scala i nodi del piano di controllo e la CLI non genera un errore. Per mantenere il quorum, il numero di nodi del piano di controllo deve essere sempre dispari.

Soluzione: non modificare il numero dei nodi del piano di controllo impostandolo su un numero pari.
I nomi dei cluster basati sulla classe hanno 25 caratteri con NSX ALB come servizio di bilanciamento del carico o controller di ingresso

Quando NSX Advanced Load Balancer (ALB) viene utilizzato come servizio di bilanciamento del carico o controller di ingresso di un cluster basato sulla classe con un cluster di gestione autonomo, i nomi delle sue applicazioni includono sia il nome del cluster sia load-balancer-and-ingress-service, il nome interno per il pacchetto AKO. Quando il nome combinato supera il limite di 64 caratteri per le app del controller Avi, il comando tanzu cluster create potrebbe non riuscire e viene visualizzato un messaggio di errore che indica che lo spazio dei nomi avi-system non è stato trovato.

Soluzione: Limitare la lunghezza del nome del cluster basato sulla classe a 25 caratteri o inferiore quando si utilizza NSX ALB come controller di bilanciamento del carico o in ingresso.

Rete

Nota
A partire dalla versione 4.0, VMware NSX-T Data Center è stato rinominato con "VMware NSX".

La rete IPv6 non è supportata in vSphere 8

TKG v2.2 non supporta la rete IPv6 in vSphere 8, anche se supporta la rete IPv6 single-stack che utilizza Kube-Vip in vSphere 7 come descritto in Rete IPv6.

Soluzione: se è necessario utilizzare o si utilizza già TKG in un ambiente IPv6 in vSphere, non installare vSphere 8 o eseguire l'aggiornamento a vSphere 8.
La modalità di ingresso NodePortLocal di NSX ALB non è supportata per il cluster di gestione

In TKG v2.2, non è possibile eseguire NSX Advanced Load Balancer (ALB) come tipo di servizio con modalità di ingresso NodePortLocal per il traffico verso il cluster di gestione.

Questo problema non riguarda il supporto per l'ingresso NodePortLocal ai cluster del carico di lavoro, come descritto in Ingresso L7 in modalità NodePortLocal.

Soluzione: configurare i cluster di gestione con AVI_INGRESS_SERVICE_TYPE impostato su NodePort o ClusterIP. Il valore predefinito è NodePort.
La creazione del cluster di gestione non riesce o le prestazioni sono lente con le versioni di NSX-T precedenti e Photon 3 o Ubuntu con macchine virtuali kernel Linux 5.8

La distribuzione di un cluster di gestione con l'infrastruttura e la configurazione seguenti potrebbe non riuscire o limitare il traffico tra pod:
- vSphere con una delle versioni seguenti di NSX-T:
  - NSX-T v3.1.3 con percorso dati avanzato abilitato
  - NSX-T v3.1.x precedente alla v3.1.3
  - NSX-T v3.0.x precedente a v3.0.2 Hot Patch
  - NSX-T v2.x. È incluso Azure VMware Solution (AVS) v2.0, che utilizza NSX-T v2.5
- Immagine di base: Photon 3 o Ubuntu con kernel Linux 5.8
Con questa combinazione è possibile che si verifichi un problema di checksum tra le versioni precedenti di NSX-T e la CNI di Antrea.

TMC: se il cluster di gestione è registrato in Tanzu Mission Control (TMC), non esistono soluzioni per questo problema. In caso contrario, vedere le soluzioni seguenti.

Soluzioni:
- distribuire i cluster del carico di lavoro configurati con ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD impostato su "true". Questa impostazione disattiva l'offload del checksum UDP di Antrea, che evita i problemi noti relativi ad alcuni driver della rete underlay e della rete NIC fisica.
- Eseguire l'aggiornamento a NSX-T v3.0.2 Hot Patch, v3.1.3, o versione successiva senza che sia abilitato il percorso dati avanzato
- Utilizzare un'immagine di base Ubuntu con kernel Linux 5.9 o versione successiva.

Gestione di identità e accessi

Se si ricrea un cluster di gestione autonomo, non viene ripristinata l'autenticazione Pinniped

Dopo aver ricreato un cluster di gestione autonomo come descritto in Backup e ripristino dell'infrastruttura di cluster di gestione e del carico di lavoro (anteprima tecnica), gli utenti non possono accedere ai cluster del carico di lavoro tramite l'autenticazione Pinniped.

Soluzione: dopo aver ricreato il cluster di gestione, riconfigurare la gestione delle identità come descritto in Abilitazione e configurazione della gestione delle identità in una distribuzione esistente.
Vulnerabilità di Golang nel componente Pinniped

In Pinniped v0.12.1 è presente CVE-2022-41723. Lo sfruttamento di questa vulnerabilità può causare un attacco DDoS del servizio Pinniped. Per ridurre la probabilità di sfruttamento, è possibile utilizzare il filtro in ingresso per consentire solo il traffico proveniente da indirizzi IP noti, ad esempio CIDR della VPN aziendale. Questa vulnerabilità verrà risolta in una versione futura di Tanzu Kubernetes Grid.
La generazione e l'utilizzo di kubeconfig per il cluster del carico di lavoro distribuito dal supervisore causano l'errore "flag sconosciuto"

Nella CLI di Tanzu v0.25.0 e versioni precedenti, il plug-in cluster genera file kubeconfig che possono contenere l'argomento --concierge-is-cluster-scoped. La CLI di Tanzu v0.29.0 pinniped-auth non riconosce questo argomento. Questa regressione temporanea è stata corretta nelle versioni successive.

Poiché vSphere 8.0 integra il plug-in cluster v0.25.0, la connessione a un cluster distribuito dal supervisore dalla CLI v0.29.0, la versione in TKG v2.2, può generare questo errore:
```
Error: unknown flag: --concierge-is-cluster-scoped
Unable to connect to the server: getting credentials: exec: executable tanzu failed with exit code 1
```
Soluzione: Nel file kubeconfig rimuovere la riga in args che imposta --concierge-is-cluster-scoped.

Storage

Il cluster del carico di lavoro non può distribuire lo storage in più datastore

Non è possibile abilitare un cluster del carico di lavoro per la distribuzione dello storage in più datastore come descritto in Distribuzione di un cluster che utilizza un cluster di datastore. Se si contrassegnano più datastore in un cluster di datastore come base per il criterio di storage di un cluster del carico di lavoro, il cluster del carico di lavoro utilizza solo uno dei datastore.

Soluzione: nessuna

CLI di Tanzu

Non è possibile utilizzare caratteri non alfanumerici nelle password del proxy HTTP/HTTPS

Quando si distribuiscono cluster di gestione con la CLI, i caratteri non alfanumerici # ` ^ | / ? % ^ { [ ] } \ " < > non possono essere utilizzati nelle password. Non è inoltre possibile utilizzare i caratteri non alfanumerici nelle password del proxy HTTP/HTTPS quando si distribuiscono cluster di gestione con l'interfaccia utente.

Soluzione: è possibile utilizzare caratteri non alfanumerici diversi da # ` ^ | / ? % ^ { [ ] } \ " < > nelle password quando si distribuisce il cluster di gestione con la CLI.
La CLI di Tanzu non funziona nelle macchine macOS con processori ARM

La versione v0.11.6 della CLI di Tanzu non funziona nelle macchine macOS con chip ARM (Apple M1), come identificato in Finder > Informazioni su questo Mac > Panoramica.

Soluzione: utilizzare una macchina di bootstrap con un sistema operativo Linux o Windows oppure una macchina macOS con un processore Intel.
La CLI di Tanzu elenca i management-cluster osimage di Tanzu

Il gruppo di comando management-cluster elenca tanzu management-cluster osimage. Questa funzionalità è attualmente in fase di sviluppo e riservata per un uso futuro.

Soluzione: Non utilizzare tanzu management-cluster osimage.
L'opzione --default-values-file-output di tanzu package available get genera un file del modello di configurazione incompleto per il pacchetto Harbor

L'esecuzione di tanzu package available get harbor.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATH crea un file del modello di configurazione incompleto per il pacchetto Harbor. Per ottenere un file completo, utilizzare il comando imgpkg pull come descritto in Installazione di Harbor per il registro del servizio.

vSphere

I pool di nodi creati con nodi small possono bloccarsi durante la fase di Provisioning

I pool di nodi creati con SIZE del nodo configurata come small possono bloccarsi nello stato Provisioning e non passare mai allo stato Running.

Soluzione: configurare il pool di nodi con dimensioni del nodo almeno medium.

AWS

Il problema di assegnazione dei tag delle risorse CAPA causa un errore di riconciliazione durante la distribuzione e l'aggiornamento del cluster di gestione AWS.

A causa di un problema di assegnazione dei tag delle risorse in Cluster API Provider AWS (CAPA) upstream, le distribuzioni offline non possono accedere all'API ResourceTagging causando errori di riconciliazione durante la creazione o l'aggiornamento del cluster di gestione.

Soluzione: in un ambiente AWS offline, impostare EXP_EXTERNAL_RESOURCE_GC=false nell'ambiente locale o nel file di configurazione del cluster di gestione prima di eseguire tanzu mc create o tanzu mc upgrade.
I pool di nodi del cluster del carico di lavoro in AWS devono trovarsi nella stessa zona di disponibilità del cluster di gestione autonomo.

Quando si crea un pool di nodi configurato con una az diversa dalla posizione in cui si trova il cluster di gestione, il nuovo pool di nodi può rimanere bloccato con lo stato ScalingUp, come indicato da tanzu cluster node-pool list, e non raggiungere mai lo stato Ready.

Soluzione: creare pool di nodi solo nella stessa zona di disponibilità (az) del cluster di gestione autonomo.
L'eliminazione del cluster in AWS non riesce se il cluster utilizza risorse di rete non distribuite con Tanzu Kubernetes Grid.

I comandi tanzu cluster delete e tanzu management-cluster delete possono bloccarsi nei cluster che utilizzano risorse di rete create da AWS Cloud Controller Manager indipendentemente dal processo di distribuzione di Tanzu Kubernetes Grid. Tali risorse possono includere bilanciamenti del carico e altri servizi di rete, come indicato in Controller del servizio nella documentazione del provider di cloud AWS Kubernetes.

Per ulteriori informazioni, vedere il problema di Cluster API Drain workload clusters of service Type=Loadbalancer on teardown.

Soluzione: utilizzare kubectl delete per eliminare i servizi di tipo LoadBalancer dal cluster. Se questa soluzione non funziona, utilizzare la console AWS per eliminare manualmente LoadBalancer e SecurityGroup creati per questo servizio da Cloud Controller Manager.

Attenzione
Non eliminare i bilanciamenti del carico o i gruppi di sicurezza gestiti da Tanzu in cui sono presenti i tag key: sigs.k8s.io/cluster-api-provider-aws/cluster/CLUSTER-NAME, value: owned.

Azure

L'eliminazione del cluster non riesce quando il volume di storage utilizza un account con endpoint privato

Con un cluster del carico di lavoro di Azure in un gruppo di risorse non gestito, quando il driver CSI di Azure crea un volume persistente che utilizza un account di storage con un endpoint privato, crea risorse privateEndpoint e vNet che non vengono eliminate quando il volume persistente viene eliminato. Di conseguenza, l'eliminazione del cluster non riesce e viene visualizzato un messaggio di errore simile a subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use.

Soluzione: prima di eliminare il cluster di Azure, eliminare manualmente l'interfaccia di rete per l'endpoint privato dell'account di storage:
1. Da un browser accedere ad Azure Resource Explorer.
2. Fare clic su subscriptions a sinistra ed espandere la propria sottoscrizione.
3. Nella sottoscrizione, espandere resourceGroups a sinistra ed espandere il gruppo di risorse della distribuzione TKG.
4. Nel gruppo di risorse, espandere providers > Microsoft.Network > networkinterfaces.
5. In networkinterfaces, selezionare la risorsa NIC che non viene eliminata correttamente.
6. Fare clic sul pulsante Read/Write in alto, quindi sulla scheda Actions (POST, DELETE) subito sotto.
7. Fare clic su Elimina.
8. Dopo aver eliminato la scheda NIC, eliminare il cluster di Azure.

Windows

Worker di Windows non supportati in ambienti con limitazioni Internet

VMware non supporta i cluster del carico di lavoro TKG con nodi di lavoro di Windows in ambienti con proxy o air gap.

Soluzione: Contattare il rappresentante VMware. Alcuni utenti di TKG hanno creato immagini personalizzate di Windows ed eseguono cluster del carico di lavoro con worker di Windows in ambienti offline, ad esempio come descritto in questoarepository non ufficiale.

Image-Builder

Errori del test goss ignorabili durante il processo di creazione dell'immagine

Quando si esegue Kubernetes Image Builder per creare un'immagine di macchina personalizzata di Linux, i test goss python-netifaces, python-requests e ebtables non riescono. L'output del comando segnala gli errori. Gli errori possono essere ignorati perché non impediscono la riuscita della creazione dell'immagine.

AVS

L'eliminazione del volume vSphere CSI può non riuscire in AVS

In Azure vSphere Solution (AVS), è possibile che l'eliminazione dei volumi persistenti di vSphere CSI non riesca. L'eliminazione di un volume persistente richiede l'autorizzazione cns.searchable. L'account amministratore predefinito per AVS, [email protected], non viene creato con questa autorizzazione. Per ulteriori informazioni, vedere Ruoli e privilegi di vSphere.

Soluzione: per eliminare un volume persistente di vSphere CSI in AVS, contattare l'assistenza di Azure.