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

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

TKG v2.3 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.3 admite la creación y la administración de clústeres de carga de trabajo basados en clases con un clúster de administración independiente que se puede ejecutar en varias infraestructuras, incluidas vSphere, AWS y Azure.

Tanzu Kubernetes Grid v2.x 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. Debido a la versión anterior de TKG que está integrada en supervisor, algunas de las funciones que están disponibles si se utiliza un clúster de administración TKG 2.3 independiente no están disponibles si se utiliza un supervisor vSphere with Tanzu para crear clústeres de carga de trabajo. 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 tan reciente como la versión independiente más reciente de TKG. 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. Por ejemplo, Tanzu CLI v1.0.0 es totalmente compatible con versiones anteriores de los complementos de TKG 2.2 que proporciona Supervisor.

CLI de Tanzu y vSphere with Tanzu en vSphere 7

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.3 incluye las siguientes funciones nuevas.

Tanzu Kubernetes Grid v2.3.1

Nuevas funciones de Tanzu Kubernetes Grid v2.3.1:

• Admite Kubernetes 1.26.8, 1.25.13 y 1.24.17; consulte Versiones de Kubernetes compatibles
• (vSphere) Al actualizar un clúster de carga de trabajo o de administración independiente, puede especificar una plantilla de OVA de destino mediante la opción --vsphere-vm-template-name, como se describe en Seleccionar una plantilla de OVA a la que actualizar.
• Componentes actualizados; consulte Versiones de componentes
  • La última versión compatible del repositorio Tanzu Standard es la 2023.10.16, que tiene sus propias notas de la versión independientes en la Documentación de paquetes de Tanzu; consulte las Notas de la versión de Tanzu Standard Repository v2023.10.16
• Solución de errores

Tanzu Kubernetes Grid v2.3.0

Nuevas funciones de Tanzu Kubernetes Grid v2.3.0:

• Nuevo mecanismo de distribución para complementos de CLI de Tanzu independientes, incluidos los complementos de CLI de Tanzu independientes para Tanzu Kubernetes Grid. Además, la CLI de Tanzu principal ahora se distribuye de forma independiente de Tanzu Kubernetes Grid. Para obtener instrucciones sobre cómo instalar la CLI de Tanzu para usarla con Tanzu Kubernetes Grid, consulte Instalar la CLI de Tanzu y la CLI de Kubernetes para su uso con clústeres de administración independientes.
• El repositorio de paquetes Tanzu Standard se versiona y distribuye por separado de TKG; consulte Tanzu Standard Repository v2023.7.13, a continuación.
  • La última versión compatible del repositorio Tanzu Standard para TKG v2.3.0 es el repositorio Tanzu Standard v2023.7.13.
• Puede ejecutar clústeres de administración independientes y de carga de trabajo en varias zonas de disponibilidad (Availability Zones, AZ) y cambiar las AZ en las que se ejecutan los nodos.
  • Para obtener información sobre cómo implementar nuevos clústeres de carga de trabajo en varias zonas de disponibilidad y cambiar los clústeres de carga de trabajo y administración existentes para que se ejecuten en varias o diferentes zonas de disponibilidad, consulte Ejecutar clústeres en varias zonas de disponibilidad.
  • Para utilizar la interfaz del instalador para configurar un nuevo clúster de administración independiente para que se ejecute en varias zonas de disponibilidad, consulte Configurar recursos de vSphere.
  • La compatibilidad con varias zonas de disponibilidad se encuentra en el estado de la función Estable.
• Los clústeres de nodo único se pueden actualizar y son compatibles con Telco Cloud Automation (TCA); consulte Clústeres de nodo único en vSphere.
  • El procedimiento de implementación simplificado no requiere agregar TKr tiny al clúster de administración.
  • No puede utilizar Tanzu Mission Control (TMC) para crear y administrar clústeres de nodo único, pero esta capacidad está planificada para una versión futura de TMC.
• Puede configurar un controlador de admisión de seguridad de pods (Pod Security Admission, PSA) en todo el clúster con las nuevas variables del archivo de configuración del clúster POD_SECURITY_STANDARD_* y los ajustes podSecurityStandard de las especificaciones del Cluster como se describe en Controlador de admisión de seguridad de pod.
  • La compatibilidad con PSA se encuentra en el estado de la función Estable.
