Note di rilascio di VMware Tanzu Kubernetes Grid v2.1

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

TKG v2.1 è distribuito come pacchetto della CLI di Tanzu scaricabile che distribuisce un cluster di gestione autonomo TKG con versione. TKG v2.1 è la prima versione di TKG che supporta la creazione e la gestione di cluster del carico di lavoro basati sulla classe con un cluster di gestione autonomo che può essere eseguito in più infrastrutture, tra cui vSphere, AWS e Azure.

Tanzu Kubernetes Grid v2.x 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.1 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.1.x include le nuove funzionalità seguenti.

Tanzu Kubernetes Grid v2.1.1

Nuove funzionalità di Tanzu Kubernetes Grid v2.1.1:

• Supporta l'utilizzo di NSX Advanced Load Balancer v22.1.2 o versioni successive in vSphere 8 con un cluster di gestione autonomo TKG e i relativi cluster del carico di lavoro.
• È possibile installare la versione FIPS di TKG v2.1.1. Per ulteriori informazioni, vedere Versioni compatibili con FIPS.
• Variabili di configurazione:
  • Controlli di integrità delle macchine: MHC_MAX_UNHEALTHY_CONTROL_PLANE e MHC_MAX_UNHEALTHY_WORKER_NODE. Per ulteriori informazioni, vedere Controllo di integrità delle macchine in Riferimento sulle variabili del file di configurazione.
  • Supporto per il server tdnf con certificato personalizzato: CUSTOM_TDNF_REPOSITORY_CERTIFICATE (anteprima tecnica). Per ulteriori informazioni consultare Configurazione del nodo in Riferimento sulle variabili del file di configurazione.
  • Supporto per le impostazioni del proxy a livello di nodo: TKG_NODE_SYSTEM_WIDE_PROXY (anteprima tecnica). Per ulteriori informazioni consultare Configurazione del proxy in Riferimento sulle variabili del file di configurazione.

Tanzu Kubernetes Grid v2.1.0

Nuove funzionalità di Tanzu Kubernetes Grid v2.1.0:

• Supporto per TKG 2.x: in vSphere, AWS o Azure con un cluster di gestione autonomo configurare e creare cluster basati sulla classe come descritto in Tipi di cluster del carico di lavoro.
• È possibile installare la versione FIPS di TKG v2.1.0. Per ulteriori informazioni, vedere Versioni compatibili con FIPS.
• CLI di Tanzu:
  • Il plug-in package utilizza comandi di tipo kctrl per impostazione predefinita. Vedere tanzu package in Informazioni di riferimento dei comandi della CLI di Tanzu.
  • I comandi download-bundle e upload-bundle del plug-in isolated-cluster recuperano e trasferiscono tutte le immagini del container richieste da TKG, come descritto in Preparazione di un ambiente con limitazioni Internet.
  • Le opzioni -A e --all-namespaces per tanzu cluster list includono i cluster in tutti gli spazi dei nomi gestiti dal cluster di gestione e per i quali l'utente dispone almeno delle autorizzazioni di visualizzazione, non solo lo spazio dei nomi predefinito.
  • Il gruppo di comandi context consente agli utenti di impostare e gestire i contesti per la CLI di Tanzu, tra cui il server da utilizzare come destinazione e il kubeconfig da applicare. Vedere tanzu context in Informazioni di riferimento dei comandi della CLI di Tanzu.
    • Nelle versioni future il comando tanzu login verrà sostituito dai comandi di tanzu context.
  • La categoria Target per i plug-in modifica il comportamento della CLI e aggiunge funzionalità riservate per un utilizzo futuro, come descritto di seguito in Modifiche del comportamento in Tanzu Kubernetes Grid v2.1.
  • La funzionalità auto-apply-generated-clusterclass-based-configuration applica automaticamente la configurazione del cluster basato sulla classe generata dalla CLI di Tanzu quando si passa un file di configurazione del cluster legacy a tanzu cluster create. La funzionalità è impostata su false per impostazione predefinita. Vedere Funzionalità in Architettura e configurazione della CLI di Tanzu.
  • La funzionalità allow-legacy-cluster consente di creare cluster basati sul piano. La funzionalità è impostata su false per impostazione predefinita. Vedere Funzionalità in Architettura e configurazione della CLI di Tanzu.
  • I comandi tanzu mc credentials update e tanzu cluster credentials update aggiungono opzioni per Azure. Sono inclusi --azure-client-id, --azure-client-secret e --azure-tenant-id.
• Le seguenti variabili di configurazione del cluster sono supportate per i cluster basati sulla classe e i cluster di gestione autonomi, come descritto in Informazioni di riferimento sulle variabili del file di configurazione:
  • Configurazione del nodo: CONTROL_PLANE_NODE_LABELS, CONTROL_PLANE_NODE_NAMESERVERS, CONTROL_PLANE_NODE_SEARCH_DOMAINS, WORKER_NODE_NAMESERVERS, WORKER_NODE_SEARCH_DOMAINS
  • Proprietà ExtraArgs: APISERVER_EXTRA_ARGS, CONTROLPLANE_KUBELET_EXTRA_ARGS, ETCD_EXTRA_ARGS, KUBE_CONTROLLER_MANAGER_EXTRA_ARGS, KUBE_SCHEDULER_EXTRA_ARGS, WORKER_KUBELET_EXTRA_ARGS
  • Limitazione della velocità e sincronizzazione: NTP_SERVERS, APISERVER_EVENT_RATE_LIMIT_CONF_BASE64
• I cluster possono rinnovare automaticamente i certificati della macchina virtuale del nodo del piano di controllo. Vedere Rinnovo automatico del certificato del nodo del piano di controllo.
• (vSphere) È possibile distribuire cluster di carichi di lavoro multi-OS che eseguono sia nodi worker basati su Windows che su Linux, come descritto in Distribuzione di un cluster di carichi di lavoro multi-OS. In questa versione, i cluster del carico di lavoro Windows vengono sostituiti dai cluster del carico di lavoro con più sistemi operativi. Per ulteriori informazioni, vedere Modifiche del comportamento in Tanzu Kubernetes Grid v2.1.
  • È possibile distribuire cluster del carico di lavoro con più sistemi operativi in più zone di disponibilità, come descritto in Distribuzione dei cluster del carico di lavoro in più zone di disponibilità (Anteprima tecnica vSphere).
