Notas de la versión de VMware Tanzu Kubernetes Grid v2.2

Excepto donde se indique, estas notas de la versión se aplican a todas las versiones de revisión v2.2.x de Tanzu Kubernetes Grid (TKG).

TKG v2.2 se distribuye como un paquete de CLI de Tanzu descargable que implementa un clúster de administración independiente de TKG con versión. TKG v2.2 admite la creación y la administración de clústeres de carga de trabajo con un clúster de administración independiente que se puede ejecutar en varias infraestructuras, incluidas vSphere 6.7, 7 y 8, AWS y Azure.

Tanzu Kubernetes Grid v2.0, v2.2 y vSphere with Tanzu Supervisor en vSphere 8

Importante
El supervisor de vSphere with Tanzu en vSphere 8.0.1c y versiones posteriores ejecuta TKG v2.2. Las versiones anteriores de vSphere 8 ejecutan TKG v2.0, que no se publicó independientemente del supervisor. Los clústeres de administración independientes que ejecutan TKG 2.x están disponibles a partir de TKG 2.1. Las versiones posteriores de TKG se integrarán en Supervisor en futuras versiones de actualización de vSphere. En consecuencia, es posible que la versión de TKG integrada en la versión de vSphere with Tanzu más reciente en un momento determinado no sea la misma que la versión independiente de TKG que utiliza. Sin embargo, las versiones de la CLI de Tanzu que son compatibles con todas las versiones de TKG v2.x son totalmente compatibles con Supervisor en todas las versiones de vSphere 8.

Tanzu Kubernetes Grid v2.2 y vSphere with Tanzu en vSphere 7

Precaución
Las versiones de CLI de Tanzu que son compatibles con TKG 2.x y con el supervisor vSphere with Tanzu en vSphere 8 no son compatibles con el clúster supervisor en vSphere 7. Para utilizar la CLI de Tanzu con un clúster supervisor vSphere with Tanzu en vSphere 7, utilice la versión CLI de Tanzu de TKG v1.6. Para utilizar las versiones de la CLI de Tanzu que son compatibles con TKG 2.x con Supervisor, actualice a vSphere 8. Puede implementar un clúster de administración de TKG 2.x independiente en vSphere 7 si no hay un clúster supervisor vSphere with Tanzu. Para obtener información sobre la compatibilidad entre los productos de CLI de Tanzu y VMware, consulte la documentación de CLI de Tanzu.

Novedades

Tanzu Kubernetes Grid v2.2.x incluye las siguientes funciones nuevas:

Compatibilidad con Kubernetes v1.25.7, 1.24.11 y 1.23.17. Consulte Versiones de Kubernetes compatibles con Tanzu Kubernetes Grid v2.2 a continuación.
Para los clústeres de administración independientes y los clústeres de carga de trabajo basados en clases, puede configurar la confianza para varios registros de imágenes privadas mediante variables ADDITIONAL_IMAGE_REGISTRY* en un archivo de configuración de clúster o la configuración de additionalImageRegistries en una especificación del objeto del Cluster. Consulte Registros de confianza para un clúster basado en clases.
Elimina la notificación de volumen persistente jobservice.scandataExports de Harbor v2.7.1. Si aplicó previamente la Superposición de Harbor Scandata Volume EmptyDir al paquete de Harbor, consulte Actualizar una implementación de Harbor en ejecución antes de actualizar el paquete de Harbor a la versión 2.7.1.
A partir de TKG 2.2.0, VMware ofrece soporte de nivel de tiempo de ejecución para paquetes compatibles con VMware, como Harbor, Contour y Velero, cuando se implementan en Tanzu Kubernetes Grid.
El paquete CSI de vSphere admite la configuración de vsphereCSI.netpermissions.

Versiones de Kubernetes y TKG compatibles

Con TKG v2.2, la directiva de compatibilidad de VMware cambia en versiones de revisión anteriores de TKG y TKr, que empaquetan versiones de Kubernetes para TKG. Las directivas de compatibilidad para TKG v2.1 y versiones secundarias anteriores de TKG no cambian.

En las siguientes secciones, se resume la compatibilidad con todas las versiones compatibles actualmente de TKG y TKr en las directivas de compatibilidad que se aplican a cada una.

Versiones de Kubernetes compatibles:

Cada versión de Tanzu Kubernetes Grid agrega compatibilidad con la versión de Kubernetes de su clúster de administración, además de versiones adicionales de Kubernetes, distribuidas como versiones Tanzu Kubernetes (TKr), excepto donde se indique como un Problema conocido.

