Note di rilascio di VMware Tanzu Kubernetes Grid v2.3

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

TKG v2.3 viene distribuito come pacchetto della CLI di Tanzu scaricabile che distribuisce un cluster di gestione autonomo TKG con versione. TKG v2.3 supporta la creazione e la gestione di cluster del carico di lavoro basato 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. Poiché la versione precedente di TKG è incorporata nel supervisore, alcune delle funzionalità che sono disponibili se si utilizza un cluster di gestione autonomo TKG 2.3 non sono disponibili se si utilizza un supervisore vSphere with Tanzu per creare cluster del carico di lavoro. Le versioni future di TKG verranno incorporate nel supervisore nelle prossime versioni di aggiornamento di vSphere. Di conseguenza, la versione di TKG incorporata nell'ultima versione di vSphere with Tanzu in un determinato momento potrebbe essere meno recente dell'ultima versione autonoma di TKG. 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. Ad esempio, CLI di Tanzu v1.0.0 è completamente compatibile con i plug-in di TKG 2.2 forniti dal supervisore.

CLI di Tanzu in vSphere with Tanzu in vSphere 7

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.3.x include le nuove funzionalità seguenti.

Tanzu Kubernetes Grid v2.3.1

Nuove funzionalità di Tanzu Kubernetes Grid v2.3.1:

Tanzu Kubernetes Grid v2.3.0

Nuove funzionalità di Tanzu Kubernetes Grid v2.3.0:

  • Nuovo meccanismo di distribuzione per i plug-in della CLI di Tanzu autonomi, inclusi i plug-in della CLI di Tanzu autonomi per Tanzu Kubernetes Grid. Inoltre, la CLI principale di Tanzu viene ora distribuita separatamente da Tanzu Kubernetes Grid. Per istruzioni su come installare la CLI di Tanzu da utilizzare con Tanzu Kubernetes Grid, vedere Installazione della CLI di Tanzu e della CLI di Kubernetes per l'utilizzo con i cluster di gestione autonomi.
  • La versione del repository dei pacchetti Tanzu Standard viene definita e distribuita separatamente da TKG; vedere Repository Tanzu Standard v2023.7.13 di seguito.
    • La versione compatibile più recente del Repository Tanzu Standard per TKG v2.3.0 è Repository Tanzu Standard v2023.7.13.
  • È possibile eseguire cluster di gestione del carico di lavoro e autonomi in più zone di disponibilità (ZD) e modificare le ZD in cui vengono eseguiti i nodi.
    • Per informazioni su come distribuire nuovi cluster del carico di lavoro in più zone di disponibilità e modificare i cluster di gestione e del carico di lavoro esistenti in modo che vengano eseguiti in più zone di disponibilità o in diverse zone di disponibilità, vedere Esecuzione dei cluster in più zone di disponibilità.
    • Per utilizzare l'interfaccia del programma di installazione di per configurare un nuovo cluster di gestione autonomo da eseguire su più ZD, vedere Configurazione delle risorse di vSphere.
    • Il supporto per più ZD è nello stato della funzionalità Stabile.
  • I cluster a nodo singolo possono essere aggiornati e sono supportati per Telco Cloud Automation (TCA). Vedere Cluster a nodo singolo in vSphere.
    • La procedura di distribuzione semplificata non richiede l'aggiunta di TKR tiny al cluster di gestione.
    • Non è possibile utilizzare Tanzu Mission Control (TMC) per creare e gestire cluster con un nodo singolo, ma questa funzione è pianificata per una versione futura di TMC.
  • È possibile configurare un controller di ammissione sicurezza pod (PSA) a livello di cluster con nuove variabili del file di configurazione del cluster POD_SECURITY_STANDARD_* e le impostazioni podSecurityStandard della specifica Cluster come descritto in Controller di ammissione sicurezza pod.
    • Il supporto di PSA si trova nello stato della funzionalità Stabile.
  • (vSphere) Per le funzionalità di gestione indirizzi IP (IPAM) nel cluster espanse, vedere IPAM del nodo:
    • IPAM per cluster di gestione autonomi, oltre ai cluster del carico di lavoro basati sulla classe.
    • Supporto IPv6.
    • I cluster del carico di lavoro in spazi dei nomi di gestione diversi possono allocare indirizzi IP dallo stesso pool di IP globale.
    • I pool di IP possono contenere intervalli di IP non contigui.
    • La query del pool di IP kubectl get inclusterippool ha come output i conteggi degli indirizzi FREE e USED.
    • Variabili di configurazione del cluster, descritte in IPAM del nodo in Informazioni di riferimento sulle variabili del file di configurazione.
    • La strutture dell'oggetto InClusterIPPool è diversa dalle versioni precedenti di TKG. L'aggiornamento del cluster alla versione 2.3 converte i pool di IP in una nuova struttura.
  • I cluster che utilizzano la CNI di Calico eseguono il rilevamento degli indirizzi IP; vedere CNI di Calico in Rete di pod e container.
  • I cluster del carico di lavoro Edge con storage isolato possono utilizzare i propri modelli di macchine virtuali archiviati in locale; vedere Specifica di un modello di macchina virtuale locale.
  • La nuova variabile del file di configurazione del cluster VSPHERE_MTU imposta le dimensioni dell'unità massima di trasmissione (MTU) per i nodi del cluster di gestione e del carico di lavoro in vSphere; vedere Configurazione di MTU del nodo del cluster.
  • È possibile configurare cluster in modo che utilizzino immagini di macchine alternative annotando le specifiche degli oggetti e senza creare o modificare i TKr; vedere Utilizzo di un'immagine di macchina alternativa.
  • (vSphere) CONTROL_PLANE_NODE_NAMESERVERS e WORKER_NODE_NAMESERVERS si trovano ora nello stato Stabile. È possibile impostare queste variabili per i nodi in esecuzione in Ubuntu o Photon; Windows non è supportato. Per un caso d'uso di esempio, vedere IPAM del nodo.
  • Ora è possibile aggiornare i cluster creati da una definizione ClusterClass personalizzata in una versione precedente. Per ulteriori informazioni, vedere Aggiornamento dei cluster personalizzati.
  • Nuovi flag per i controlli di integrità delle macchine, --max-unhealthy e --machine-deployment; vedere Gestione dei controlli di integrità delle macchine per i cluster del carico di lavoro.
  • La nuova opzione tanzu mc credentials update --vsphere-thumbprint consente di utilizzare la CLI di Tanzu per aggiornare l'identificazione personale TLS del vCenter Server nei cluster di gestione e nei cluster del carico di lavoro in vSphere. Vedere Aggiornamento delle credenziali dei cluster.
  • Per impostazione predefinita, ai cluster basati su piano appena creati non viene aggiunto il repository di pacchetti Tanzu Standard.

  • Il componente Pinniped non utilizza più Dex per i provider di identità LDAP, con conseguenti modifiche della configurazione:

    • Nuova variabile di configurazione: LDAP_GROUP_SEARCH_SKIP_ON_REFRESH
    • Variabili di configurazione aggiornate:
    • LDAP_BIND_DN e LDAP_BIND_PASSWORD sono ora necessarie.
    • LDAP_GROUP_SEARCH_NAME_ATTRIBUTE è dn per impostazione predefinita.
    • LDAP_USER_SEARCH_FILTER e LDAP_GROUP_SEARCH_FILTER devono essere impostate nel formato utilizzato da Pinniped.
    • Variabili di configurazione rimosse: LDAP_USER_SEARCH_USERNAME LDAP_USER_SEARCH_EMAIL_ATTRIBUTE e LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE.

    La rimozione di Dex indica che è necessario modificare le impostazioni LDAP di un cluster di gestione prima di aggiornarlo a TKG v2.3; vedere (Solo LDAP) Aggiornamento delle impostazioni LDAP.
    Per ulteriori informazioni sulle variabili di configurazione nuove e aggiornate, vedere Provider di identità - LDAP in Informazioni di riferimento sulle variabili del file di configurazione.

  • Poiché il repository di pacchetti Tanzu Standard viene distribuito separatamente da TKG, il file BoM di TKG non elenca più un'immagine del container grafana. In una versione futura è prevista la rimozione di altri componenti Tanzu Standard dalla console di gestione dei componenti.