• (vSphere) Capacidades de administración de direcciones IP en el clúster expandidas; consulte Node IPAM:
  • IPAM para clústeres de administración independientes, además de clústeres de carga de trabajo basados en clases.
  • Compatibilidad con IPv6.
  • Los clústeres de carga de trabajo en diferentes espacios de nombres de administración pueden asignar direcciones IP desde el mismo grupo de direcciones IP global.
  • Los grupos de direcciones IP pueden contener rangos de IP no contiguos.
  • La consulta de grupo de direcciones IP kubectl get inclusterippool da como resultado los recuentos de direcciones FREE y USED.
  • Variables de configuración del clúster, que se describen en Node IPAM en la referencia de variables del archivo de configuración.
  • La estructura del objeto InClusterIPPool difiere de las versiones anteriores de TKG; la actualización del clúster a la versión 2.3 convierte los grupos de direcciones IP en una nueva estructura.
• Los clústeres que utilizan la CNI de Calico realizan la detección de direcciones IP; consulte Calico CNI en Redes de contenedor y pod.
• Los clústeres de carga de trabajo de Edge con almacenamiento aislado pueden utilizar sus propias plantillas de máquina virtual almacenadas localmente; consulte Especificar una plantilla de máquina virtual local.
• La nueva variable del archivo de configuración del clúster VSPHERE_MTU establece el tamaño de la unidad de transmisión máxima (Maximum Transmission Unit, MTU) para los nodos del clúster de carga de trabajo y de administración en vSphere; consulte Configurar MTU de nodo de clúster.
• Puede configurar clústeres para que usen imágenes de máquina alternativas anotando sus especificaciones de objeto y sin crear ni modificar TKr; consulte Usar una imagen de máquina alternativa.
• (vSphere) CONTROL_PLANE_NODE_NAMESERVERS y WORKER_NODE_NAMESERVERS ahora se encuentran en el Estado estable. Puede establecer estas variables para nodos que se ejecutan en Ubuntu o Photon; no se admite Windows. Para ver un ejemplo de caso práctico, consulte Node IPAM.
• Ahora puede actualizar los clústeres que creó a partir de una definición de ClusterClass personalizada en una versión anterior. Para obtener información, consulte Actualizar clústeres personalizados.
• Nuevas marcas para las comprobaciones de estado de las máquinas, --max-unhealthy y --machine-deployment; consulte Administrar comprobaciones de estado de máquinas para clústeres de carga de trabajo.
• La nueva opción tanzu mc credentials update --vsphere-thumbprint permite utilizar la CLI de Tanzu para actualizar la huella digital TLS de vCenter Server en los clústeres de administración y los clústeres de carga de trabajo en vSphere. Consulte Actualizar credenciales de los clústeres.
• Los clústeres basados en planes recién creados no tienen el repositorio de paquetes Tanzu estándar agregado de forma predeterminada.

• El componente Pinniped ya no utiliza Dex para los proveedores de identidad de LDAP, lo que provoca los siguientes cambios de configuración:

  • Nueva variable de configuración: LDAP_GROUP_SEARCH_SKIP_ON_REFRESH
  • Variables de configuración actualizadas:
  • Ahora se requieren LDAP_BIND_DN y LDAP_BIND_PASSWORD.
  • El valor predeterminado de LDAP_GROUP_SEARCH_NAME_ATTRIBUTE es dn.
  • LDAP_USER_SEARCH_FILTER y LDAP_GROUP_SEARCH_FILTER deben establecerse en el formato utilizado por Pinniped.
  • Variables de configuración eliminadas: LDAP_USER_SEARCH_USERNAME, LDAP_USER_SEARCH_EMAIL_ATTRIBUTE y LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE.

  La eliminación de Dex significa que debe cambiar la configuración LDAP de un clúster de administración antes de actualizarlo a TKG v2.3; consulte (Solo LDAP) Actualizar configuración de LDAP.
  Para obtener más información sobre las variables de configuración nuevas y actualizadas, consulte Proveedores de identidad: LDAP en Referencia de variables de archivo de configuración.

• Debido a que el repositorio de paquetes Tanzu Standard se distribuye de forma independiente desde TKG, el archivo de TKG BoM ya no muestra una imagen de contenedor grafana. Otros componentes Tanzu Standard están planificados para su eliminación de la lista de materiales en una versión futura.
  • Para obtener una lista de los componentes distribuidos a través del repositorio de paquetes de Tanzu Standard, consulte las Notas de la versión del repositorio Tanzu Standard v2023.10.16 en la documentación de paquetes de Tanzu o el Repositorio Tanzu Standard v2023.7.13 a continuación.