• (vSphere) I cluster del carico di lavoro basati sulla classe possono essere configurati con IPAM (IP Address Management) nel cluster su un pool di IP allocato, eliminando la necessità di configurare le prenotazioni DHCP quando il numero o le istanze dei nodi vengono modificati.
• (vSphere) Le etichette di oggetti Machine del nodo del cluster identificano l'indirizzo del loro host ESXi per supportare l'utilizzo di nodeSelector per l'esecuzione di carichi di lavoro specifici nell'hardware specializzato.
• (vSphere) Le immagini OVA di Ubuntu utilizzano la modalità UEFI (Unified Extensible Firmware Interface) per l'avvio, sostituendo la modalità firmware BIOS tradizionale. La modalità UEFI abilita i carichi di lavoro della GPU (Graphic Processing Unit) e migliora la sicurezza dei nodi. Per ulteriori informazioni su UEFI in Ubuntu, vedere UEFI nella documentazione di Ubuntu.
• È possibile utilizzare Kube-VIP come servizio LoadBalancer L4 i carichi di lavoro. Vedere Bilanciamento del carico Kube-VIP (anteprima tecnica).
• È possibile distribuire cluster di carichi di lavoro a singolo nodo che eseguono sia i carichi di lavoro ospitati che l'infrastruttura del piano di controllo su un singolo host ESXi, per le applicazioni edge come descritto in Cluster a singolo nodo in vSphere (anteprima tecnica).
  • È possibile distribuire cluster a nodo singolo minimi in base a TKrs tiny che ne riducono al minimo il footprint.
• È possibile eseguire il backup e la distribuzione dell'infrastruttura del cluster come descritto in Backup e ripristino dell'infrastruttura di cluster di gestione e del carico di lavoro (anteprima tecnica).
• Supporta i controller PSA (Pod Security Admission) per sostituire i criteri di sicurezza pod come descritto inController Pod Security Admission (anteprima tecnica).

Versioni di Kubernetes supportate in Tanzu Kubernetes Grid v2.1

Ogni versione di Tanzu Kubernetes Grid aggiunge supporto per la versione di Kubernetes del relativo cluster di gestione, oltre a versioni di Kubernetes aggiuntive distribuite come versioni di Tanzu Kubernetes (TKr).

Qualsiasi versione di Tanzu Kubernetes Grid supporta tutte le versioni di TKr delle due linee minori precedenti di Kubernetes, ad eccezione di quando è indicato come Problema conosciuto. Ad esempio, TKG v2.1.x supporta le versioni di Kubernetes v1.23.x e v1.22.x elencate di seguito, ma non v1.21.x o le versioni precedenti.

Versione di Tanzu Kubernetes Grid	Versione di Kubernetes del cluster di gestione	Versioni di Kubernetes (TKr) fornite
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
1.5.4	1.22.9	1.22.9, 1.21.11, 1.20.15
1.5.3	1.22.8	1.22.8, 1.21.11, 1.20.15
1.5.2, 1.5.1, 1.5.0	1.22.5	1.22.5, 1.21.8, 1.20.14

Snapshot del prodotto per Tanzu Kubernetes Grid v2.1

Tanzu Kubernetes Grid v2.1 supporta le piattaforme e i sistemi operativi dell'infrastruttura seguenti, nonché i componenti di creazione e gestione, rete, storage, autenticazione, backup, migrazione e osservabilità dei cluster. Le versioni dei componenti elencate tra parentesi sono incluse in Tanzu Kubernetes Grid v2.1.1. 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.28.1
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.6)
Rete dei container	Antrea (v1.7.2), Calico (v3.24.1)
Registro dei container	Harbor (v2.6.3)
Ingresso	NSX Advanced Load Balancer Essentials e controller Avi **** (v21.1.3- v21.1.6, v22.1.1, v22.1.2), Contour (v1.22.3)	Contour (v1.22.3)	Contour (v1.22.3)
Storage	vSphere Container Storage Interface (v2.5.2*) e vSphere Cloud Native Storage	Driver Amazon EBS CSI (v1.8.0) e provider di cloud nella struttura	Driver Azure Disk CSI (v1.19.0), driver Azure File CSI (v1.21.0), 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.5)

* Versione di vsphere_csi_driver. Per un elenco completo dei componenti di vSphere Container Storage Interface inclusi in Tanzu Kubernetes Grid v1.6, 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.

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

Versioni dei componenti

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