Versiones secundarias: VMware admite TKG v2.2 con Kubernetes v1.25, v1.24 y v1.23 en el momento del lanzamiento y durante el tiempo que también se admite TKG v2.1. Una vez que TKG v2.1 alcance su hito de fin de soporte general, VMware dejará de admitir Kubernetes v1.23 y v1.24 con TKG.

Versiones de revisión: Después de que VMware publique una nueva versión de revisión de TKr para una línea secundaria, conserva la compatibilidad con versiones de revisión anteriores durante dos meses. Esto proporciona a los clientes un plazo de 2 meses para actualizar a nuevas versiones de revisión de TKr. A partir de TKG v2.2, VMware no admite todas las versiones de revisión de TKr de líneas secundarias anteriores de Kubernetes.

Versiones de TKG y TKr compatibles

Las versiones de revisión de TKG compatibles actualmente admiten versiones de revisión de TKr, como se indica a continuación.

Versión de Tanzu Kubernetes Grid	Versión de Kubernetes del clúster de administración	Versiones de Kubernetes (TKr) proporcionadas
2.2.0	1.25.7	1.25.7, 1.24.11, 1.23.17
2.1.1	1.24.10	1.24.10, 1.23.16, 1.22.17
2.1.0	1.24.9	1.24.9, 1.23.15, 1.22.17
1.6.1	1.23.10	1.23.10, 1.22.13, 1.21.14
1.6.0	1.23.8	1.23.8, 1.22.11, 1.21.14

Versiones de TKr compatibles con TKG v2.2.0

TKG v2.2.0 admite versiones de revisión de TKr como se indica en la siguiente tabla, en función de las siguientes fechas de versión:

v2.2.0: 18 de mayo de 2023
v2.1.1: 21 de marzo de 2023

Kubernetes secundario	Revisión de Kubernetes	Publicado con TKG	Fecha de finalización de soporte (si no es la más reciente)
v1.25	v1.25.7	v2.2.0	Última versión compatible
v1.24	v1.24.11	v2.2.0	Última versión compatible
	v1.24.10	v2.1.1	11 de julio de 2023
	v1.24.9	v2.1.0	21 de mayo de 2023
v1.23	v1.23.17	v2.2.0	Última versión compatible
	v1.23.16	v2.1.1	11 de julio de 2023
	v1.23.15	v2.1.0	21 de mayo de 2023

Versiones de Tanzu Kubernetes Grid compatibles

VMware admite las versiones de TKG de la siguiente manera:

Versiones secundarias: VMware admite TKG siguiendo la directiva del ciclo de vida de N-2, que se aplica a las dos versiones secundarias más recientes y anteriores de TKG. Con la versión de TKG v2.2.0, ya no se admite TKG v1.5. Consulte la Matriz del ciclo de vida del producto de VMware para obtener más información.

Versiones de revisión: VMware no admite todas las versiones anteriores de revisiones de TKG. Después de que VMware publique una nueva versión de revisión de TKG, conserva la compatibilidad con la versión de revisión anterior durante dos meses. Esto proporciona a los clientes un período de 2 meses para actualizar a nuevas versiones de revisión de TKG.

Por ejemplo, la compatibilidad con TKG v2.2.0 finalizaría dos meses después de la disponibilidad general de TKG v2.2.1.

Aclaración de compatibilidad del paquete de repositorio estándar de Tanzu

VMware proporciona la siguiente compatibilidad con los paquetes opcionales que se proporcionan en el repositorio de VMware Tanzu Standard:

VMware proporciona validación de instalación y actualización para los paquetes que se incluyen en el repositorio de VMware Tanzu Standard opcional cuando se implementan en Tanzu Kubernetes Grid. Esta validación se limita a la instalación y actualización del paquete, pero incluye las actualizaciones disponibles necesarias para abordar las CVE. Las correcciones de errores, mejoras de funciones y correcciones de seguridad se proporcionan en nuevas versiones de paquete cuando están disponibles en el proyecto de paquete ascendente.
VMware no proporciona compatibilidad con el nivel de tiempo de ejecución para los componentes proporcionados por el repositorio de Tanzu Standard. La depuración de la configuración, los problemas relacionados con el rendimiento o la depuración y la corrección del propio paquete no se proporcionan mediante VMware.

Para obtener más información sobre la compatibilidad con VMware para paquetes de Tanzu Standard, consulte Novedades anteriormente y Avisos de cambio de comportamiento futuros a continuación.

Instantánea del producto para Tanzu Kubernetes Grid v2.2

Tanzu Kubernetes Grid v2.2 admite las siguientes plataformas de infraestructura y sistemas operativos (SO), así como con los componentes de creación y administración de clústeres, redes, almacenamiento, autenticación, copia de seguridad y migración y observación. Las versiones de componentes enumeradas entre paréntesis se incluyen en Tanzu Kubernetes Grid v2.2.0. Para obtener más información, consulte Versiones de los componentes.

	vSphere	AWS	Azure