Repositorio Tanzu Standard

Con TKG v2.3, el repositorio de paquetes Tanzu Standard se versiona y se distribuye de forma independiente desde TKG, y su control de versiones se basa en una marca de fecha. Consulte Repositorio Tanzu Standard v2023.7.13 a continuación para obtener más información.

Para cada versión de revisión de TKG v2.3, las notas de la versión de su última versión de repositorio Tanzu Standard compatible son las siguientes:

• TKG v2.3.1: Notas de la versión del repositorio Tanzu Standard v2023.10.16 en la documentación de paquetes de Tanzu
• TKG v2.3.0: Repositorio Tanzu Standard v2023.7.13, a continuación.

Versiones de paquetes, TKG y Kubernetes compatibles

A partir de TKG v2.2, la directiva de compatibilidad de VMware cambió 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 primeras dos secciones siguientes, 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.

En la tercera sección a continuación se enumeran las versiones de los paquetes del repositorio Tanzu Standard compatibles con Kubernetes v1.26, v1.25 y tkr 1.24.

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.3 con Kubernetes v1.26, v1.25 y v1.24 en el momento del lanzamiento. Una vez que TKG v2.1 alcance su hito de fin de soporte general, VMware dejará de admitir Kubernetes v1.24 con TKG. Una vez que TKG v2.2 alcance su hito de fin de soporte general, VMware dejará de admitir Kubernetes v1.25 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.

Las versiones de revisiones de Tanzu Kubernetes Grid son compatibles o eran compatibles con las versiones de revisiones 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.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

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. 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.3.0 finalizaría dos meses después de la disponibilidad general de TKG v2.3.1.

Versiones de paquete compatibles

Para TKG v2.3, las versiones del paquete en el repositorio Tanzu Standard son compatibles con TKr para las versiones secundarias 1.26, 1.25 y 1.24 de Kubernetes, como se indica a continuación:

Paquete	Versión de paquete	Kubernetes v1.26 TKrs	Kubernetes v1.25 TKrs	Kubernetes v1.24 TKrs
Administrador de certificados 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 externo 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	✖	✖	✔
Controlador de ayuda FluxCD fluxcd-helm-controller.tanzu.vmware.com	0.32.0+vmware.1-tkg.2-20230629	✔	✔	✔
	0.21.0+vmware.1-tkg.1-zshippable	✖	✖	✔
Controlador de fuente FluxCD fluxcd-origen-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	✔	✔	✔

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

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

Consulte las Notas de la versión del repositorio Tanzu Standard v2023.10.16 en la documentación de paquetes de Tanzu para obtener versiones de paquetes adicionales compatibles con TKG v2.3.

Consulte Versiones de componentes para obtener una lista completa de versiones de componentes incluidas en TKG v2.3.

	vSphere	AWS	Azure
Plataforma de la infraestructura	vSphere 7.0, 7.0U1-U3 vSphere 8.0, 8.0U1 VMware Cloud on AWS* v1.20, v1.22 Azure VMware Solution v2.0	AWS nativo	Azure nativo
CLI de Tanzu	Tanzu CLI Core v1.0.0**
Infraestructura de TKG API y de paquetes	Tanzu Framework v0.30.2
Creación y administración de clústeres	API de clúster principal (v1.4.5), proveedor de API del clúster vSphere (v1.7.1)	API de clúster principal (v1.4.5), PROVEEDOR de API del clúster AWS (v2.1.3)	API de clúster principal (v1.4.5), Proveedor de API del clúster Azure (v1.9.2)
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.11.2), Calico (v3.25.1), Multus CNI (v4.0.1, v3.8.0)
Registro de contenedores	Harbor (v2.8.4)
Entrada	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)
Almacenamiento	Interfaz de almacenamiento de contenedores de vSphere (v3.0.1*****) y almacenamiento nativo en la nube vSphere	Controlador CSI de Amazon EBS (v1.18.0) y proveedores de nube en el árbol	Controlador CSI de discos de Azure (v1.27.1), controlador CSI de archivos de Azure (v1.27.0) y proveedores de nube en el árbol
Autenticación	OIDC y LDAP a través de Pinniped (v0.24.0)
Observabilidad	Fluent Bit (v2.1.6), Prometheus (v2.45.0, v2.37.0)******, Grafana (v10.0.1)
Detección de servicios	DNS externo (v0.13.4)
Copia de seguridad y migración	Velero (v1.10.3)

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