Componente	TKG v2.1.1	TKG v2.1.0
aad-pod-identity	v1.8.13+vmware.2*	v1.8.13+vmware.1*
addons-manager	v2.1+vmware.1-tkg.3	v2.1+vmware.1-tkg.3
ako-operator	v1.7.0+vmware.3	v1.7.0+vmware.3*
alertmanager	v0.24.0+vmware.2*	v0.24.0+vmware.1
antrea	v1.7.2+vmware.1-advanced	v1.7.2+vmware.1-advanced*
aws-ebs-csi-driver	v1.8.0+vmware.2	v1.8.0+vmware.2*
azuredisk-csi-driver	v1.19.0+vmware.1	v1.19.0+vmware.1*
azurefile-csi-driver*	v1.21.0+vmware.1	v1.21.0+vmware.1
calico_all	v3.24.1+vmware.1	v3.24.1+vmware.1*
capabilities-package	v0.28.1-dev-capabilities*	v0.28.0-dev-capabilities*
carvel-secretgen-controller	v0.11.2+vmware.1	v0.11.2+vmware.1*
cloud-provider-azure	v1.1.26+vmware.1, v1.23.23+vmware.1, v1.24.10+vmware.1	v1.1.26+vmware.1*, v1.23.23+vmware.1*, v1.24.9+vmware.1*
cloud_provider_vsphere	v1.24.3+vmware.1	v1.24.3+vmware.1*
cluster-api-provider-azure	v1.6.3_vmware.1*	v1.6.1_vmware.1*
cluster_api	v1.2.8+vmware.1	v1.2.8+vmware.1*
cluster_api_aws	v2.0.2+vmware.1	v2.0.2+vmware.1*
cluster_api_vsphere	v1.5.3+vmware.1l*	v1.5.1+vmware.1l*
cni_plugins	v1.1.1+vmware.18*	v1.1.1+vmware.16*
configmap-reload	v0.7.1+vmware.2*	v0.7.1+vmware.1
containerd	v1.6.6+vmware.3*	v1.6.6+vmware.1*
contour	v1.22.3+vmware.1	v1.22.3+vmware.1*
coredns	v1.8.6+vmware.17*	v1.8.6+vmware.15*
crash-diagnostics	v0.3.7+vmware.6	v0.3.7+vmware.6*
cri_tools	v1.23.0+vmware.8*	v1.23.0+vmware.7*
csi_attacher	v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1	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	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	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	v3.2.1+vmware.1*, v3.1.0+vmware.2, v3.0.0+vmware.1
dex	v2.35.3+vmware.2	v2.35.3+vmware.2*
envoy	v1.23.3+vmware.2	v1.23.3+vmware.2*
external-dns	v0.12.2+vmware.4	v0.12.2+vmware.4*
external-snapshotter	v6.0.1+vmware.1, v5.0.1+vmware.1	v6.0.1+vmware.1, v5.0.1+vmware.1
etcd	v3.5.6+vmware.6*	v3.5.6+vmware.3*
fluent-bit	v1.9.5+vmware.1	v1.9.5+vmware.1*
gangway	v3.2.0+vmware.2	v3.2.0+vmware.2
grafana	v7.5.17+vmware.1*	v7.5.16+vmware.1
guest-cluster-auth-service	v1.2.0*	v1.1.0*
harbor	v2.6.3+vmware.1	v2.6.3+vmware.1*
image-builder	v0.1.13+vmware.2	v0.1.13+vmware.2*
image-builder-resource-bundle	v1.24.10+vmware.1-tkg.1*	v1.24.9+vmware.1-tkg.1*
imgpkg	v0.31.1+vmware.1	v0.31.1+vmware.1*
jetstack_cert-manager	v1.10.1+vmware.1	v1.10.1+vmware.1*
k8s-sidecar	v1.15.6+vmware.3*, v1.12.1+vmware.5*	v1.15.6+vmware.2, v1.12.1+vmware.3*
k14s_kapp	v0.53.2+vmware.1	v0.53.2+vmware.1*
k14s_ytt	v0.43.1+vmware.1	v0.43.1+vmware.1*
kapp-controller	v0.41.5+vmware.1, v0.38.5+vmware.2	v0.41.5+vmware.1*, v0.38.5+vmware.2*
kbld	v0.35.1+vmware.1	v0.35.1+vmware.1*
kube-state-metrics	v2.6.0+vmware.2*	v2.6.0+vmware.1*
kube-vip	v0.5.7+vmware.1	v0.5.7+vmware.1*
kube-vip-cloud-provider*	v0.0.4+vmware.2	v0.0.4+vmware.2
kube_rbac_proxy	v0.11.0+vmware.2	v0.11.0+vmware.2
kubernetes	v1.24.10+vmware.1*	v1.24.9+vmware.1*
kubernetes-csi_external-resizer	v1.4.0+vmware.1, v1.3.0+vmware.1	v1.4.0+vmware.1*, v1.3.0+vmware.1
kubernetes-sigs_kind	v1.24.10+vmware.1-tkg.1_v0.17.0*	v1.24.9+vmware.1-tkg.1_v0.17.0*
kubernetes_autoscaler	v1.24.0+vmware.1	v1.24.0+vmware.1*
load-balancer-and-ingress-service (AKO)	v1.8.2+vmware.1	v1.8.2+vmware.1*
metrics-server	v0.6.2+vmware.1	v0.6.2+vmware.1*
multus-cni	v3.8.0+vmware.2	v3.8.0+vmware.2*
pinniped	v0.12.1+vmware.1-tkg.1	v0.12.1+vmware.1-tkg.1
pinniped-post-deploy	v0.12.1+vmware.2-tkg.3	v0.12.1+vmware.2-tkg.3*
prometheus	v2.37.0+vmware.2*	v2.37.0+vmware.1*
prometheus_node_exporter	v1.4.0+vmware.2*	v1.4.0+vmware.1*
pushgateway	v1.4.3+vmware.2*	v1.4.3+vmware.1
sonobuoy	v0.56.13+vmware.1	v0.56.13+vmware.1*
standalone-plugins-package	v0.28.1-dev-standalone-plugins*	v0.28.1-dev-standalone-plugins*
tanzu-framework	v0.28.1*	v0.28.0*
tanzu-framework-addons	v0.28.1*	v0.28.0*
tanzu-framework-management-packages	v0.28.1-tf*	v0.28.0-tf*
tkg-bom	v2.1.1*	v2.1.0*
tkg-core-packages	v1.24.10+vmware.1-tkg.1*	v1.24.9+vmware.1-tkg.1*
tkg-standard-packages	v2.1.1*	v2.1.0*
tkg-storageclass-package	v0.28.1-tkg-storageclass*	v0.28.0-tkg-storageclass*
tkg_telemetry	v2.1.1+vmware.1*	v2.1.0+vmware.1*
velero	v1.9.5+vmware.1	v1.9.5+vmware.1*
velero-mgmt-cluster-plugin*	v0.1.0+vmware.1	v0.1.0+vmware.1
velero-plugin-for-aws	v1.5.3+vmware.1	v1.5.3+vmware.1*
velero-plugin-for-csi	v0.3.3+vmware.1	v0.3.3+vmware.1*
velero-plugin-for-microsoft-azure	v1.5.3+vmware.1	v1.5.3+vmware.1*
velero-plugin-for-vsphere	v1.4.2+vmware.1	v1.4.2+vmware.1*
vendir	v0.30.1+vmware.1	v0.30.1+vmware.1*
vsphere_csi_driver	v2.6.2+vmware.2	v2.6.2+vmware.2*
whereabouts	v0.5.4+vmware.1	v0.5.4+vmware.1*

^* Indica un nuovo componente o un bump di versione rispetto alla versione precedente. TKG v2.1.0 è precedente a v2.1.1 e v1.6.1 è precedente a v2.1.0.

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

imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.1.1 -o standard-2.1.1
cd standard-2.1.1/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.1.yaml
• ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml

Percorsi di aggiornamento supportati

Nel percorso di aggiornamento di TKG, v2.1 segue immediatamente v1.6. TKG v2.0 non è una versione scaricabile di TKG: è la versione di TKG incorporata nel supervisore vSphere with Tanzu in vSphere 8.

È possibile eseguire l'aggiornamento a Tanzu Kubernetes Grid v2.1.x solo dalla versione v1.6.x. Se si desidera eseguire l'aggiornamento a Tanzu Kubernetes Grid v2.1.x da una versione precedente alla v1.6.x, è innanzitutto necessario eseguire l'aggiornamento alla versione v1.6.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.21.x alla versione v1.23.x. Prima di aggiornare il cluster v1.21.x alla versione v1.23.x, è necessario aggiornarlo alla versione v1.22.x.

Date di rilascio

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

• v2.1.0: 29 gennaio 2023
• v2.1.1: 21 marzo 2023