Repository Tanzu Standard

Con TKG v2.3, la versione del repository dei pacchetti Tanzu Standard viene definita e distribuita separatamente da TKG e il controllo delle versioni è basato su un’indicazione di data. Per ulteriori informazioni, vedere Repository Tanzu Standard v2023.7.13 riportato di seguito.

Per ogni versione della patch di TKG v2.3, le note di rilascio della versione compatibile più recente del Repository Tanzu Standard sono:

Versioni di Kubernetes, TKG e pacchetto supportate

A partire da TKG v2.2, il criterio di supporto di VMware è cambiato 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 prime due 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.

Nella terza sezione sono elencate le versioni dei pacchetti nel repository Tanzu Standard supportate dai Tkr di Kubernetes v1.26, v1.25 e v1.24.

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.3 con Kubernetes v1.26, v1.25 e v1.24 al momento del rilascio. Quando TKG v2.1 raggiunge l'attività cardine della fine del supporto generale, VMware non supporterà più Kubernetes v1.24 con TKG. Quando TKG v2.2 raggiunge l'attività cardine della fine del supporto generale, VMware non supporterà più Kubernetes v1.25 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.

Le versioni patch di Tanzu Kubernetes Grid supportano o supportavano 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.3.1 1.26.8 1.26.8, 1.25.13, 1.24.17
2.3.0 1.26.5 1.26.5, 1.25.10, 1.24.14
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

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. 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.3.0 terminerà due mesi dopo il rilascio della versione General Availability di TKG v2.3.1.

Versioni dei pacchetti supportate

Per TKG v2.3, le versioni dei pacchetti nel repository Tanzu Standard sono compatibili con TKr per le versioni secondarie v1.26, v1.25 e v1.24 di Kubernetes come indicato di seguito:

Pacchetto Versione pacchetto TKr Kubernetes v1.26 Kubernetes v1.25 TKr Kubernetes v1.24 TKr
Cert Manager
cert-manager.tanzu.vmware.com		 1.11.1+vmware.1-tkg.1-20230629 ✔ ✔ ✔
Contour
contour.tanzu.vmware.com		 1.24.4+vmware.1-tkg.1-20230629 ✔ ✔ ✔
DNS esterno
external-dns.tanzu.vmware.com		 0.13.4+vmware.2-tkg.1-20230629 ✔ ✔ ✔
0.12.2+vmware.5-tkg.2-20230629 ✔ ✔ ✔
0.11.1+vmware.5-tkg.2-20230629 ✖ ✖ ✔
Fluent Bit
fluent-bit.tanzu.vmware.com		 2.1.2+vmware.1-tkg.1-20230629 ✔ ✔ ✔
1.9.5+vmware.1-tkg.3-zshippable ✔ ✔ ✔
1.8.15+vmware.1-tkg.1 ✖ ✖ ✔
Controller della guida di FluxCD
fluxcd-helm-controller.tanzu.vmware.com		 0.32.0+vmware.1-tkg.2-20230629 ✔ ✔ ✔
0.21.0+vmware.1-tkg.1-zshippable ✖ ✖ ✔
Controller di origine FluxCD
fluxcd-source-controller.tanzu.vmware.com		 0.33.0+vmware.2-tkg.1-20230629 ✔ ✔ ✔
Grafana
grafana.tanzu.vmware.com		 9.5.1+vmware.2-tkg.1-20230629 ✔ ✔ ✔
7.5.17+vmware.1-tkg.3-zshippable ✖ ✖ ✔
Harbor
harbor.tanzu.vmware.com		 2.8.2+vmware.2-tkg.1-20230629 ✔ ✔ ✔
Multus CNI
multus-cni.tanzu.vmware.com		 3.8.0+vmware.3-tkg.1 ✔ ✔ ✔
4.0.1+vmware.1-tkg.1-20230629 ✔ ✔ ✔
Prometheus
prometheus.tanzu.vmware.com		 2.43.0+vmware.2-tkg.1-20230629 ✔ ✔ ✔
2.37.0+vmware.3-tkg.1 ✔ ✔ ✔
2.36.2+vmware.1-tkg.1 ✖ ✖ ✔
Whereabouts
whereabouts.tanzu.vmware.com		 0.6.1+vmware.2-tkg.1-20230629 ✔ ✔ ✔
0.5.4+vmware.2-tkg.1 ✔ ✔ ✔