Plataforma de la infraestructura	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
Infraestructura de CLI, API y de paquetes	Tanzu Framework v0.29.0
Creación y administración de clústeres	API de clúster principal (v1.2.8), proveedor de la API del clúster vSphere (v1.5.3)	API de clúster principal (v1.2.8), proveedor de la API del clúster AWS (v2.0.2)	API de clúster principal (v1.2.8), proveedor de la API del clúster Azure (v1.6.3)
Sistema operativo del nodo de Kubernetes distribuido con TKG	Photon OS 3, Ubuntu 20.04	Amazon Linux 2, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
Cree su propia imagen	Photon OS 3, Red Hat Enterprise Linux 7*** y 8, Ubuntu 18.04, Ubuntu 20.04, Windows 2019	Amazon Linux 2, Ubuntu 18.04 y Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
Tiempo de ejecución del contenedor	Containerd (v1.6.18)
Redes de contenedores	Antrea (v1.9.0), Calico (v3.24.1)
Registro de contenedores	Harbor (v2.7.1)
Entrada	Controlador NSX Advanced Load Balancer Essentials y Avi **** (v21.1.5-v21.1.6, v22.1.2-v22.1.3), Contour (v1.23.5)	Contour (v1.23.5)	Contour (v1.23.5)
Almacenamiento	Interfaz de almacenamiento del contenedor de vSphere (v2.7.1*) y almacenamiento nativo en la nube de vSphere	Controlador CSI de Amazon EBS (v1.16.0) y proveedores de nube en el árbol	Controlador CSI de discos de Azure (v1.27.0), controlador CSI de archivos de Azure (v1.26.1) y proveedores de nube en el árbol
Autenticación	OIDC a través de Pinniped (v0.12.1), LDAP a través de Pinniped (v0.12.1) y Dex
Observabilidad	Fluent Bit (v1.9.5), Prometheus (v2.37.0)*****, Grafana (v7.5.17)
Copia de seguridad y migración	Velero (v1.9.7)

* Versión de vsphere_csi_driver. Para obtener una lista completa de los componentes de la interfaz de almacenamiento del contenedor de vSphere incluidos en Tanzu Kubernetes Grid versión 2.2, consulte Versiones de los componentes.

** Para obtener una lista de las versiones de SDDC de VMware Cloud on AWS compatibles con esta versión, consulte Matriz de interoperabilidad de productos de VMware.

Tanzu Kubernetes Grid v1.6 es la última versión que admite la creación de imágenes de Red Hat Enterprise Linux 7.

En vSphere 8, para utilizar NSX Advanced Load Balancer con un clúster de administración independiente de TKG y sus clústeres de carga de trabajo, necesita NSX ALB v22.1.2 o una versión posterior y TKG v2.1.1 o una versión posterior.

***** Si actualiza un clúster a Kubernetes v1.25, debe actualizar Prometheus a la versión2.37.0+vmware.3-tkg.1. Las versiones anteriores del paquete de Prometheus, por ejemplo, la versión 2.37.0+vmware.1-tkg.1, no son compatibles con Kubernetes 1.25.

Para obtener una lista completa de las versiones de Kubernetes que se incluyen en Tanzu Kubernetes Grid v2.2, consulte la sección anterior Versiones de Kubernetes compatibles en Tanzu Kubernetes Grid v2.2.

Versiones de los componentes

Las versiones Tanzu Kubernetes Grid v2.2.x incluyen las siguientes versiones de los componentes de software:

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

^* Indica un nuevo componente o un nuevo bump de versiones desde la versión anterior. TKG v2.1.1 es anterior a la versión 2.2.0.

Para obtener una lista completa de versiones de componentes de software que se incluyen en TKG v2.2 utilice imgpkg para extraer el paquete de repositorios y, a continuación, enumerar su contenido. Para TKG v2.2.0, por ejemplo:

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

Los archivos de lista de materiales locales, como los siguientes, también muestran las versiones del paquete, pero pueden no estar actualizados:

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

Rutas de actualización compatibles

En la ruta de acceso de actualización de TKG, v2.2 sigue inmediatamente a v2.1.1.

Solo puede actualizar a Tanzu Kubernetes Grid v2.2.x desde v2.1.x. Si desea actualizar a Tanzu Kubernetes Grid v2.2.x desde una versión anterior a v2.1.x, primero debe actualizar a v2.1.x.