Modifiche del comportamento in Tanzu Kubernetes Grid v2.1

Tanzu Kubernetes Grid v2.1 include i nuovi comportamenti seguenti rispetto alla versione v1.6.1, ovvero la versione precedente più recente.

• L'opzione --include-management-cluster per tanzu cluster list richiede l'opzione -A per elencare un cluster di gestione autonomo. Con l'opzione -A, il comando elenca i cluster in tutti gli spazi dei nomi.

• Per impostazione predefinita, il plug-in package della CLI di Tanzu utilizza comandi di tipo kctrl. Vedere tanzu package with kctrl in Informazioni di riferimento dei comandi della CLI di Tanzu.

  • In TKG v1.6, il plug-in package viene eseguito per impostazione predefinita con la modalità kctrl disattivata, denominata modalità legacy di seguito.

  • I comandi della modalità kctrl e della modalità legacy differiscono come segue:

    • Per creare un file di valori predefinito per la configurazione del pacchetto, i comandi kctrl-style tanzu package available get utilizzano il flag --generate-default-values-file anziché --default-values-file-output.
    • Il flag --create-namespace è stato rimosso. Se si utilizza -n o --namespace per specificare uno spazio dei nomi di destinazione, lo spazio dei nomi deve essere già presente.
    • Il flag --create è stato rimosso per package repository update.
    • Il flag --package-name è stato rinominato con --package per package installed create e package install.
    • Il flag --install è stato rimosso per package installed update.
    • Il flag globale --verbose è stato rimosso.
    • I flag --poll-interval e -poll-timeout sono stati rinominati con --wait-interval e --wait-timeout.
    • Nell'output di package available get, una tabella aggiuntiva elenca le versioni disponibili per il pacchetto.
    • Nell'output di package available list la colonna LATEST-VERSION è stata rimossa e la colonna SHORT-DESCRIPTION non viene visualizzata per impostazione predefinita. Utilizzare il flag --wide per visualizzarla.
    • Nell'output di package repository list, le colonne REPOSITORY e TAG sono state sostituite da una colonna SOURCE che include il tipo di origine (ad esempio imgpkg), l'URL del repository e il tag.

  • Vedere gli argomenti in Pacchetti gestiti dalla CLI nella documentazione di TKG v1.6 per informazioni sul funzionamento del plug-in tanzu package con la modalità kctrl disattivata.

• Il repository dei pacchetti tanzu-standard non è preinstallato nei cluster basati sulla classe. Per aggiungere il repository del pacchetto, vedere Aggiunta di un repository di pacchetti.
• Il processo di creazione del cluster di gestione della CLI di Tanzu non supporta più la creazione di un nuovo VPC. L'interfaccia del programma di installazione non include alcuna opzione per la creazione di un nuovo VPC e i file di configurazione del cluster non supportano più le opzioni AWS_* per la creazione di un nuovo VPC per un CIDR specificato. Se si desidera utilizzare un nuovo VPC, prima di distribuire un cluster di gestione autonomo in AWS, è necessario creare un VPC per la distribuzione di TKG utilizzando la console di AWS.

• La CLI di Tanzu utilizza una nuova astrazione Targets per associare gruppi di comandi diversi al tipo di server a cui i comandi vengono applicati. Il comando tanzu context list fa riferimento allo stesso concetto del tipo di contesto con il flag --target. Poiché i gruppi di comandi si basano sui plug-in della CLI:

  • I plug-in che definiscono i comandi per i cluster Kubernetes includono il valore Target k8s
  • I plug-in che definiscono i comandi per i comandi TMC includono il valore Target tmc riservato per un uso futuro
  • I plug-in che definiscono i comandi indipendenti dal contesto non includono il valore Target
  • I plug-in con nome identico per destinazioni diverse consentono alla CLI di Tanzu di adattare i comandi nei gruppi di comandi come tanzu cluster in base al contesto.

  In TKG v2.1, l'unico tipo di contesto o Target supportato è k8s, indicato anche da:

  • Kubernetes cluster operations nell'output dei comandi tanzu help
  • kubernetes nella colonna TARGET dell'output di tanzu plugin list
• VMware non consiglia di distribuire Windows cluster del carico di lavoro che dispongono solo di worker basati su Windows, come descritto nella documentazione di TKG v1.6. VMware consiglia invece di creare cluster con più sistemi operativi come descritto in Distribuzione di un cluster di carichi di lavoro multi OS. I cluster con più sistemi operativi possono eseguire container Windows e Linux, supportando così sia i componenti TKG basati su Linux sia i carichi di lavoro Linux.
• A causa delle modifiche della gestione dei certificati in Go v1.18, le macchine con bootstrap MacOS necessitano dell'aggiunta del certificato vCenter ai portachiavi prima di poter eseguire tanzu cluster create con verifica dell'identificazione personale; vedere Prerequisiti per la distribuzione del cluster.

Documentazione per l'utente

Una nuova pubblicazione, Distribuzione e gestione di cluster di gestione autonomi TKG 2.1 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

• Risolti in v2.1.1
• Risolti in v2.1.0

Risolti in v2.1.1

I seguenti problemi indicati come problemi noti in Tanzu Kubernetes Grid v2.1.0 sono stati risolti in Tanzu Kubernetes Grid v2.1.1.

• Impossibile distribuire una CNI personalizzata

  L'opzione CNI:none non funziona nei cluster del carico di lavoro distribuiti da un cluster di gestione autonomo. Le uniche opzioni disponibili sono antrea (impostazione predefinita) e calico.

• L'account utente TKG crea sessioni vCenter inattive

  L'account vSphere per TKG crea sessioni vCenter inattive, come indicato in vSphere > Host e cluster inventario > il tuo vCenter > Monitor scheda > Sessioni.

  Soluzione: Rimuovere le sessioni vCenter inattive avviando e arrestando tutte le sessioni:

  1. ssh in per vCenter come root
  2. Se richiesto, digitare shell
  3. Eseguire service-control --stop --all
  4. Attendere che i servizi vengano visualizzati come Stopped
  5. Eseguire service-control --start --all