** Para obtener una lista completa de las versiones de la CLI de Tanzu compatibles con esta versión, consulte la matriz de interoperabilidad de productos.

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.

***** 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 esta versión, consulte Versiones de los componentes.

****** Si actualiza un clúster a Kubernetes v1.25, debe actualizar Prometheus a la versión 2.37.0+vmware.3-tkg.1 como mínimo. 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.3, consulte la sección anterior Versiones de Kubernetes compatibles.

Versiones de los componentes

La versión de TKG v2.3.x incluye las siguientes versiones de componentes de software:

Nota

Las versiones anteriores de TKG incluían componentes que ahora se distribuyen a través del repositorio Tanzu Standard. Para obtener una lista de estos componentes, consulte Repositorio Tanzu Standard a continuación.

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*
clúster-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/C	Se quitó
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 nuevo componente o un nuevo bump de versiones desde la versión anterior. TKG v2.3.0 es anterior a v2.3.1 y TKG v2.2.0 es anterior a v2.3.0.

Para obtener una lista de versiones de componentes de software que se incluyen en TKG v2.3 utilice imgpkg para extraer los paquetes de repositorios y, a continuación, enumerar su contenido. Por ejemplo, para enumerar las versiones de componentes que se incluyen en el repositorio Tanzu Standard para TKG v2.3.1, ejecute el siguiente comando:

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

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

Rutas de actualización compatibles

En la ruta de acceso de actualización de TKG, v2.3 sigue inmediatamente a v2.2.0.

Solo puede actualizar a Tanzu Kubernetes Grid v2.3.x desde v2.2.x. Si desea actualizar a Tanzu Kubernetes Grid v2.3.x desde una versión anterior a v2.2.x, primero debe actualizar a v2.2.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.24.x a v1.26.x. Debe actualizar un clúster de la v1.24.x a la v1.25.x antes de actualizar el clúster a la v1.26.x.

Fechas de versión

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

• v2.3.1: 9 de noviembre de 2023
• v2.3.0: 1 de agosto de 2023

Cambios de comportamiento en Tanzu Kubernetes Grid v2.3

Tanzu Kubernetes Grid v2.3 introduce los siguientes comportamientos nuevos en comparación con la versión 2.2.0, que es la versión anterior más reciente.

• Carvel Tools se envían en un paquete de descarga dedicado. Para obtener información, consulte Instalar Carvel Tools.

• Cuando se utiliza un proveedor de identidad (IDP) de OIDC para la administración de identidades y acceso a través de Pinniped, el IDP de OIDC debe configurarse para emitir un token de actualización.

  • Esto puede requerir una configuración adicional en el IDP de OIDC.
  • Para ver un ejemplo de Okta, consulte Configurar administración de identidades.
  • Si el IDP de OIDC requiere ámbitos o parámetros adicionales para devolver un token de actualización, configure OIDC_IDENTITY_PROVIDER_SCOPES y OIDC_IDENTITY_PROVIDER_ADDITIONAL_AUTHORIZE_PARAMS con los ámbitos o los parámetros necesarios.
• Tanzu Kubernetes Grid ya no utiliza Dex para los proveedores de identidad de LDAP. Cada variable de configuración enumerada en la sección Proveedores de identidad: LDAP de la Referencia de variables del archivo de configuración ahora corresponde a una opción de configuración en el recurso personalizado LDAPIdentityProvider de Pinniped. Antes de actualizar un clúster de administración configurado para utilizar un proveedor de identidades LDAP a Tanzu Kubernetes Grid v2.3, actualice la configuración de LDAP como se describe en (solo LDAP) Actualizar configuración de LDAP. Toda la configuración de LDAP existente se migrará automáticamente al nuevo formato Pinniped durante la actualización del clúster de administración a la versión 2.3.
• Velero v1.10 presenta Cambios importantes en comparación con las versiones de Velero que se enviaron con versiones anteriores de TKG. Para obtener información sobre cómo mitigar estos cambios importantes al actualizar de Velero v1.9.x a v1.10, consulte Actualizar Velero.
• Al actualizar Tanzu Kubernetes Grid a la versión 2.3 en AWS, debe ejecutar tanzu mc permissions aws set después de actualizar la CLI de Tanzu, pero antes de actualizar el clúster de administración. Para obtener más información, consulte la pestaña AWS en Preparar para actualizar clústeres.
• Al crear definiciones de objetos ClusterClass personalizadas, ya no se descarga el manifiesto predeterminado del repositorio de Tanzu Framework. El manifiesto predeterminado está disponible cuando se crea un clúster de administración o se instala la CLI de Tanzu, o cuando se puede extraer del repositorio de imágenes de TKG. Para obtener más información, consulte Crear una ClusterClass personalizada.
• Al implementar un clúster de carga de trabajo con una versión de revisión de Kubernetes anterior a la última revisión admitida para su versión secundaria, debe crear un objeto ConfigMap para su TKr antes de implementar el clúster. Consulte Implementar el clúster de Kubernetes en la página Varias versiones de Kubernetes.

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