Al actualizar versiones de Kubernetes en clústeres de carga de trabajo, no se pueden omitir versiones secundarias. Por ejemplo, no puede actualizar un clúster de Tanzu Kubernetes directamente de v1.23.x a v1.25.x. Debe actualizar un clúster de la v1.23.x a la v1.24.x antes de actualizar el clúster a la v1.25.x.

Fechas de versión

Las fechas de versión de Tanzu Kubernetes Grid v2.2 son:

v2.2.0: 9 de mayo de 2023

Cambios de comportamiento en Tanzu Kubernetes Grid v2.2

Tanzu Kubernetes Grid v2.2 no introduce comportamientos nuevos en comparación con la versión 2.1.1, que es la versión anterior más reciente.

Avisos de cambio de comportamiento futuros

En esta sección se proporciona un aviso previo de los cambios de comportamiento que se aplicarán en futuras versiones, después de la versión 2.2 de TKG.

Repositorio de VMware Tanzu Standard

Importante
Tanzu Kubernetes Grid v2.2.x es la última versión secundaria de TKG en la que el repositorio de VMware Tanzu Standard se empaqueta como parte de la versión. TKG v2.2.x y las versiones anteriores incluyen un conjunto de paquetes opcionales en el repositorio estándar de Tanzu, que se pueden implementar en clústeres para agregar funcionalidades como el reenvío de registros, el control de entrada, un registro de contenedor, etc. En una versión secundaria futura de TKG v2.x, el repositorio estándar de Tanzu no se descargará automáticamente cuando instale CLI de Tanzu e implemente un clúster de administración. Para utilizar este conjunto opcional de paquetes, utilizará CLI de Tanzu para descargarlos y agregarlos manualmente. Si se separan los paquetes opcionales de las versiones de TKG, las versiones de VMware proporcionarán actualizaciones de paquetes incrementales fuera de las versiones de TKG y ofrecerán una mayor capacidad de respuesta a las CVE.

Avisos de desuso

En una futura versión de TKG, se eliminará el componente Dex, ya que ya no es necesario para que Pinniped funcione con los proveedores de LDAP. Con este cambio, las siguientes variables de configuración del clúster para la autenticación LDAP serán necesarias: LDAP_BIND_DN y LDAP_BIND_PASSWORD. Para obtener más información, consulte Proveedores de identidad: LDAP en Referencia de variables de archivo de configuración.

Documentación del usuario

Implementar y administrar clústeres de administración independientes de TKG 2.2 incluye temas específicos de los clústeres de administración independientes que no son pertinentes para usar TKG con un supervisor de vSphere with Tanzu.

Para obtener más información, consulte Buscar los documentos de TKG adecuados para la implementación en la página Documentación de VMware Tanzu Kubernetes Grid.

Problemas resueltos

Los siguientes problemas documentados como Problemas conocidos en versiones de Tanzu Kubernetes Grid anteriores se han resuelto en Tanzu Kubernetes Grid v2.2.0.

Al crear un archivo de configuración ClusterClass a partir de un archivo de configuración heredado y --dry-run se incluye una configuración de Antrea vacía

Al crear un archivo de configuración ClusterClass mediante tanzu cluster create --dry-run -f con un archivo de configuración heredado que incluye una entrada de ANTREA_NODEPORTLOCAL, se produce una configuración de Antrea autogenerada que no incluye ninguna etiqueta, lo que hace que Antrea no se concilie correctamente.
Los paquetes no cumplen con el perfil de PSA de línea base predeterminado

Con los controladores PSA en TKG, en un estado de vista previa técnica no compatible, algunos paquetes de TKG no cumplen con el perfil baseline predeterminado.
Error de validación cuando se ejecuta tanzu cluster create

De forma predeterminada, cuando se pasa un archivo de configuración de clave-valor plano a la opción --file de tanzu cluster create, el comando convierte el archivo de configuración en un archivo de especificación de objeto de estilo Kubernetes y, a continuación, sale. Este comportamiento se controla mediante la función auto-apply-generated-clusterclass-based-configuration, que está establecida en false de forma predeterminada. En algunos casos, cuando se pasa el archivo de especificación de objeto de estilo Kubernetes generado por la opción --file a tanzu cluster create, se produce un error en el comando similar al siguiente:
```
Error: workload cluster configuration validation failed...
```
Este error también puede producirse al pasar un archivo de especificación de objeto de estilo Kubernetes generado por la opción --dry-run a tanzu cluster create.
tanzu cluster create no valida correctamente las especificaciones de clúster generadas con versiones de Kubernetes no predeterminadas

Cuando se crea un clúster de carga de trabajo basado en clases a partir de un archivo de configuración mediante uno de los procesos de dos pasos descritos en Crear un clúster basado en clases y se especifica un valor de --tkr en el primer paso para basar el clúster en una versión no predeterminada de Kubernetes, en el segundo paso se pueden producir errores de validación.