• I servizi LoadBalancer per i cluster del carico di lavoro basati sulla classe in Azure richiedono la configurazione manuale del gateway o di front-end

  A causa della mancata corrispondenza del nome tra AzureClusterName e ClusterName, i servizi di tipo LoadBalancer distribuiti per l'utilizzo da parte delle app nei cluster del carico di lavoro di Azure basati sulla classe non sono accessibili da Internet.

  Soluzione: specificare una route personalizzata per il servizio di bilanciamento del carico, ad esempio tramite un gateway NAT, un proxy o un altro routing interno, per consentire ai nodi dietro il bilanciamento del carico di accedere a Internet.

  VMware consiglia di utilizzare un gateway NAT, se disponibile, per la connettività in uscita. Se il gateway NAT non è disponibile:

  1. Dal portale di Azure, passare alla risorsa LoadBalancer creata da CAPZ, che deve avere lo stesso nome di quella di AzureCluster.
  2. Selezionare Configurazione IP front-end (Frontend IP configuration) e fare clic su Aggiungi (Add).
  3. Creare un nuovo indirizzo IP pubblico per il servizio di bilanciamento del carico.

  4. Configurare e creare il servizio utilizzando la specifica seguente, impostando il valore loadBalancerIP sull'indirizzo IP pubblico, dove indicato da IP-ADDRESS:

       apiVersion: v1
       kind: Service
       metadata:
         name: frontend
         labels:
           app: guestbook
           tier: frontend
         namespace: sample-app
       spec:
         # Add the frontend public IP here
         loadBalancerIP: IP-ADDRESS
         type: LoadBalancer
         ports:
         - port: 80
         selector:
           app: guestbook
           tier: frontend
     

• L'aggiornamento dei cluster non aggiorna la versione di Kube-VIP

  L'aggiornamento dei cluster di gestione autonomi e dei cluster del carico di lavoro alla versione v2.1 non aggiorna kube-vip alla versione corrente.

  Soluzione: per i cluster aggiornati che utilizzano Kube-VIP per l'endpoint del piano di controllo, come configurato con AVI_CONTROL_PLANE_HA_PROVIDER = false, aggiornare il componente kube-vip:

  1. Recuperare il file BoM di TKr corrente utilizzato per l'aggiornamento del cluster. Trovare una copia locale di questo file in ~/.config/tanzu/tkg/bom/ con un nome che inizia con tkr-. Ad esempio, tkr-bom-v1.24.10+vmware.1-tkg.1.yaml.

  2. Recuperare la versione corrente di kube-vip dal file BoM, ad esempio:

     $ cat ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml | yq '.components.kube-vip'
     - version: v0.5.7+vmware.1
       images:
         kubeVipImage:
           imagePath: kube-vip
           tag: v0.5.7_vmware.1
     

  3. Recuperare l'oggetto kcp per il cluster. Il nome di questo oggetto ha il formato CLUSTER-NAME-control-plane.

     • Gli oggetti del cluster di gestione vengono creati nello spazio dei nomi tkg-system.
     • Gli oggetti cluster del carico di lavoro si trovano nello spazio dei nomi utilizzato per la creazione del cluster o default se NAMESPACE non è stato impostato.

  4. Eseguire kubectl edit per modificare l'oggetto kcp e aggiornare il percorso di kube-vip in modo che corrisponda alla versione corrente dell'immagine BoM. Individuare la posizione di questa impostazione eseguendo:

     kubectl get kcp <cluster-name>-control-plane -o jsonpath='{.spec.kubeadmConfigSpec.files[0]}' | jq
     

• L'aggiornamento dei cluster di gestione da v1.5.x a v2.1.0 causa un errore di rete del nodo dovuto a avi_ingress_node_network_list null nel segreto dell'operatore AKO

  Con i cluster di gestione autonomi originariamente creati in TKG v1.5 o versioni precedenti, l'aggiornamento a v2.1.0 imposta un valore null per avi_ingress_node_network_list nel segreto dell'operatore AKO. Ciò causa un errore di rete del nodo durante l'aggiornamento a v2.1.0 e genera errori di configurazione AVI mancanti nei registri.

  Soluzione: Dopo aver aggiornato la CLI di Tanzu a v2.1.0 ma prima di eseguire tanzu mc upgrade:

  1. Passare al contesto del cluster di gestione:

     kubectl config use-context <MGMT-CLUSTER>-admin@<MGMT-CLUSTER>
     

  2. Recuperare il segreto dell'operatore AKO e decodificarne i valori dei dati:

     kubectl get secret <MGMT-CLUSTER>-ako-operator-addon -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 --decode > values.yaml
     

  3. Aprire il file values.yaml in un editor di testo. L'impostazione avi_ingress_node_network_list sarà simile a quanto segue:

     avi_ingress_node_network_list: '""'
     

  4. Modificare l'impostazione impostandola come questa, con l'intervallo della rete del nodo del cluster:

     avi_ingress_node_network_list: '[{"networkName":"VM Network", "cidrs":["10.191.176.0/20"]}]'
     

  5. codificare i nuovi valori dei dati in base64 e registrare la stringa di output:

     base64 -w 0 values.yaml
     

  6. Modificare il segreto dell'operatore AKO:

     kubectl edit secret MGMT-CLUSTER-ako-operator-addon -n tkg-system
     

  7. Incollare la nuova stringa dei valori dei dati codificati come valore di values.yaml nel segreto. Salvare e uscire.

• TMC non può distribuire cluster basati sulla classe con motori di servizio non inclusi in Default-Group SEG.

  Tanzu Mission Control, che si integra con TKG, non può distribuire nuovi cluster basati sulla classe che utilizzano NSX ALB e sono configurati con motori di servizio non inclusi nel gruppo di motori di servizio Default-Group in NSX ALB. Questa limitazione non influisce sull'aggiornamento dei cluster del carico di lavoro esistenti configurati con motori di servizio personalizzati.

  Per ulteriori informazioni, vedere le Note di rilascio di Tanzu Mission Control.

• Catalogo TMC non supportato per l'elenco e la distribuzione dei pacchetti

  Non è possibile utilizzare la funzionalità Catalogo di Tanzu Mission Control (TMC) per elencare o installare pacchetti nei cluster del carico di lavoro TKG v2.1 come descritto in Visualizzazione dei pacchetti nella documentazione di TMC. L'interfaccia utente di TMC mostrerà il repository dei pacchetti bloccato in uno stato riconciliante.

Risolti in v2.1.0

I seguenti problemi indicati come problemi noti in Tanzu Kubernetes Grid v1.6.1 sono stati risolti in Tanzu Kubernetes Grid v2.1.0.

• È possibile che le operazioni di cluster e pod che eliminano pod non riescano se DaemonSet è configurato per ripristinare automaticamente i volumi persistenti

  Nelle installazioni in cui un DaemonSet utilizza volumi persistenti, l'eliminazione della macchina potrebbe non riuscire perché il processo di svuotamento per impostazione predefinita ignora i DaemonSet e il sistema attende indefinitamente che i volumi vengano scollegati dal nodo. Le operazioni del cluster interessate includono l'aggiornamento, la scalabilità orizzontale e l'eliminazione.