Avisos de desuso

El comando tanzu login se eliminará en las futuras versiones de TKG. El comando se reemplazará por el comando tanzu context. Para obtener más información, consulte contexto tanzu en la documentación de la CLI de VMware Tanzu.

Documentación del usuario

Implementar y administrar clústeres de administración independientes de TKG 2.3 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

• Problemas resueltos en v2.3.1
• Problemas resueltos en v2.3.0

Problemas resueltos en v2.3.1

Tanzu Kubernetes Grid v2.3.1 resuelve problemas y errores de clientes no documentados.

Problemas resueltos en v2.3.0

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

• No se admiten redes IPv6 en vSphere 8

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

• El escalador automático de clústeres no agrega las claves esperadas a MachineDeployment

  Si crea un clúster con el escalador automático de clústeres habilitado, las claves esperadas cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size y cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size no se agregan a metadata.annotations en MachineDeployment.

• Falta la variable de implementación del nodo de trabajo en las configuraciones ClusterClass

  WORKER_ROLLOUT_STRATEGYMachineDeployments Ahora puede establecer la variable de WORKER_ROLLOUT_STRATEGY en clústeres basados en clases, así como en clústeres basados en planes heredados. Para obtener más información, consulte Clústeres habilitados para GPU en Referencia de variables de archivo de configuración.

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

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

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

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

• 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 establecen en los objetos MachineDeployment del clúster y tienen que añadirse manualmente.

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

Problemas conocidos

A continuación se muestran los problemas conocidos de Tanzu Kubernetes Grid v2.3.x. Todos los problemas conocidos presentes en la versión 2.3.0 que se hayan resuelto en una versión de revisión posterior a v2.3.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

• Se produce un error al agregar un repositorio estándar para clústeres de nodo único

  Puede que se produzca un error al ejecutar 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.

  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

• En AWS y Azure, se produce un error de zona/región al crear un clúster de carga de trabajo con la especificación de objeto

  De forma predeterminada, en AWS o Azure, la ejecución de tanzu cluster create con una especificación de objeto de clúster basada en clases que se envía a --file hace que la CLI de Tanzu realice la verificación de regiones y zonas que solo son pertinentes para las zonas de disponibilidad de vSphere.

  Solución alternativa Al crear un clúster basado en clases en AWS o Azure, realice una de las siguientes acciones, en función de si utiliza el proceso de un paso o de dos pasos descrito en Crear un clúster basado en clases:

  • Un paso: Siga el proceso de un paso que se describe estableciendo features.cluster.auto-apply-generated-clusterclass-based-configuration en true sin pasar --dry-run al comando tanzu cluster create.

  • Dos pasos: Antes de ejecutar tanzu cluster create con la especificación de objeto como segundo paso, establezca SKIP_MULTI_AZ_VERIFY en true en el entorno local:

    export SKIP_MULTI_AZ_VERIFY=true
    

• Los componentes no se programan cuando se utilizan clústeres con capacidad limitada

  Para los clústeres de administración y los clústeres de carga de trabajo, si implementa clústeres con un solo nodo de plano de control, un solo nodo de trabajo o clústeres pequeños o medianos, es posible que se produzca una contención de programación de recursos.

  Solución alternativa: Utilice clústeres de nodo único o clústeres con un total de tres o más nodos.

• 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.26.8, 1.25.13 o 1.24.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.

• 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 escalar los recuentos de nodos del plano de control a un número par.

Redes

Nota

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