Snapshot del prodotto per Tanzu Kubernetes Grid v2.3

Tanzu Kubernetes Grid v2.3 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.

Per informazioni su ulteriori versioni dei pacchetti compatibili con TKG v2.3, vedere le Note di rilascio del Repository Tanzu Standard v2023.10.16 nella documentazione relativa ai pacchetti Tanzu.

Per un elenco completo delle versioni dei componenti incluse in TKG v2.3, vedere Versioni dei componenti.

vSphere AWS Azure
Piattaforma dell'infrastruttura
  • vSphere 7.0, 7.0U1-U3
  • vSphere 8.0 e 8.0U1
  • VMware Cloud on AWS* v1.20, v1.22
  • Azure VMware Solution v2.0
 AWS nativo Azure nativo
CLI di Tanzu CLI principale di Tanzu v1.0.0**
API TKG e infrastruttura del pacchetto Tanzu Framework v0.30.2
Creazione e gestione di cluster Core Cluster API (v1.4.5), Cluster API Provider vSphere (v1.7.1) Core Cluster API (v1.4.5), Cluster API Provider AWS (v2.1.3) Core Cluster API (v1.4.5), Cluster API Provider Azure (v1.9.2)
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.11.2), Calico (v3.25.1), Multus CNI (v4.0.1, v3.8.0)
Registro dei container Harbor (v2.8.4)
Ingresso NSX Advanced Load Balancer Essentials and Avi Controller **** (v21.1.4-v21.1.6, v22.1.2-v22.1.3), NSX v4.1.0 (vSphere 8.0.u1), v3.2.2 (vSphere 7), Contour (v1.25.2) Contour (v1.25.2) Contour (v1.25.2)
Storage vSphere Container Storage Interface (v3.0.1***) e vSphere Cloud Native Storage Driver Amazon EBS CSI (v1.18.0) e provider di cloud nella struttura Driver Azure Disk CSI (v1.27.1), driver Azure File CSI (v1.27.0) e provider di cloud nella struttura
Autenticazione OIDC e LDAP tramite Pinniped (v0.24.0)
Osservabilità Fluent Bit (v2.1.6), Prometheus (v2.45.0, v2.37.0)******, Grafana (v10.0.1)
Esplorazione dei servizi DNS esterno (v0.13.4)
Backup e migrazione Velero (v1.10.3)

* Per un elenco delle versioni dell'SDDC di VMware Cloud on AWS compatibili con questa versione, vedere VMware Product Interoperability Matrix.

** Per un elenco completo delle versioni della CLI di Tanzu compatibili con questa versione, vedere Product Interoperability Matrix.

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

***** Versione di vsphere_csi_driver. Per un elenco completo dei componenti di vSphere Container Storage Interface inclusi in questa versione, vedere Versioni dei componenti.

****** Se si aggiorna un cluster a Kubernetes v1.25, è necessario aggiornare Prometheus come minimo 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.3, vedere l'argomento Versioni di Kubernetes supportate precedente.

Versioni dei componenti

La versione di TKG v2.3.x include le seguenti versioni dei componenti software:

Nota

Le versioni precedenti di TKG includevano componenti che ora vengono distribuiti tramite il repository Tanzu Standard. Per un elenco di questi componenti, vedere Repository Tanzu Standard di seguito.

Componente TKG v2.3.1 TKG v2.3.0
aad-pod-identity v1.8.15+vmware.2 v1.8.15+vmware.2*
addons-manager v2.2+vmware.1 v2.2+vmware.1*
ako-operator v1.9.0_vmware.1 v1.9.0_vmware.1*
alertmanager v0.25.0_vmware.4* v0.25.0_vmware.3*
antrea v1.11.2_vmware.1* v1.11.1_vmware.4*
antrea-interworking v0.11.1* v0.11.0*
aws-ebs-csi-driver v1.18.0+vmware.2 v1.18.0+vmware.2*
azuredisk-csi-driver v1.27.1+vmware.3* v1.27.1+vmware.2*
azurefile-csi-driver v1.27.0+vmware.3* v1.27.0+vmware.2*
calico v3.25.1+vmware.2 v3.25.1+vmware.2*
capabilities-package v0.30.2-capabilities* v0.30.2-capabilities*
carvel-secretgen-controller v0.14.2+vmware.2 v0.14.2+vmware.2*
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.10+vmware.1
cloud_provider_vsphere

v1.24.6+vmware.1,
v1.26.2+vmware.1,
v1.25.3+vmware.1