• In vSphere with Tanzu, tanzu cluster list genera un errore per gli utenti DevOps

  Quando un utente con il ruolo di tecnico DevOps, come descritto in Ruoli utente e workflow di vSphere with Tanzu, esegue tanzu cluster list, è possibile che venga visualizzato un messaggio di errore simile a Error: unable to retrieve combined cluster info: unable to get list of clusters. User cannot list resource "clusters" at the cluster scope.

  Questo problema si verifica perché tanzu cluster command senza un'opzione -n tenta di accedere a tutti gli spazi dei nomi, alcuni dei quali potrebbero non essere accessibili per un tecnico DevOps.

  Soluzione: quando si esegue tanzu cluster list, includere un valore --namespace per specificare uno spazio dei nomi a cui l'utente può accedere.

Problemi noti

Di seguito sono elencati i problemi noti di Tanzu Kubernetes Grid v2.1.x. Tutti i problemi noti presenti in v2.1.1 e che sono stati risolti in una versione patch v2.1.x successiva sono elencati in Problemi risolti per la versione patch in cui sono stati risolti.

• Aggiornamento
• Pacchetti
• Operazioni relative al cluster
• Rete
• Gestione di identità e accessi
• Storage
• CLI
• vSphere
• AWS
• Windows e cluster del carico di lavoro con più sistemi operativi
• Image Builder
• AVS

Aggiornamento

• Noti in v2.1.1
• Noti in v2.1.x

Noti in v2.1.1

Di seguito sono riportati i problemi di aggiornamento noti in v2.1.1.

• L'aggiornamento da v2.1 a v2.1.1 in vSphere non riesce

  In vSphere, l'aggiornamento da v2.1 a v2.1.1 non riesce e viene visualizzato l'errore Reconcile failed:Error. L'errore si verifica perché il pacchetto tkg-clusterclass-vsphere non viene riconciliato e l'installazione è bloccata.

  Soluzione: Annullare l'impostazione delle seguenti variabili di risorsa vSphere se sono impostate nell'ambiente locale:

  unset VSPHERE_CLONE_MODE
  unset VSPHERE_DATACENTER
  unset VSPHERE_DATASTORE
  unset VSPHERE_FOLDER
  unset VSPHERE_NETWORK
  unset VSPHERE_RESOURCE_POOL
  unset VSPHERE_SERVER
  unset VSPHERE_STORAGE_POLICY_ID
  unset VSPHERE_TEMPLATE
  unset VSPHERE_WORKER_DISK_GIB
  unset VSPHERE_WORKER_MEM_MIB
  unset VSPHERE_WORKER_NUM_CPUS
  

Noti in v2.1.x

Di seguito sono riportati i problemi di aggiornamento noti in v2.1.x.

• L'aggiornamento dei cluster in Azure non riesce

  In Azure, l'aggiornamento dei cluster di gestione e dei cluster del carico di lavoro non riesce e vengono visualizzati messaggi di errore come context deadline exceeded o unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane. Questo problema si verifica perché le operazioni in Azure impiegano a volte più tempo rispetto alle altre piattaforme.

  Soluzione: eseguire nuovamente tanzu management-cluster upgrade o tanzu cluster upgrade specificando un timeout più lungo nel flag --timeout. Il Timeout predefinito è 30 m0s.

• L'aggiornamento non riesce per i cluster di gestione autonomi originariamente creati in TKG v1.3 o versioni precedenti

  In TKG v2.1, i componenti che trasformano un cluster generico in un cluster di gestione autonomo TKG sono inclusi in un pacchetto Carvel tkg-pkg. Nei cluster di gestione autonomi originariamente creati in TKG v1.3 o versioni precedenti manca un segreto di configurazione richiesto dal processo di aggiornamento per installare tkg-pkg. L'aggiornamento non viene quindi eseguito correttamente.

  Soluzione: eseguire i passaggi aggiuntivi elencati in Aggiornamento dei cluster di gestione autonomi per i cluster di gestione autonomi creati in TKG v1.3 o versioni precedenti.

• L'aggiornamento non riesce per i cluster creati con il carattere jolly (*) nell'impostazione TKG_NO_PROXY

  TKG v1.6 non consente il carattere jolly (*) nelle impostazioni del file di configurazione del cluster per TKG_NO_PROXY. I cluster creati dalle versioni precedenti di TKG con questa impostazione richiedono una gestione speciale prima dell'aggiornamento per evitare l'errore workload cluster configuration validation failed: invalid string '*' in TKG_NO_PROXY.

  Soluzione: in base al tipo di cluster che si sta aggiornando:

  • Cluster di gestione:

    1. Passare al contesto kubectl del cluster di gestione.

    2. Modificare la mappa di configurazione kapp-controller-config:

       kubectl edit cm kapp-controller-config -n tkg-system
       

    3. Individuare il campo data.noProxy e modificarne il nome host con caratteri jolly rimuovendo *. Ad esempio, modificare *.vmware.com to .vmware.com

    4. Salvare e uscire. Il cluster è pronto per l'aggiornamento.

  • Cluster del carico di lavoro:

    1. Passare al contesto kubectl del cluster del carico di lavoro

    2. Impostare le variabili di ambiente per il nome e lo spazio dei nomi del cluster, ad esempio:

       CLUSTER_NAME=my-test-cluster
       NS=my-test-namespace
       

    3. Recuperare e decodificare i valori dei dati del controller kapp per il cluster del carico di lavoro:

       kubectl get secret "${CLUSTER_NAME}-kapp-controller-data-values" -n $NS -o json | jq -r '.data."values.yaml"' | base64 -d > "${CLUSTER_NAME}-${NS}-kapp-controller-data-values"
       

    4. Modificare il file ${CLUSTER_NAME}-${NS}-kapp-controller-data-values rimuovendo * dall'impostazione kappController.config.noProxy. Ad esempio, modificare *.vmware.com to .vmware.com.

    5. Salvare e uscire.

    6. Codificare nuovamente il file dei valori dei dati ${CLUSTER_NAME}-${NS}-kapp-controller-data-values:

       cat "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" | base64 -w 0
       

    7. Modificare il segreto ${CLUSTER_NAME}-${NS}-kapp-controller-data-values e aggiornarne l'impostazione data.value.yaml incollando la stringa dei valori dei dati appena codificata.

       kubectl edit secret "${CLUSTER_NAME}-kapp-controller-data-values" -n "${NS}"
       

    8. Salvare e uscire. Il cluster è pronto per l'aggiornamento.