Problemas conocidos

A continuación se muestran los problemas conocidos de Tanzu Kubernetes Grid v2.2.x. Todos los problemas conocidos presentes en la versión 2.2.0 que se hayan resuelto en una versión de revisión posterior a v2.2.x se enumeran en Problemas resueltos para la versión de revisión en la que se resolvieron.

Puede encontrar soluciones adicionales para problemas frecuentes en Solución de problemas del clúster de administración y Solución de problemas del clúster de carga de trabajo, o en los artículos de la base de conocimientos de VMware.

Paquetes
Operaciones del clúster
Redes
Administración de identidades y acceso
Almacenamiento
CLI
vSphere
AWS
Image Builder
AVS

Paquetes

Se produce un error en la instalación de Grafana en vSphere 6.7 con NSX ALB v21.1.4 o anterior

No se puede instalar el paquete de Grafana v7.5.17 en clústeres de carga de trabajo de TKG v2.2 en vSphere v6.7U3 que utilizan NSX ALB v21.1.4 o anterior como servicio de equilibrador de carga.

Solución alternativa: Si los clústeres de carga de trabajo utilizan Grafana y NSX ALB, actualice vSphere a la versión 7.0 o superior y NSX ALB a la versión 21.1.5+ antes de actualizar TKG a la versión 2.2.
Se puede producir un error en la exportación de CVE de Harbor cuando el identificador de ejecución supera los 1 000 000.

Harbor v2.7.1, que es la versión empaquetada para TKG v2.2, tiene un problema desconocido que CVE informa de la exportación con el error "404 page not found" cuando el identificador de incremento automático de clave principal de ejecución crece hasta 1 000 000 o superior.

Este problema de Harbor se resuelve en versiones posteriores de Harbor que están programadas para incluirse en versiones posteriores de TKG.
Vulnerabilidad de Golang en el componente Notary de Harbor

CVE-2021-33194 está presente en Notary. El componente Notary ha quedado obsoleto en Harbor v2.6 y está programado para eliminarse en una versión futura, como se indica en las notas de la versión de Harbor v2.6.0. VMware recomienda utilizar Sigstore Cosign en lugar de Notary para la verificación y la firma del contenedor.
Se produce un error al agregar un repositorio estándar para clústeres de nodo único

La ejecución de tanzu package repository add para agregar el repositorio tanzu-standard a un clúster de nodo único del tipo descrito en Clústeres de nodo único en vSphere (vista previa técnica) puede fallar.

Esto sucede porque los clústeres de nodo único arrancan con cert-manager como complemento principal, lo que entra en conflicto con el paquete cert-manager diferente en el repositorio tanzu-standard.

Solución alternativa: Antes de agregar el repositorio tanzu-standard, aplique las anotaciones del paquete cert-manager como se describe en Instalar cert-manager.

Operaciones del clúster

No se pueden crear nuevos clústeres de carga de trabajo basados en versiones de TKr no actuales con CNI de Antrea

No se puede crear un nuevo clúster de carga de trabajo que utilice CNI de Antrea y ejecute versiones de Kubernetes enviadas con versiones anteriores de TKG, como Kubernetes v1.23.10, que fue la versión predeterminada de Kubernetes en TKG v1.6.1, como se indica en Versiones de Kubernetes compatibles en Tanzu Kubernetes Grid v2.2.

Solución alternativa: Cree un clúster de carga de trabajo que ejecute Kubernetes 1.25.7, 1.24.11 o 1.23.17. El proyecto de Kubernetes recomienda que se ejecuten componentes en la versión de revisión más reciente de cualquier versión secundaria actual.
El escalador automático para clústeres basados en clases requiere anotaciones manuales

Debido a un problema de propagación de etiquetas en la API del clúster, los ajustes AUTOSCALER_MIN_SIZE_* y AUTOSCALER_MAX_SIZE_* en el archivo de configuración del clúster para los clústeres de carga de trabajo basados en clases no se establece en los objetos MachineDeployment del clúster.

Solución alternativa: Después de crear un clúster de carga de trabajo basado en clases con el escalador automático de clúster habilitado, añada manualmente el ajuste de recuento mínimo y máximo de máquinas para cada AZ, como se describe en Añadir manualmente anotaciones de tamaño mínimo y máximo.
No se pueden cambiar las labels del grupo de nodos ni otras propiedades de configuración.

No puede agregar ni cambiar las propiedades labels, az, nodeMachineType ni vSphere de un grupo de nodos existente, como se indica en Propiedades de configuración.

Solución alternativa: Cree un nuevo grupo de nodos en el clúster con las propiedades deseadas, migre las cargas de trabajo al nuevo grupo de nodos y elimine el original.
No se pueden escalar los nodos del plano de control del clúster de administración a un número par