• Algunas variables de configuración de NSX ALB no funcionan

  En TKG v2.3, las variables de configuración del clúster de administración AVI_DISABLE_INGRESS_CLASS, AVI_DISABLE_STATIC_ROUTE_SYNC y AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER no funcionan.

  Después de crear el clúster de administración, para establecer cualquiera de sus propiedades subyacentes en el valor no predeterminado true, debe editar manualmente los dos objetos de configuración AKODeploymentConfig del clúster de administración como se describe a continuación.

  Solución alternativa: Edite los objetos install-ako-for-all y install-ako-for-management-cluster en el clúster de administración:

  1. Establezca el contexto kubectl en el clúster de administración:

     kubectl config use-context MGMT-CLUSTER-CONTEXT
     

  2. Edite las configuraciones de install-ako-for-all y install-ako-for-management-cluster:

     kubectl edit adc install-ako-for-all
     

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

  3. En las configuraciones, establezca las siguientes propiedades según desee:

     • extraConfigs.ingress.disableIngressClass: para la variable de configuración AVI_DISABLE_INGRESS_CLASS
     • extraConfigs.disableStaticRouteSync: para la variable de configuración AVI_DISABLE_STATIC_ROUTE_SYNC
     • extraConfigs.ingress.defaultIngressController: para la variable de configuración AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER

  4. Guarde y salga.

  Esta configuración se aplicará a los clústeres de carga de trabajo que el clúster de administración cree posteriormente.

• El modo de entrada NodePortLocal de NSX ALB no es compatible con el clúster de administración

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

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

vSphere

• Se produce un error al implementar el clúster de administración en vSphere 7 mientras se espera a que el plano de control del clúster esté disponible

  Si especifica la red de máquina virtual al implementar un clúster de administración para vSphere 7, se produce el error unable to set up management cluster: unable to wait for cluster control plane available: control plane is not available yet.

  Solución alternativa: A continuación, la red "Red de máquina virtual" tiene varias subredes configuradas con direcciones IP estáticas para VsVip y ServiceEngine. Establezca exclude_discovered_subnets en True en la red de máquina virtual para omitir las subredes detectadas y permitir que los servicios virtuales se coloquen en los motores de servicio.

• Las zonas de disponibilidad se pueden eliminar mientras se asignan máquinas virtuales

  Si elimina una zona de disponibilidad que contiene máquinas virtuales, las máquinas virtuales no se pueden eliminar posteriormente.

  Solución alternativa: Elimine todas las máquinas virtuales de una zona de disponibilidad antes de eliminarla.

• Se produce un error al crear clústeres de carga de trabajo debido a que se agota la sesión de VPXD

  Al crear clústeres de carga de trabajo en vSphere, se produce el siguiente error en la creación:

  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
  

  Esto ocurre debido a que la sesión de vCenter Server se agota.

  Solución alternativa: Consulte el artículo de la base de conocimientos de VMware 50114010.

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

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.

Repositorio Tanzu Standard v2023.7.13

Con TKG v2.3, el repositorio de paquetes Tanzu Standard se versiona y se distribuye de forma independiente desde TKG, y su control de versiones se basa en una marca de fecha.

Para TKG v2.3.0 y v2.3.1, la versión de revisión de TKG y su última versión de repositorio Tanzu Standard compatible se publican alrededor de la misma fecha.

Es posible que las futuras versiones del repositorio Tanzu Standard se publiquen con más frecuencia que las versiones de TKG, pero todas las versiones de revisión mantendrán compatibilidades existentes entre las versiones secundarias de TKG y Tanzu Standard.

Para cada versión de revisión de TKG v2.3, su última versión de repositorio Tanzu Standard compatible es:

• TKG v2.3.1: Tanzu Standard v2023.10.16
  • Notas de la versión: Consulte las Notas de la versión del repositorio Tanzu Standard v2023.10.16 en la documentación de paquetes de Tanzu
• TKG v2.3.0: Tanzu Standard v2023.7.13
  • Notas de la versión: Ver a continuación

Compatibilidad del paquete del repositorio Tanzu Standard

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.
• VMware ofrece compatibilidad de nivel de tiempo de ejecución para los paquetes compatibles con VMware Harbor, Contour y Velero cuando se implementan en Tanzu Kubernetes Grid.

Cert-manager v1.11.1

Novedades

• Consulte las notas de la versión de cert-manager v1.11.1
• El paquete vmware_cert-manager incluye el componente acmesolver de jetstack_cert-manager ascendente.

Versiones compatibles

Versión de TKG	Versión de jetstack_cert-manager	Versión del paquete vmware cert-manager	Compatibilidad de versión de Kubernetes
2.3	v1.11.1	v1.11.1+vmware.1	1.21-1.27

Versiones de los componentes

El administrador de certificados v1.11.1 contiene las siguientes versiones de imagen de 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