• I TKr delle versioni precedenti non sono disponibili immediatamente dopo l'aggiornamento del cluster di gestione autonomo

  L'aggiornamento di un cluster di gestione autonomo da TKG v1.6 a v2.1 sostituisce il controller di origine di TKr con una versione più recente che supporta cluster basati sulla classe e quindi sincronizza nuovamente TKr. Di conseguenza, una volta completato il comando tanzu mc upgrade, tanzu cluster available-upgrades get e tanzu kubernetes-release get potrebbero non visualizzare tutte le versioni di TKr valide e la CLI di Tanzu potrebbe non essere in grado di aggiornare immediatamente i cluster del carico di lavoro.

  Soluzione: attendere qualche minuto che TKr venga nuovamente scaricato.

Pacchetti

• L'aggiornamento della configurazione richiede l'aggiornamento per alcuni pacchetti

  Problema noto in: v2.1.1

  Nel repository del pacchetto Tanzu Standard per TKG v2.1.1 non sono presenti le versioni dei pacchetti seguenti incluse nel repository v2.1.0:

  • cert-manager: 1.10.1+vmware.1-tkg.1.yml, 1.5.3+vmware.7-tkg.1.yml e 1.7.2+vmware.3-tkg.1.yml
  • external-dns: 0.10.0+vmware.1-tkg.3.yml, 0.11.0+vmware.1-tkg.3.yml e 0.12.2+vmware.4-tkg.1.yml
  • grafana: 7.5.16+vmware.1-tkg.2.yml

  Per questo motivo, dopo aver aggiornato un cluster del carico di lavoro da TKG v2.1.0 a v2.1.1, non è possibile eseguire tanzu package installed update per aggiornare le configurazioni di questi pacchetti senza aggiornare i pacchetti alle versioni più recenti:

  • cert-manager: 1.10.1+vmware.1-tkg.2.yml
  • external-dns: 0.12.2+vmware.4-tkg.2.yml
  • grafana: 7.5.17+vmware.1-tkg.1.yml

  Questo problema si verifica solo se è necessario modificare le configurazioni dei pacchetti, l'esecuzione dei pacchetti installati continua senza l'aggiornamento.

  Soluzione: Eseguire una delle operazioni seguenti:

  • Se è necessario aggiornare la configurazione del pacchetto cert-manager, external-dns o grafana:

    1. Eseguire tanzu package installed get per recuperare la versione del pacchetto.
    2. Come sopra elencato, se il repository v2.1.1 non dispone della versione del pacchetto installata, passare la versione più recente al flag -v quando si esegue tanzu package installed update.

  • Dopo aver aggiornato i cluster del carico di lavoro a TKG v2.1.1, aggiornare i tre pacchetti alle versioni precedenti.

  Per i comandi tanzu package, vedere , come descritto in Installazione e gestione dei pacchetti.

• Multus CNI non riesce in pod medium e più piccoli con NSX Advanced Load Balancer

  In vSphere, è possibile che i cluster del carico di lavoro con nodi worker medium o più piccoli che eseguono il pacchetto Multus CNI con NSX ALB non riescano e che venga visualizzato il messaggio di errore Insufficient CPU o altri.

  Soluzione: per utilizzare Multus CNI con NSX ALB, distribuire i cluster del carico di lavoro con nodi worker di dimensioni large o extra-large.

• Il file BoM di TKG contiene una versione estranea del pacchetto cert-manager

  Il file Bill of Materials (BoM) di TKG installato dalla CLI di Tanzu in ~/.config/tanzu/tkg elenca entrambe le versioni v1.5.3 e v1.7.2 per il pacchetto cert manager (jetstack_cert-manager). La versione corretta da installare è v1.5.3, come descritto in Installazione di cert-manager.

  Soluzione: installare la versione v1.5.3 di cert-manager.

• La disattivazione di Pinniped richiede l'eliminazione manuale di Secret nei cluster legacy

  Quando si disattiva la gestione delle identità esterne in un cluster di gestione, l'oggetto Secret inutilizzato di Pinniped rimane presente nei cluster del carico di lavoro legacy.

  Se un utente tenta quindi di accedere al cluster utilizzando un vecchio kubeconfig, verrà visualizzato un popup di accesso che non riesce.

  Soluzione: eliminare manualmente il Secret di Pinniped del cluster legacy come descritto in Disattivazione della gestione delle identità.

• È possibile che l'esportazione di CVE di Harbor non riesca quando l'ID esecuzione è maggiore di 1000000

  In Harbor v2.6.3, che è la versione fornita nel pacchetto per TKG v2.1, è 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.

• Nessun supporto per la cache del proxy Harbor

  Non è possibile utilizzare Harbor nella funzionalità cache proxy per l'esecuzione di Tanzu Kubernetes Grid v2.1 in un ambiente con limitazioni Internet. È comunque possibile utilizzare la cache del proxy Harbor per il proxy delle immagini delle versioni precedenti di Tanzu Kubernetes Grid e delle immagini non Tanzu come le immagini delle applicazioni.

  Soluzione: Nessuna

• 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.

  Soluzione: impostare le etichette audit=privileged e warn=privileged negli spazi dei nomi dei pacchetti interessati come descritto in Controller Pod Security Admission (anteprima tecnica).

• 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

• Noti in v2.1.1
• Noti in v2.1

Noti in v2.1.1

Di seguito sono riportati i problemi noti delle operazioni del cluster in v2.1.1.

• Impossibile creare nuovi cluster del carico di lavoro basati su versioni di TKr non correnti con CNI Antrea

  Non è possibile creare un nuovo cluster del carico di lavoro che utilizzi CNI Antrea ed esegua 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.1.

  TKG v2.1.1 supporta completamente i cluster esistenti che eseguono versioni precedenti di Kubernetes.

  Soluzione: Creare un cluster del carico di lavoro che esegue Kubernetes 1.24.10, 1.23.16 o 1.22.17. Il progetto Kubernetes consiglia di eseguire componenti nella versione patch più recente di una versione secondaria corrente.

Noti in v2.1

• 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.

  Soluzione: Nel secondo passaggio, quando si esegue tanzu cluster create una seconda volta e si passa al manifesto del cluster generato, specificare gli stessi valori --tkr e le altre opzioni specificate nel primo passaggio, come descritto in Creazione di un cluster basato sulla classe.