Si ejecuta tanzu cluster scale en un clúster de administración y envía un número par a la opción --controlplane-machine-count, TKG no escala los nodos del plano de control y la CLI no genera un error. Para mantener el cuórum, los recuentos de nodos del plano de control siempre deben ser impares.

Solución alternativa: No escale los recuentos de nodos del plano de control a un número par.
Los nombres de clúster basados en clases tienen un límite de 25 caracteres con NSX ALB como servicio de equilibrador de carga o controlador de entrada

Cuando se utiliza NSX Advanced Load Balancer (ALB) como controlador de entrada o servicio de equilibrador de carga de un clúster basado en clases con un clúster de administración independiente, sus nombres de aplicaciones incluyen el nombre del clúster y load-balancer-and-ingress-service, el nombre interno del paquete AKO. Cuando el nombre combinado supera el límite de 64 caracteres para las aplicaciones del controlador AVI, el comando tanzu cluster create puede generar un error que indica que no se encontró el espacio de nombres avi-system.

Solución alternativa: Limite la longitud del nombre de clúster basado en clases a 25 caracteres o menos cuando utilice NSX ALB como equilibrador de carga o controlador de entrada.

Redes

Nota
Para v4.0+, se cambia el nombre de VMware NSX-T Data Center a "VMware NSX".

No se admiten redes IPv6 en vSphere 8

TKG v2.2 no admite redes IPv6 en vSphere 8, aunque sí admite redes IPv6 de pila única mediante Kube-Vip en vSphere 7, como se describe en Redes IPv6.

Solución alternativa: Si necesita o actualmente utiliza TKG en un entorno IPv6 en vSphere, no instale ni actualice a vSphere 8.
El modo de entrada NodePortLocal de NSX ALB no es compatible con el clúster de administración

En TKG v2.2, no se puede ejecutar NSX Advanced Load Balancer (ALB) como un tipo de servicio con modo de entrada NodePortLocal para el tráfico hacia el clúster de administración.

Este problema no afecta a la compatibilidad con la entrada NodePortLocal a los clústeres de carga de trabajo, como se describe en Entrada L7 en el modo NodePortLocal.

Solución alternativa: Configure los clústeres de administración con AVI_INGRESS_SERVICE_TYPE establecido en NodePort o ClusterIP. El valor predeterminado es NodePort.
Se produce un error en la creación del clúster de administración o el rendimiento es lento con versiones anteriores de NSX-T y máquinas virtuales con Photon 3 o Ubuntu y kernel de Linux 5.8

La implementación de un clúster de administración con la siguiente infraestructura y configuración puede fallar o resultar en un tráfico restringido entre los pods:
- vSphere con cualquiera de las siguientes versiones de NSX-T:
  - NSX-T v3.1.3 con la ruta de datos mejorada habilitada
  - NSX-T v3.1.x anterior a v3.1.3
  - NSX-T v3.0.x anterior a la revisión activa de 3.0.2
  - NSX-T v2.x. Esto incluye Azure VMware Solution (AVS) v2.0, que utiliza NSX-T v2.5
- Imagen base: Photon 3 o Ubuntu con kernel de Linux 5.8
Esta combinación expone un problema de suma de comprobación entre versiones anteriores de NSX-T y CNI de Antrea.

TMC: Si el clúster de administración está registrado en Tanzu Mission Control (TMC), no hay ninguna solución alternativa para este problema. De lo contrario, consulte las soluciones alternativas que aparecen a continuación.

Soluciones alternativas:
- Implemente clústeres de carga de trabajo configurados con ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD establecido en "true". Este ajuste desactiva la descarga de la suma de comprobación UDP de Antrea, lo que evita los problemas conocidos con algunos controladores de red de NIC físicas y de red subyacentes.
- Actualice a la revisión activa de NSX-T v3.0.2, v3.1.3 o versiones posteriores sin la ruta de datos mejorada habilitada
- Utilice una imagen base de Ubuntu con kernel de Linux 5.9 o posterior.

Administración de identidades y acceso

Volver a crear un clúster de administración independiente no restaura la autenticación de Pinniped

Después de volver a crear un clúster de administración independiente como se describe en Copia de seguridad y restauración de la infraestructura del clúster de carga de trabajo y administración (vista previa técnica), los usuarios no pueden iniciar sesión en los clústeres de carga de trabajo a través de la autenticación Pinniped.

Solución alternativa: Después de volver a crear el clúster de administración, vuelva a configurar la administración de identidades como se describe en Habilitar y configurar la administración de identidades en una implementación existente.
Vulnerabilidad de Golang en el componente Pinniped