v1.24.6+vmware.1*,
v1.26.2+vmware.1*,
v1.25.3+vmware.1*
cluster-api-provider-azure v1.9.2+vmware.1 v1.9.2+vmware.1*
cluster_api v1.4.5+vmware.1* v1.4.2+vmware.3*
cluster_api_aws v2.1.3+vmware.0 v2.1.3+vmware.0*
cluster_api_vsphere v1.7.1+vmware.0* v1.7.0+vmware.0*
cni_plugins v1.1.1+vmware.28* v1.1.1+vmware.23*
configmap-reload v0.8.0+vmware.3* v0.8.0+vmware.2*
containerd v1.6.18+vmware.1 v1.6.18+vmware.1
coredns v1.9.3+vmware.16* v1.9.3+vmware.11*
crash-diagnostics v0.3.7+vmware.7 v0.3.7+vmware.7*
cri_tools v1.25.0+vmware.10* v1.25.0+vmware.6*
csi_attacher v4.2.0+vmware.4*,
v4.0.0+vmware.1,
v3.5.0+vmware.1,
v3.4.0+vmware.1,
v3.3.0+vmware.1		 v4.2.0+vmware.2*,
v4.0.0+vmware.1*,
v3.5.0+vmware.1,
v3.4.0+vmware.1,
v3.3.0+vmware.1
csi_livenessprobe v2.9.0+vmware.4*,
v2.8.0+vmware.1,
v2.7.0+vmware.1,
v2.6.0+vmware.1,
v2.5.0+vmware.1,
v2.4.0+vmware.1		 v2.9.0+vmware.2*,
v2.8.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.7.0+vmware.4*,
v2.7.0+vmware.2,
v2.6.3+vmware.1,
v2.6.2+vmware.1,
v2.5.1+vmware.1,
v2.5.0+vmware.1,
v2.3.0+vmware.1		 v2.7.0+vmware.1*,
v2.7.0+vmware.2*,
v2.6.3+vmware.1*,
v2.6.2+vmware.1*,
v2.5.1+vmware.1,
v2.5.0+vmware.1,
v2.3.0+vmware.1
csi_provisioner v3.4.1+vmware.3*,
v3.4.0+vmware.4*,
v3.3.0+vmware.1,
v3.2.1+vmware.1,
v3.1.0+vmware.2		 v3.4.1+vmware.2*,
v3.4.0+vmware.2*,
v3.3.0+vmware.1*,
v3.2.1+vmware.1,
v3.1.0+vmware.2
dex N/D Rimosso
envoy v1.25.9+vmware.1* v1.25.6+vmware.1*
external-snapshotter v6.2.1+vmware.4*,
v6.1.0+vmware.1,
v6.0.1+vmware.1,
v5.0.1+vmware.1		 v6.2.1+vmware.2*,
v6.1.0+vmware.1*,
v6.0.1+vmware.1,
v5.0.1+vmware.1
etcd v3.5.6+vmware.20* v3.5.6+vmware.14*
guest-cluster-auth-service v1.3.0_tkg.2 v1.3.0_tkg.2
image-builder v0.1.14+vmware.1 v0.1.14+vmware.1*
image-builder-resource-bundle v1.26.8+vmware.1-tkg.2* v1.26.5+vmware.2-tkg.1*
imgpkg v0.36.0+vmware.2 v0.36.0+vmware.2*
jetstack_cert manager (cert-manager) v1.11.1+vmware.1 v1.11.1+vmware.1*
k8s-sidecar v1.22.4+vmware.2* v1.22.0+vmware.2*,
v1.15.6+vmware.5,
v1.12.1+vmware.6
k14s_kapp (kapp) v0.55.0+vmware.2 v0.55.0+vmware.2*
k14s_ytt (ytt) v0.45.0+vmware.2 v0.45.0+vmware.2*
kapp-controller v0.45.2+vmware.1 v0.45.2+vmware.1*
kbld v0.37.0+vmware.2 v0.37.0+vmware.2*
kube-state-metrics v2.8.2+vmware.1 v2.8.2+vmware.1*
kube-vip v0.5.12+vmware.1 v0.5.12+vmware.1
kube-vip-cloud-provider v0.0.5+vmware.1,
v0.0.4+vmware.4		 v0.0.5+vmware.1*,
v0.0.4+vmware.4
kubernetes v1.26.8+vmware.1*,
v1.25.13+vmware.1*,
v1.24.17+vmware.1*		 v1.26.5+vmware.2*,
v1.25.10+vmware.2*,
v1.24.14+vmware.2
kubernetes-csi_external-resizer v1.7.0+vmware.4*,
v1.6.0+vmware.1,
v1.5.0+vmware.1,
v1.4.0+vmware.1		 v1.7.0+vmware.2*,
v1.6.0+vmware.1*,
v1.5.0+vmware.1*,
v1.4.0+vmware.1
kubernetes-sigs_kind v1.26.8+vmware.1-tkg.2_v0.17.0*,
v1.25.13+vmware.2-tkg.1_v0.17.0*,
v1.24.17+vmware.2-tkg.1_v0.17.0*		 v1.26.5+vmware.2-tkg.1_v0.17.0*,
v1.25.10+vmware.2-tkg.1_v0.17.0*,
v1.24.14+vmware.2-tkg.1_v0.17.0*
kubernetes_autoscaler v1.26.2+vmware.1 v1.26.2+vmware.1*
load-balancer-and-ingress-service (AKO) v1.9.3+vmware.2-tkg.1 v1.9.3+vmware.2-tkg.1*
metrics-server v0.6.2+vmware.1 v0.6.2+vmware.1
pinniped v0.24.0+vmware.1-tkg.1 v0.24.0+vmware.1-tkg.1*
pinniped-post-deploy v0.24.0+vmware.1 v0.24.0+vmware.1*
prometheus_node_exporter v1.5.0+vmware.3* v1.5.0+vmware.2*
pushgateway v1.5.1+vmware.3* v1.5.1+vmware.2*
sonobuoy v0.56.16+vmware.2 v0.56.16+vmware.2*
tanzu-framework v0.30.2* v0.30.2*
tanzu-framework-addons v0.30.2* v0.30.2*
tanzu-framework-management-packages v0.30.2* v0.30.2*
tkg-bom v2.3.1* v2.3.0*
tkg-core-packages v1.26.8+vmware.1-tkg.2* v1.26.8+vmware.2-tkg.1*
tkg-standard-packages v2023.10.16* v2023.7.13*
tkg-storageclass-package v0.30.2* v0.30.2*
tkg_telemetry v2.3.1+vmware.3* v2.3.0+vmware.2*
velero v1.10.3+vmware.1 v1.10.3+vmware.1*
velero-mgmt-cluster-plugin* v0.2.0+vmware.1 v0.2.0+vmware.1*
velero-plugin-for-aws v1.6.2+vmware.1 v1.6.2+vmware.1*
velero-plugin-for-csi v0.4.3+vmware.1 v0.4.3+vmware.1*
velero-plugin-for-microsoft-azure v1.6.2+vmware.1 v1.6.2+vmware.1*
velero-plugin-for-vsphere v1.5.1+vmware.1 v1.5.1+vmware.1*
vendir v0.33.1+vmware.2 v0.33.1+vmware.2*
vsphere_csi_driver v3.0.1+vmware.4* v3.0.1+vmware.2*