• 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 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. Questo problema si verifica perché in TKG 2.1.1, le risorse di AntreaConfig richiedono tkg.tanzu.vmware.com/package-name label affinché il manager dei componenti aggiuntivi installi Antrea nel cluster del carico di lavoro designato. Questo problema non si applica a 2.1.0.

  Soluzione: Aggiungere le etichette mancanti in AntreaConfig nel file di configurazione ClusterClass e tentare di creare nuovamente il cluster:

  labels:
  tkg.tanzu.vmware.com/cluster-name: rito
  tkg.tanzu.vmware.com/package-name: antrea.tanzu.vmware.com.1.7.2---vmware.1-tkg.1-advanced 
  

• La rete IPv6 non è supportata in vSphere 8

  TKG v2.1 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.1, non è possibile eseguire NSX Advanced Load Balancer (ALB) come tipo di servizio con la 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.

Storage

• La modifica dell'oggetto StorageClass predefinito causa un errore di riconciliazione nei cluster del carico di lavoro

  La modifica delle proprietà di un oggetto StorageClass predefinito incluso in TKG causa un errore di riconciliazione dei pacchetti nei cluster del carico di lavoro che utilizzano la classe di storage.

  Soluzione: per personalizzare una classe di storage, creare una nuova definizione di StorageClass con un name diverso anziché modificare la definizione dell'oggetto predefinita e riconfigurare il cluster in modo che utilizzi la nuova classe di 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

• 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.

• 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.

  Soluzione: Impostare i parametri di configurazione o i parametri elencati nell'output di errore come variabili di ambiente locali. In alternativa, per evitare questo errore, è possibile creare cluster basati sulla classe in un passaggio, senza visualizzare l'anteprima della loro configurazione, impostando la funzionalità auto-apply-generated-clusterclass-based-configuration su true e quindi eseguendo tanzu cluster create. Per impostare auto-apply-generated-clusterclass-based-configuration su true eseguire:

  tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration true
  

  In questo modo, la CLI di Tanzu consente di creare sempre cluster basati sulla classe in un unico passaggio. Per ulteriori informazioni, vedere Creazione di un cluster basato sulla classe.

• 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.

• Prompt dei comandi di Windows: caratteri estranei nelle intestazioni delle colonne di output della CLI

  Nel prompt dei comandi (CMD) di Windows, l'output del comando della CLI di Tanzu formattato in colonne include caratteri estranei nelle intestazioni delle colonne.

  Il problema non si verifica in Windows Terminal o PowerShell.

  Soluzione: nelle macchine di bootstrap di Windows, eseguire la CLI di Tanzu da Windows Terminal.

• Errore di AKODeploymentConfig ignorabile durante la creazione del cluster di gestione

  L'esecuzione di tanzu management-cluster create per creare un cluster di gestione con NSX ALB genera il seguente errore: no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???. L'errore può essere ignorato. Per ulteriori informazioni, vedere questo articolo nella Knowledge Base.

• Errori di machinehealthcheck e clusterresourceset ignorabili durante la creazione del cluster del carico di lavoro in vSphere

  Quando un cluster del carico di lavoro viene distribuito in vSphere utilizzando il comando tanzu cluster create tramite vSphere with Tanzu, l'output potrebbe includere errori relativi all'esecuzione di machinehealthcheck e all'accesso alle risorse clusterresourceset come illustrato di seguito:

  Error from server (Forbidden): error when creating "/tmp/kubeapply-3798885393": machinehealthchecks.cluster.x-k8s.io is forbidden: User "sso:[email protected]" cannot create resource "machinehealthchecks" in API group "cluster.x-k8s.io" in the namespace "tkg"
  ...
  Error from server (Forbidden): error when retrieving current configuration of: Resource: "addons.cluster.x-k8s.io/v1beta1, Resource=clusterresourcesets", GroupVersionKind: "addons.cluster.x-k8s.io/v1beta1, Kind=ClusterResourceSet"
  ...
  

  Il cluster del carico di lavoro viene creato correttamente. È possibile ignorare gli errori.

• La CLI segnala temporaneamente per errore lo stato dei nodi eliminati di recente quando i controlli MHC sono disattivati

  Quando i controlli di integrità delle macchine (MHC) sono disattivati, i comandi della CLI di Tanzu come tanzu cluster status potrebbero non segnalare lo stato aggiornato del nodo durante la ricreazione dell'infrastruttura.

  Soluzione: Nessuna

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.

• Con NSX ALB, non è possibile creare cluster con nomi identici

  Se si utilizza NSX Advanced Load Balancer per i carichi di lavoro (AVI_ENABLE) o il piano di controllo (AVI_CONTROL_PLANE_HA_PROVIDER), è possibile che il controller Avi non riesca a distinguere i cluster con nome identico.

  Soluzione: impostare un valore CLUSTER_NAME univoco per ogni cluster:

  • Cluster di gestione: non creare più cluster di gestione con lo stesso valore CLUSTER_NAME, anche da macchine di bootstrap diverse.

  • Cluster del carico di lavoro: non creare più cluster del carico di lavoro che hanno lo stesso CLUSTER_NAME e si trovano anche nello stesso spazio dei nomi del cluster di gestione, come specificato dal valore NAMESPACE.

• L'aggiunta della gestione delle identità esterne a una distribuzione esistente può richiedere l'impostazione di un valore fittizio di VSPHERE_CONTROL_PLANE_ENDPOINT

  L'integrazione di un provider di identità esterno con una distribuzione TKG esistente può richiedere l'impostazione di un valore fittizio di VSPHERE_CONTROL_PLANE_ENDPOINT nel file di configurazione del cluster di gestione utilizzato per creare il segreto del componente aggiuntivo, come descritto in Generazione del segreto del componente aggiuntivo Pinniped per il cluster di gestione

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 e cluster del carico di lavoro con più sistemi operativi

• Non è possibile creare un'immagine di macchina Windows in una macchina MacOS

  A causa di un problema relativo all'utilità packer open source utilizzata da Kubernetes Image Builder, non è possibile creare un'immagine di macchina Windows in una macchina MacOS come descritto in Immagini delle macchine personalizzate di Windows.

  Soluzione: utilizzare una macchina Linux per creare immagini di macchine Windows personalizzate.

• Il backup e il ripristino non sono supportati per i cluster del carico di lavoro Windows e multi OS

  Non è possibile eseguire il backup e il ripristino dei cluster del carico di lavoro con nodi di lavoro basati su Windows.

  Soluzione: nessuna

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.