Desusos

Las siguientes versiones del administrador de certificados han quedado obsoletas en TKG v2.3:

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

Contour v1.24.4

Novedades

• Consulte las notas de la versión de Contour v1.24.0-4:
  • CHANGELOG-v1.24.0.md
  • CHANGELOG-v1.24.1.md
  • CHANGELOG-v1.24.2.md
  • CHANGELOG-v1.24.3.md
  • CHANGELOG-v1.24.4.md
• Puede configurar Envoy para que se instale como una implementación con un número especificado de réplicas en lugar de como un DaemonSet (valor predeterminado), utilizando valores de datos como los siguientes:

  envoy: 
    workload: 
      type: Deployment 
      replicas: 3
  

• Puede especificar solicitudes de recursos o límites para cada contenedor dentro de las cargas de trabajo de Contour y Envoy mediante valores de datos como los siguientes:

  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 
  

• Los valores de configuración de archivos data-values se verifican. Se produce un error al especificar un valor no compatible en los valores de datos.

Versiones de Kubernetes compatibles:

Contour v1.24.4 es compatible con Kubernetes v1.24-v1.26. Consulte la Matriz de compatibilidad de Contour.

Desusos

• Todas las versiones de Contour anteriores a la versión 1.24.4 se eliminaron del repositorio Tanzu Standard v2023.7.13.
• Los archivos del paquete de Contour data-values ya no aceptan valores null. Para cualquier campo de configuración con un valor establecido en null, debe omitir el valor por completo.

External-csi-snapshot-webhook v6.1.0

Novedades

• external-csi-snapshot-webhook es un nuevo paquete para TKG v2.3
• TKG v2.3 con un supervisor de vSphere 8.0U2 admite instantáneas CSI para el supervisor y los clústeres de carga de trabajo que implementa, pero primero debe instalar explícitamente external-csi-snapshot-webhook v6.1.0 mediante la CLI de Tanzu.

Versiones compatibles

Versión de TKG	Versión external-csi-snapshot-webhook	Compatibilidad de versión de Kubernetes esperada	Probado en la versión de Kubernetes
2.3.0	6.1.0	1.18 - más reciente	1.24

Dependencias

• external-csi-snapshot-webhook requiere cert-manager para una comunicación X509 segura con el servidor de API de Kubernetes.

Versiones de los componentes

external-csi-snapshot-webhook contiene la siguiente versión de imagen del componente:

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

DNS externo v0.13.4

Novedades

• Consulte las notas de la versión de DNS externo v0.13.4
• Nuevo campo de configuración createNamespace. Establézcalo en true para crear el espacio de nombres en el que se instalan los componentes external-dns. Si se establece en false, los componentes del paquete se instalan en un espacio de nombres existente.

Fluent-bit v2.1.2

Novedades

• Consulte las notas de la versión de Fluent Bit v2.1.2.

Problemas conocidos/Limitaciones

• No admite variables de entorno de credenciales de AWS en ConfigMap del paquete fluent-bit para acceder a AWS S3.
  • La compatibilidad con las credenciales de AWS está planificada para una versión futura.

Controladores fluxcd

Novedades

Consulte las siguientes notas de la versión del paquete de controladores Fluxcd:

• Fluxcd-helm-controller
  • Notas de la versión de fluxcd-helm-controller v0.21.0
  • Notas de la versión de fluxcd-helm-controller v0.28.1
• Fluxcd-kustomize-controller
  • Notas de la versión de fluxcd-kustomize-controller v0.24.4
  • Notas de la versión de fluxcd-kustomize-controller v0.32.0
• Fluxcd-source-controller
  • Notas de la versión de fluxcd-source-controller v0.24.4
  • Notas de la versión de fluxcd-source-controller v0.33.0

Grafana v9.5.1

Novedades

• Consulte las notas de la versión de Grafana v9.5.1

Versiones de los componentes

Grafana v9.5.1 contiene las siguientes versiones de imagen de componente:

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

Harbor v2.8.2

Novedades

• Consulte las notas de la versión de Harbor v2.8.2
• Debido a CVE, se eliminó la compatibilidad de TKG v2.3 con las siguientes versiones de Harbor:
  • 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

Versiones de los componentes

Harbor v2.8.2 contiene las siguientes versiones de imagen de componente:

• 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
• notary-server-photon:v2.8.2
• notary-signer-photon:v2.8.2
• redis-photon:v2.8.2
• trivy-adapter-photon:v2.8.2