* Indica un nuovo componente o un bump di versione rispetto alla versione precedente. TKG v2.3.0 è precedente a v2.3.1 e TKG v2.2.0 è precedente a v2.3.0.

Per un elenco delle versioni dei componenti software forniti insieme a TKG v2.3, utilizzare imgpkg per estrarre il bundle del repository e quindi elencarne il contenuto. Ad esempio, per elencare le versioni dei componenti forniti con il repository Tanzu Standard per TKG v2.3.1, eseguire il comando seguente:

imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2023.10.16 -o standard-2023.10.16

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.3.1.yaml
  • ~/.config/tanzu/tkg/bom/tkr-bom-v1.26.8+vmware.2-tkg.1.yaml

Percorsi di aggiornamento supportati

Nel percorso di aggiornamento di TKG, v2.3 segue immediatamente v2.2.0.

È possibile eseguire l'aggiornamento a Tanzu Kubernetes Grid v2.3.x solo dalla versione v2.2.x. Se si desidera eseguire l'aggiornamento a Tanzu Kubernetes Grid v2.3.x da una versione precedente alla v2.2.x, è innanzitutto necessario eseguire l'aggiornamento alla versione v2.2.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.24.x alla versione v1.26.x. Il cluster v1.24.x deve essere aggiornato alla versione v1.25.x prima di poter essere aggiornato alla versione v1.26.x.

Date di rilascio

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

  • v2.3.1: 9 novembre 2023
  • v2.3.0: 1° agosto 2023

Modifiche del comportamento in Tanzu Kubernetes Grid v2.3

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

  • Gli strumenti Carvel vengono forniti in un bundle di download dedicato. Per informazioni, vedere Installazione degli strumenti Carvel.

  • Quando si utilizza un provider di identità (IDP) OIDC per la gestione delle identità e degli accessi tramite Pinniped, il provider deve essere configurato in modo da emettere un token di aggiornamento.

    • Questa operazione potrebbe richiedere alcune configurazioni aggiuntive nel provider di identità OIDC.
    • Per un esempio di Okta, vedere Configurazione della gestione delle identità.
    • Se il provider di identità OIDC richiede ambiti o parametri aggiuntivi per restituire un token di aggiornamento, configurare OIDC_IDENTITY_PROVIDER_SCOPES e OIDC_IDENTITY_PROVIDER_ADDITIONAL_AUTHORIZE_PARAMS con gli ambiti o i parametri necessari.
  • Tanzu Kubernetes Grid non utilizza più Dex per i provider di identità LDAP. Ogni variabile di configurazione elencata nella sezione Provider di identità - LDAP delle Informazioni di riferimento sulle variabili del file di configurazione corrisponde ora a un'impostazione di configurazione nella risorsa personalizzata LDAPIdentityProvider di Pinniped. Prima di aggiornare un cluster di gestione configurato per l'utilizzo di un provider di identità LDAP a Tanzu Kubernetes Grid v2.3, aggiornare le impostazioni LDAP come descritto in (Solo LDAP) Aggiornamento delle impostazioni LDAP. Tutte le impostazioni LDAP esistenti verranno migrate automaticamente nel nuovo formato Pinniped durante l'aggiornamento del cluster di gestione a v2.3.
  • Velero v1.10 introduce Modifiche importanti rispetto alle versioni di Velero fornite con le versioni precedenti di TKG. Per informazioni su come mitigare queste modifiche importanti che si verificano durante l'aggiornamento da Velero v1.9.x a v1.10, vedere Aggiornamento di Velero.
  • Durante l'aggiornamento di Tanzu Kubernetes Grid a v2.3 in AWS, è necessario eseguire tanzu mc permissions aws set dopo l'aggiornamento della CLI di Tanzu ma prima di aggiornare il cluster di gestione. Per ulteriori informazioni, vedere la scheda AWS in Prepazione all'aggiornamento dei cluster.
  • Quando si creano definizioni di oggetti ClusterClass personalizzate, non si scarica più il manifesto predefinito dal repository Tanzu Framework. Il manifesto predefinito viene reso disponibile quando si crea un cluster di gestione o si installa la CLI di Tanzu oppure è possibile estrarlo dal repository di immagini TKG. Per informazioni, vedere Creazione di una ClusterClass personalizzata.
  • Quando si distribuisce un cluster del carico di lavoro con una versione della patch di Kubernetes precedente all'ultima patch supportata per la sua versione secondaria, è necessario creare un oggetto ConfigMap per il relativo TKr prima di distribuire il cluster. Vedere Distribuzione del cluster Kubernetes nella pagina Più versioni di Kubernetes.

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

Avvisi di deprecazione

Il comando tanzu login verrà rimosso nelle versioni future di TKG. Verrà sostituito dal comando tanzu context. Per ulteriori informazioni, vedere tanzu context in Documentazione della CLI di VMware Tanzu.