CVE-2022-41723 está presente en Pinniped v0.12.1. El aprovechamiento de esta vulnerabilidad podría provocar un ataque DDoS del servicio Pinniped. Para reducir la probabilidad de explotación a baja, puede utilizar el filtrado de entrada para permitir el tráfico solo desde direcciones IP conocidas, como un CIDR de VPN corporativo. Esta vulnerabilidad se resolverá en una versión futura de Tanzu Kubernetes Grid.
La generación y el uso de kubeconfig para el clúster de carga de trabajo implementado por supervisor provoca un error de "marca desconocida"

En la CLI de Tanzu v0.25.0 y versiones anteriores, el complemento cluster genera archivos kubeconfig que pueden contener el argumento --concierge-is-cluster-scoped. El complemento pinniped-auth de la CLI de Tanzu v0.29.0 no reconoce este argumento. Esta regresión temporal se solucionó en versiones posteriores.

Debido a que vSphere 8.0 integra el complemento cluster v0.25.0, al conectarse a un clúster implementado por supervisor desde la CLI v0.29.0, la versión de TKG v2.2 puede generar este error:
```
Error: unknown flag: --concierge-is-cluster-scoped
Unable to connect to the server: getting credentials: exec: executable tanzu failed with exit code 1
```
Solución alternativa: En el archivo kubeconfig, elimine la línea de args que establece --concierge-is-cluster-scoped.

Almacenamiento

El clúster de carga de trabajo no puede distribuir el almacenamiento entre varios almacenes de datos

No puede habilitar un clúster de carga de trabajo para distribuir el almacenamiento entre varios almacenes de datos como se describe en Implementar un clúster que usa un clúster de almacén de datos. Si etiqueta varios almacenes de datos en un clúster de almacenes de datos como base para la directiva de almacenamiento de un clúster de carga de trabajo el clúster de carga de trabajo utiliza solo uno de los almacenes de datos.

Solución alternativa: Ninguna

CLI de Tanzu

No se pueden utilizar caracteres no alfanuméricos en las contraseñas de proxy HTTP/HTTPS

Al implementar clústeres de administración con la CLI, los caracteres no alfanuméricos # ` ^ | / ? % ^ { [ ] } \ " < > no se pueden utilizar en las contraseñas. Además, no se puede utilizar ningún carácter no alfanumérico en las contraseñas de proxy HTTP/HTTPS al implementar el clúster de administración con la interfaz de usuario.

Solución alternativa: Puede utilizar caracteres no alfanuméricos que no sean # ` ^ | / ? % ^ { [ ] } \ " < > en las contraseñas al implementar el clúster de administración con la CLI.
La CLI de Tanzu no funciona en máquinas macOS con procesadores ARM

La CLI de Tanzu v0.11.6 no funciona en máquinas macOS con chips ARM (Apple M1), como se identifica en Buscador (Finder) > Acerca de este Mac (About This Mac) > Descripción general (Overview).

Solución alternativa: Utilice una máquina de arranque con un sistema operativo Linux o Windows, o bien una máquina macOS con un procesador Intel.
La CLI de Tanzu enumera tanzu management-cluster osimage

El grupo de comandos management-cluster enumera tanzu management-cluster osimage. Esta función está actualmente en desarrollo y está reservada para su uso en el futuro.

Solución alternativa: No use tanzu management-cluster osimage
La opción --default-values-file-output de los resultados tanzu package available get genera un archivo de plantilla de configuración incompleto para el paquete de Harbor

Al ejecutar tanzu package available get harbor.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATH, se crea un archivo de plantilla de configuración incompleto para el paquete de Harbor. Para obtener un archivo completo, utilice el comando imgpkg pull como se describe en Instalar Harbor para el registro de servicios.

vSphere

Los grupos de nodos creados con nodos small pueden detenerse en Provisioning

Los grupos de nodos creados con el nodo SIZE configurado como small pueden bloquearse en el estado Provisioning y nunca continuar con Running.

Solución alternativa: Configure el grupo de nodos con al menos nodos de tamaño medium.

AWS

El problema de etiquetado de recursos de CAPA provoca un error de conciliación durante la implementación y la actualización del clúster de administración de AWS.

Debido a un problema de etiquetado de recursos en el proveedor de API del clúster AWS (CAPA) ascendente, las implementaciones sin conexión no pueden acceder a la API ResourceTagging, lo que provoca errores de conciliación durante la creación o la actualización del clúster de administración.

Solución alternativa: En un entorno de AWS sin conexión, establezca EXP_EXTERNAL_RESOURCE_GC=false en el entorno local o en el archivo de configuración del clúster de administración antes de ejecutar tanzu mc create o tanzu mc upgrade.
Los grupos de nodos del clúster de carga de trabajo en AWS deben estar en la misma zona de disponibilidad que el clúster de administración independiente.