Multus-CNI v4.0.1

Novedades

• Presenta una implementación y una arquitectura de complementos gruesos. Consulte la nueva función Multus-CNI v4.0.1

• Cambia los valores predeterminados de la siguiente manera:

  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

Novedades

• Consulte las notas de la versión de Prometheus v2.43.0

Versiones de los componentes

Prometheus v2.43.0 contiene las siguientes versiones de imagen de componente:

• 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

Novedades

• Consulte las notas de la versión de Velero v1.10.0
• Kopia reemplaza a Restic como el cargador. Esto da como resultado los siguientes cambios de interrupción. Para obtener más información, consulte Cambios importantes en el registro de cambios de Velero v1.10:
  • restic daemonset ha cambiado de nombre a node-agent
  • ResticRepository CR ha cambiado de nombre a BackupRepository
  • El comando velero restic repo se ha cambiado a velero repo
  • El secreto velero-restic-credentials ha cambiado a velero-repo-credentials
  • El parámetro default-volumes-to-restic ha cambiado a default-volumes-to-fs-backup
  • El parámetro restic-timeout ha cambiado a fs-backup-timeout
  • El parámetro default-restic-prune-frequency ha cambiado a default-repo-maintain-frequency
• Unifica el repositorio de copia de seguridad y lo desacopla de los motores de datos como se describe en Diseño de integración de Kopia y repositorios unificados.
• Refactoriza la copia de seguridad del sistema de archivos agregando una ruta Kopia junto con la ruta de Restic existente, admitiendo ambas a través de un parámetro de configuración uploader-type.
  • Consulte Copia de seguridad del sistema de archivos y Actualizar a Velero 1.10.
  • Para elegir entre Kopia y Restic, consulte Guía de rendimiento de copia de seguridad del sistema de archivos de Velero.
• Mueve los complementos BackupItemAction, RestoreItemAction y VolumeSnapshotterAction a la versión v1 para permitir cambios futuros en los complementos que pueden no ser compatibles con versiones anteriores, como tareas complejas de movimiento de datos, por ejemplo, tareas de movimiento de datos. Consulte Control de versiones de complementos.
• Agrega opciones para guardar credenciales para ubicaciones de instantáneas de volumen específicas; consulte Ubicaciones de almacenamiento de reserva y Ubicaciones de instantáneas de volumen.
• Mejora la solidez de las instantáneas de CSI con códigos de protección para el control de errores y la capacidad de omitir las comprobaciones de exclusión para que la instantánea CSI funcione con varios filtros de recursos de copia de seguridad.
• Admite la pausa o la anulación de pausa de programación de copia de seguridad:
  • Pase la marca de -paused para velero schedule create para crear una programación en pausa.
  • velero schedule pause y velero schedule unpause pausa y anula la pausa de una programación existente.

Versiones compatibles

Versión de TKG	Versión de Velero	Compatibilidad de versión de Kubernetes esperada	Probado en la versión de Kubernetes
2.3 (Halifax)	1.10	1.18-más reciente	1.22.5, 1.23.8, 1.24.6 y 1.25.1

Versiones de los componentes

Velero v1.10.3 contiene las siguientes versiones de imagen de 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

Para solucionar las CVE, las versiones de dependencia y tiempo de ejecución de Velero se actualizan de la siguiente manera:

• Go runtime v1.18.8
• Compiló Restic v0.13.1 con Go 1.18.8 en lugar de comprimir el binario de Restic oficial
• Se actualizaron las versiones de las bibliotecas dependientes principales

Actualizaciones

Los procedimientos de actualización anteriores no funcionan debido a cambios en la copia de seguridad del sistema de archivos. Para conocer los pasos de actualización nuevos, consulte Actualización a Velero 1.10.

Problemas conocidos/Limitaciones

• La copia de seguridad de Kopia no admite certificados autofirmados para almacenamiento compatible con S3. Para realizar un seguimiento de este problema, consulte Velero número 5123 y Kopia n.º 1443.
• No funciona con el complemento de vSphere más reciente para la versión de Velero, como se describe en Complemento vSphere para el problema de Velero #485. Hasta que se solucione este problema, no actualice el complemento de vSphere para que funcione con Velero v1.1.0.

Whereabouts v0.6.1

Novedades

• Admite ipRanges para configurar la asignación de IP de pila dual; consulte Ejemplo de configuración de IPv6 en el repositorio LÉAME de Whereabouts.