Documentazione per l'utente

Distribuzione e gestione di cluster di gestione autonomi TKG 2.3 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.3.1

Tanzu Kubernetes Grid v2.3.1 risolve problemi e bug dei clienti privi di documenti.

Risolti in v2.3.0

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

  • La rete IPv6 non è supportata in vSphere 8

    TKG v2.3 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.

  • La scalabilità automatica del cluster non aggiunge le chiavi previste a MachineDeployment

    Se si crea un cluster con scalabilità automatica del cluster abilitata, le chiavi previste cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size e cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size non vengono aggiunte a metadata.annotations nella MachineDeployment.

  • La variabile di implementazione del nodo di lavoro non è presente nelle configurazioni ClusterClass

    La variabile WORKER_ROLLOUT_STRATEGY utilizzata per impostare la strategia di implementazione per i cluster del carico di lavoro MachineDeployments non è presente nelle configurazioni ClusterClass per tutti i provider di infrastrutture. Ora è possibile impostare la variabile WORKER_ROLLOUT_STRATEGY nei cluster basati sulla classe, nonché nei cluster legacy basati sul piano. Per ulteriori informazioni, vedere Cluster abilitati per GPU in Informazioni di riferimento sulle variabili del file di configurazione.

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

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

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

    In Harbor v2.7.1, che era 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.

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

  • 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 e devono essere aggiunte manualmente.

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

Problemi noti

Di seguito sono elencati i problemi noti di Tanzu Kubernetes Grid v2.3.x. Tutti i problemi noti presenti nella v2.3.0 che sono stati risolti in una versione patch v2.3.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

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

  • In AWS e Azure, la creazione di un cluster del carico di lavoro con le specifiche dell'oggetto non riesce e si verifica un errore zona/regione

    Per impostazione predefinita, in AWS o Azure, l'esecuzione di tanzu cluster create con le specifiche dell'oggetto cluster basato sulla classe passata a --file causa l'esecuzione della verifica di regione e zona da parte della CLI di Tanzu, pertinente solo alle zone di disponibilità di vSphere.

    Soluzione Quando si crea un cluster basato sulla classe in AWS o Azure, eseguire una delle operazioni seguenti, in base al processo a un passaggio o a due passaggi descritti in Creare un cluster basato sulla classe:

    • A un passaggio: eseguire il processo a un passaggio così come descritto, impostando features.cluster.auto-apply-generated-clusterclass-based-configuration su true e non passando --dry-run al comando tanzu cluster create.

    • A due passaggi: prima di eseguire tanzu cluster create con le specifiche dell'oggetto come secondo passaggio, impostare SKIP_MULTI_AZ_VERIFY su true nell'ambiente locale:

      export SKIP_MULTI_AZ_VERIFY=true

  • I componenti non sono pianificati quando si utilizzano cluster con capacità limitata

    Per i cluster di gestione e i cluster del carico di lavoro, se si distribuiscono cluster con un singolo nodo del piano di controllo, un singolo nodo di lavoro o cluster di piccole o medie dimensioni, è possibile che si verifichi un conflitto di pianificazione delle risorse.

    Soluzione: Utilizzare cluster a nodo singolo o cluster con un totale di tre o più nodi.

  • 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.26.8, 1.25.13, or 1.24.17. Il progetto Kubernetes consiglia di eseguire componenti nella versione patch più recente di una versione secondaria corrente.

  • 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 scalare il numero dei nodi del piano di controllo impostandolo su un numero pari.

Rete

Nota

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

  • Alcune variabili di configurazione NSX ALB non funzionano

    In TKG v2.3, le variabili di configurazione del cluster di gestione AVI_DISABLE_INGRESS_CLASS, AVI_DISABLE_STATIC_ROUTE_SYNC e AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER non funzionano.

    Per impostare una qualsiasi delle proprietà sottostanti sul valore non predefinito true, è necessario creare il cluster di gestione e modificare manualmente i suoi due oggetti di configurazione AKODeploymentConfig come descritto di seguito.

    Soluzione: modificare gli oggetti install-ako-for-all e install-ako-for-management-cluster nel cluster di gestione:

    1. Impostare il contesto di kubectl sul cluster di gestione:

      kubectl config use-context MGMT-CLUSTER-CONTEXT

    2. Modificare le configurazioni install-ako-for-all e install-ako-for-management-cluster:

      kubectl edit adc install-ako-for-all

      kubectl edit adc install-ako-for-management-cluster

    3. Nelle configurazioni, impostare le proprietà seguenti come desiderato:

      • extraConfigs.ingress.disableIngressClass - per la variabile di configurazione AVI_DISABLE_INGRESS_CLASS
      • extraConfigs.disableStaticRouteSync - per la variabile di configurazione AVI_DISABLE_STATIC_ROUTE_SYNC
      • extraConfigs.ingress.defaultIngressController - per la variabile di configurazione AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER

    4. Salvare e uscire.

    Queste impostazioni verranno applicate ai cluster del carico di lavoro creati successivamente dal cluster di gestione.

  • La modalità di ingresso NodePortLocal di NSX ALB non è supportata per il cluster di gestione

    In TKG v2.3, 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.

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.