Al crear un grupo de nodos configurado con un az que sea diferente al lugar donde se encuentra el clúster de administración, es posible que el nuevo grupo de nodos permanezca bloqueado con el estado ScalingUp, tal y como se indica en tanzu cluster node-pool list, y nunca llegue al estado Ready.

Solución alternativa: Cree grupos de nodos únicamente en la misma zona de disponibilidad que el clúster de administración independiente.
Se produce un error al eliminar el clúster en AWS si el clúster utiliza recursos de redes no implementados con Tanzu Kubernetes Grid.

Los comandos tanzu cluster delete y tanzu management-cluster delete pueden dejar de responder con los clústeres que utilizan recursos de redes creados por AWS Cloud Controller Manager independientemente del proceso de implementación de Tanzu Kubernetes Grid. Estos recursos pueden incluir equilibradores de carga y otros servicios de redes, como se indica en El controlador de servicios en la documentación del proveedor de nube de Kubernetes AWS.

Para obtener más información, consulte el problema de la API del clúster Purgar clústeres de carga de trabajo del servicio Type=Loadbalancer en el desmontaje.

Solución alternativa: Utilice kubectl delete para eliminar servicios del tipo LoadBalancer del clúster. O bien, si se produce un error, utilice la consola de AWS para eliminar manualmente cualquier objeto LoadBalancer y SecurityGroup creado para este servicio por el administrador de controladores de nube.

Precaución
No elimine los equilibradores de carga ni los grupos de seguridad administrados por Tanzu, que tienen las etiquetas key: sigs.k8s.io/cluster-api-provider-aws/cluster/CLUSTER-NAME, value: owned.

Azure

Se produce un error en la eliminación del clúster cuando el volumen de almacenamiento utiliza una cuenta con endpoint privado

Con un clúster de carga de trabajo de Azure en un grupo de recursos no administrado, cuando el controlador CSI de Azure crea un volumen persistente (PV) que utiliza una cuenta de almacenamiento con un endpoint privado, crea un recurso privateEndpoint y un recurso vNet que no se eliminan cuando se elimina el PV. Como resultado, al eliminar el clúster, se produce un error como subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use.

Solución alternativa: Antes de eliminar el clúster de Azure, elimine manualmente la interfaz de red del endpoint privado de la cuenta de almacenamiento:
1. Desde un navegador, inicie sesión en Azure Resource Explorer.
2. Haga clic en suscripciones (subscriptions) a la izquierda y expanda la suscripción.
3. En la suscripción, expanda resourceGroups a la izquierda y el grupo de recursos de la implementación de TKG.
4. En el grupo de recursos, expanda proveedores (providers) > Microsoft.Network > networkinterfaces.
5. En networkinterfaces, seleccione el recurso de NIC que no se puede eliminar.
6. Haga clic en el botón Leer/Escribir (Read/Write) en la parte superior y, a continuación, en la pestaña Acciones (PUBLICAR, ELIMINAR) (Actions [POST, DELETE]) justo debajo.
7. Haga clic en Eliminar.
8. Una vez eliminada la NIC, elimine el clúster de Azure.

Windows

No se admiten trabajos Windows en entornos restringidos por Internet

VMware no admite clústeres de carga de trabajo de TKG con nodos de trabajo Windows en entornos con proxy o aislados.

Solución alternativa: Póngase en contacto con su representante de VMware. Algunos usuarios de TKG crearon imágenes personalizadas de Windows y ejecutaron clústeres de carga de trabajo con trabajos Windows en entornos sin conexión, por ejemplo, como se describe en este repositorio no oficial.

Image-Builder

La prueba goss que se puede ignorar falla durante el proceso de creación de imagen

Cuando se ejecuta Kubernetes Image Builder para crear una imagen de máquina personalizada de Linux, las pruebas goss python-netifaces, python-requests y ebtables producen errores. Los resultados del comando informan de los errores. Los errores se pueden ignorar; no impiden que se cree correctamente la imagen.

AVS

La eliminación del volumen de vSphere CSI podría fallar en AVS

En Azure vSphere Solution (AVS), la eliminación de volúmenes persistentes (PV) de vSphere CSI puede producir un error. Para eliminar un PV, se requiere el permiso cns.searchable. La cuenta de administrador predeterminada para AVS, [email protected], no se crea con este permiso. Para obtener más información, consulte Funciones y privilegios de vSphere.

Solución alternativa: Para eliminar un PV de vSphere CSI en AVS, póngase en contacto con el soporte de Azure.