vSphere

  • La distribuzione del cluster di gestione in vSphere 7 non riesce durante l'attesa della disponibilità del piano di controllo del cluster

    Se si specifica la rete della macchina virtuale quando si distribuisce un cluster di gestione in vSphere 7, la distribuzione non riesce e viene visualizzato l'errore unable to set up management cluster: unable to wait for cluster control plane available: control plane is not available yet.

    Soluzione: La rete "Rete della macchina virtuale" ha quindi più subnet configurate con IP statici per VsVip e ServiceEngine. Impostare exclude_discovered_subnets su True nella rete della macchina virtuale per ignorare le subnet rilevate e consentire l'inserimento dei servizi virtuali nei motori di servizio.

  • Le zone di disponibilità possono essere eliminate quando a esse sono assegnate le macchine virtuali

    Se si elimina una zona di disponibilità che contiene macchine virtuali, le macchine virtuali non possono essere successivamente eliminate.

    Soluzione: Rimuovere tutte le macchine virtuali da una zona di disponibilità prima di eliminarla.

  • La creazione di cluster del carico di lavoro non riesce a causa dell'esaurimento della sessione VPXD

    Quando si creano cluster del carico di lavoro in vSphere, la creazione non riesce e viene visualizzato il seguente errore:

    vSphere config validation failed: failed to get VC client: failed to create vc client: Post "https://address/sdk": EOF ". VCenter vpxd.log report error: Out of HTTP sessions: Limited to 2000

    Questo problema si verifica a causa dell'esaurimento della sessione del vCenter Server.

    Soluzione: Vedere l'articolo della Knowledge Base di VMware 50114010.

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

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.

Repository Tanzu Standard v2023.7.13

Con TKG v2.3, la versione del repository dei pacchetti Tanzu Standard viene definita e distribuita separatamente da TKG e il controllo delle versioni è basato su un’indicazione di data.

Per TKG v2.3.0 e v2.3.1, la versione patch di TKG e la versione compatibile più recente del Repository Tanzu Standard vengono rilasciate nella stessa data.

Le versioni future del repository Tanzu Standard potrebbero essere pubblicate più frequentemente rispetto alle versioni di TKG, ma tutte le versioni patch manterranno le compatibilità esistenti tra le versioni secondarie di TKG e Tanzu Standard.

Per ogni versione della patch di TKG v2.3, la versione compatibile più recente del Repository Tanzu Standard è:

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.
  • VMware offre supporto a livello di runtime per i pacchetti supportati da VMware Harbor, Contour e Velero quando vengono distribuiti in Tanzu Kubernetes Grid.

Cert-manager v1.11.1

Novità

Versioni supportate
Versione di TKG Versione jetstack_cert-manager Versione del pacchetto vMware cert-manager Compatibilità delle versioni Kubernetes
2.3 v1.11.1 v1.11.1+vmware.1 1.21-1.27

Versioni dei componenti

cert manager v1.11.1 contiene le seguenti versioni dell'immagine del componente:

  • quay.io/jetstack/cert-manager-cainjector:v1.11.1
  • quay.io/jetstack/cert-manager-controller:v1.11.1
  • quay.io/jetstack/cert-manager-webhook:v1.11.1
  • quay.io/jetstack/cert-manager-acmesolver:v1.11.1

Deprecazioni

Le seguenti versioni di Cert Manager sono obsolete in TKG v2.3:

  • v1.5.3
  • v1.7.2
  • v1.10.2

Contour v1.24.4

Novità

  • Vedere le note di rilascio di Contour v1.24.0-4:
  • È possibile configurare Envoy per l'installazione come distribuzione con un numero specificato di repliche anziché come DaemonSet (impostazione predefinita), utilizzando valori di dati come i seguenti:
    envoy: 
  workload: 
    type: Deployment 
    replicas: 3

  • È possibile specificare richieste o limiti di risorse per ogni container all'interno dei carichi di lavoro Contour ed Envoy utilizzando valori di dati come i seguenti:

    contour: 
  resources: 
    contour: 
      requests: 
        cpu: 250m 
        memory: 128Mi 
      limits: 
        cpu: 1 

        memory: 512Mi
envoy:
  resources:
    envoy:
# include requests and limits as desired
    shutdown-manager:
# include requests and limits as desired
  • Vengono verificati i valori di configurazione del file data-values. Se si specifica un valore non supportato nei valori dei dati, viene generato un errore.

Versioni di Kubernetes supportate

Contour v1.24.4 è supportato in Kubernetes v1.24-v1.26. Vedere Matrice di compatibilità di Contour.

Deprecazioni

  • Tutte le versioni di Contour precedenti alla v1.24.4 sono state rimosse dal repository Tanzu Standard v2023.7.13.
  • I file data-values del pacchetto Contour non accettano più i valori null. Per qualsiasi campo di configurazione con un valore impostato su null, è necessario omettere completamente il valore.

External-csi-snapshot-webhook v6.1.0

Novità

  • external-csi-snapshot-webhook è un nuovo pacchetto per TKG v2.3
  • TKG v2.3 con un supervisore vSphere 8.0U2 supporta gli snapshot CSI per il supervisore e i cluster del carico di lavoro che distribuisce, ma è innanzitutto necessario installare esplicitamente external-csi-snapshot-webhook v6.1.0 utilizzando la CLI di Tanzu.

Versioni supportate
Versione di TKG Versione external-csi-snapshot-webhook Compatibilità prevista della versione di Kubernetes Testato nella versione di Kubernetes
2.3.0 6.1.0 1.18 - più recente 1.24

Dipendenze

  • external-csi-snapshot-webhook richiede cert-manager per la comunicazione sicura X509 con il server dell'API Kubernetes.

Versioni dei componenti

external-csi-snapshot-webhook contiene la seguente versione dell'immagine del componente:

  • registry.k8s.io/sig-storage/snapshot-validation-webhook:v6.1.0

DNS esterno v0.13.4

Novità

  • Vedere le note di rilascio del DNS esterno v0.13.4
  • Nuovo campo di configurazione createNamespace. Impostare su true per creare lo spazio dei nomi in cui sono installati i componenti external-dns. Se impostato su false, i componenti del pacchetto vengono installati in uno spazio dei nomi esistente.

Fluent-bit v2.1.2

Novità

Limiti/Problemi noti

  • Non supporta le variabili di ambiente delle credenziali AWS nel pacchetto ConfigMap di fluent-bit per l'accesso ad AWS S3.
    • È previsto il supporto delle credenziali AWS in una versione futura.

Controller Fluxcd

Novità

Vedere le seguenti note di rilascio del pacchetto del controller Fluxcd:

Grafana v9.5.1

Novità

Versioni dei componenti

Grafana v9.5.1 contiene le seguenti versioni dell'immagine del componente:

  • grafana/grafana:9.5.1
  • kiwigrid/k8s-sidecar:1.22.0

Harbor v2.8.2

Novità

  • Vedere le note di rilascio di Harbor v2.8.2
  • A causa delle CVE, la compatibilità di TKG v2.3 con le seguenti versioni di Harbor è stata rimossa:
    • v2.2.3_vmware.1-tkg.1
    • v2.2.3_vmware.1-tkg.2
    • v2.3.3_vmware.1-tkg.1
    • v2.5.3_vmware.1-tkg.1
    • v2.7.1_vmware.1-tkg.1

Versioni dei componenti

Harbor v2.8.2 contiene le seguenti versioni delle immagine dei componenti:

  • harbor-core:v2.8.2
  • harbor-db:v2.8.2
  • harbor-exporter:v2.8.2
  • harbor-jobservice:v2.8.2
  • harbor-portal:v2.8.2
  • harbor-registryctl:v2.8.2
  • registry-photon:v2.8.2
  • photon server notary:v2.8.2
  • firmatario notary-photon:v2.8.2
  • redis-photon:v2.8.2
  • trivy-adapter-photon:v2.8.2

Multus-CNI v4.0.1

Novità

  • Include una distribuzione e un'architettura thick-plugin. Vedere Nuova funzionalità di Multus-CNI v4.0.1

  • Modificare i valori predefiniti come segue:

    namespace: kube-system 
#! DaemonSet related configuration 
daemonset: 
  resources: 
    limits: 
      cpu: 100m 
      memory: 50Mi 
    requests: 
      cpu: 100m 
      memory: 50Mi 
configmap: 
  cniVersion: 0.3.1 
  multusConfigFile: auto

Prometheus v2.43.0

Novità

Versioni dei componenti

Prometheus v2.43.0 contiene le seguenti versioni delle immagini dei componenti:

  • prom/prometheus:v2.43.0
  • prom/alertmanager:v0.25.0
  • prom/pushgateway:v1.5.1
  • jimmidyson/configmap-reload:v0.8.0
  • bitnami/kube-state-metrics:2.8.2
  • quay.io/prometheus/node-exporter:v1.5.0

Velero v1.10.0

Novità

  • Vedere le note di rilascio di Velero v1.10.0
  • Kopia sostituisce Restic come programma di caricamento. Ciò comporta le seguenti modifiche importanti. Per informazioni dettagliate, vedere Modifiche importanti nel registro delle modifiche di Velero v1.10:
    • restic daemonset rinominato in node-agent
    • CR ResticRepository rinominato in BackupRepository
    • Comando velero restic repo rinominato in velero repo
    • Segreto velero-restic-credentials rinominato in velero-repo-credentials
    • Parametro default-volumes-to-restic rinominato in default-volumes-to-fs-backup
    • Parametro restic-timeout rinominato in fs-backup-timeout
    • Parametro default-restic-prune-frequency rinominato in default-repo-maintain-frequency
  • Unifica il repository di backup e lo separa dagli spostamenti dei dati come descritto in Progettazione del repository unificato e integrazione di Kopia.
  • Esegue il refactoring del backup del file system aggiungendo un percorso Kopia insieme al percorso Restic esistente, che supporta entrambi tramite un parametro di configurazione uploader-type.
  • Sposta i plug-in BackupItemAction, RestoreItemAction e VolumeSnapshotterAction alla versione v1 per consentire modifiche future del plug-in che potrebbero non supportare la compatibilità con le versioni precedenti, ad esempio in come attività complesse di spostamento dei dati. Vedere Controllo delle versioni del plug-in.
  • Aggiunge opzioni per salvare le credenziali per posizioni di snapshot di volume specifiche; vedere Posizioni di storage di backup e posizioni degli snapshot dei volumi.
  • Migliora l’affidabilità dello snapshot CSI con codici di protezione per la gestione degli errori e la possibilità di ignorare i controlli di esclusione in modo che lo snapshot CSI funzioni con vari filtri delle risorse di backup.
  • Supporta la pausa/sospensione della pausa della pianificazione del backup:
    • Passare il flag -paused a velero schedule create per creare una pianificazione in pausa.
    • velero schedule pause e velero schedule unpause mette in pausa e sospende la pausa di una pianificazione esistente.

Versioni supportate
Versione di TKG Versione di Velero Compatibilità prevista della versione di Kubernetes Testato nella versione di Kubernetes
2.3 (Halifax) 1.10 1.18-più recente 1.22.5, 1.23.8, 1.24.6 e 1.25.1

Versioni dei componenti

Velero v1.10.3 contiene le seguenti versioni dell'immagine del componente:

  • velero/velero:v1.10.3
  • velero/velero-plugin-for-aws:v1.6.2
  • velero/velero-plugin-for-csi:v0.4.3
  • velero/velero-plugin-for-microsoft-azure:v1.6.2
  • vsphereveleroplugin/velero-plugin-for-vsphere:v1.5.1

Per correggere le CVE, le versioni di runtime di Velero e delle dipendenze vengono aggiornate come segue:

  • Go runtime v1.18.8
  • Restic v0.13.1 compilato con Go 1.18.8 anziché creare pacchetti per il file binario ufficiale di Restic
  • Versioni aggiornate delle librerie dipendenti principali

Aggiornamenti

Le procedure di aggiornamento precedenti non funzionano a causa delle modifiche del backup del file system. Per i nuovi passaggi di aggiornamento, vedere Aggiornamento a Velero 1.10.

Limiti/Problemi noti

Whereabouts v0.6.1

Novità

check-circle-line exclamation-circle-line close-line
Scroll to top icon