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

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

TKG v2.1 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.1 es la primera versión de TKG que 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 supervisor de vSphere with Tanzu 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.1 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.1 incluye las siguientes funciones nuevas.

Tanzu Kubernetes Grid v2.1.1

Nuevas funciones de Tanzu Kubernetes Grid v2.1.1:

• Admite el uso de NSX Advanced Load Balancer v22.1.2 o versiones posteriores en vSphere 8 con un clúster de administración independiente de TKG y sus clústeres de carga de trabajo.
• Puede instalar la versión FIPS de TKG v2.1.1. Para obtener más información, consulte Versiones compatibles con FIPS.
• Variables de configuración:
  • Comprobaciones de estado de máquinas: MHC_MAX_UNHEALTHY_CONTROL_PLANE y MHC_MAX_UNHEALTHY_WORKER_NODE. Para obtener más información, consulte Comprobaciones de estado de máquinas en Referencia de variables de archivo de configuración.
  • Compatibilidad con el servidor tdnf con certificado personalizado: CUSTOM_TDNF_REPOSITORY_CERTIFICATE (vista previa técnica). Para obtener más información, consulte Configuración de nodo en Referencia de variables de archivo de configuración.
  • Compatibilidad con la configuración de proxy a nivel de nodo: TKG_NODE_SYSTEM_WIDE_PROXY (vista previa técnica). Para obtener más información, consulte Configuración de proxy en Referencia de variables de archivo de configuración.

Tanzu Kubernetes Grid v2.1.0

Nuevas funciones de Tanzu Kubernetes Grid v2.1.0:

• Compatibilidad con TKG 2.x: En vSphere, AWS o Azure con un clúster de administración independiente, configure y cree clústeres basados en clases como se describe en Tipos de clústeres de carga de trabajo.
• Puede instalar la versión FIPS de TKG v2.1.0. Para obtener más información, consulte Versiones compatibles con FIPS.
• CLI de Tanzu:
  • El complemento package utiliza comandos de estilo kctrl de forma predeterminada. Consulte Paquete de Tanzu en la Referencia de comandos de la CLI de Tanzu.
  • El complemento isolated-cluster download-bundle y los comandos upload-bundle recuperan y transfieren todas las imágenes de contenedor que TKG necesita, como se describe en Preparar un entorno con acceso a Internet restringido.
  • Las opciones -A y --all-namespaces para tanzu cluster list incluye clústeres en todos los espacios de nombres que administra el clúster de administración y para los que el usuario tiene permisos de View o superiores, no solo el espacio de nombres predeterminado.
  • El grupo de comandos context permite a los usuarios establecer y administrar contextos para la CLI de Tanzu, que incluyen el servidor de destino y el kubeconfig que se aplicará. Consulte Contexto de Tanzu en la Referencia de comandos de la CLI de Tanzu.
    • Las versiones futuras eliminarán el comando tanzu login en favor de los comandos tanzu context.
  • La categoría Target para complementos cambia el comportamiento de la CLI y agrega funcionalidades reservadas para un uso futuro, como se describe en Cambios en el comportamiento de Tanzu Kubernetes Grid v2.1, a continuación.
  • La función auto-apply-generated-clusterclass-based-configuration aplica automáticamente la configuración del clúster basada en clases generada por la CLI de Tanzu cuando se pasa un archivo de configuración del clúster heredado a tanzu cluster create. La función está establecida en false de forma predeterminada. Consulte Funciones en Arquitectura y configuración de la CLI de Tanzu.
  • La función allow-legacy-cluster permite crear clústeres basados en planes. La función está establecida en false de forma predeterminada. Consulte Funciones en Arquitectura y configuración de la CLI de Tanzu.
  • Los comandos tanzu mc credentials update y tanzu cluster credentials update agregan opciones para Azure. Esto incluye --azure-client-id, --azure-client-secret y --azure-tenant-id.
• Las siguientes variables de configuración de clústeres son compatibles con clústeres basados en clases y clústeres de administración independientes, como se describe en Referencia de variables del archivo de configuración:
  • Configuración de nodos: CONTROL_PLANE_NODE_LABELS, CONTROL_PLANE_NODE_NAMESERVERS, CONTROL_PLANE_NODE_SEARCH_DOMAINS, WORKER_NODE_NAMESERVERS, WORKER_NODE_SEARCH_DOMAINS
  • Propiedad ExtraArgs: APISERVER_EXTRA_ARGS, CONTROLPLANE_KUBELET_EXTRA_ARGS, ETCD_EXTRA_ARGS, KUBE_CONTROLLER_MANAGER_EXTRA_ARGS, KUBE_SCHEDULER_EXTRA_ARGS, WORKER_KUBELET_EXTRA_ARGS
  • Sincronización y limitación de velocidad: NTP_SERVERS, APISERVER_EVENT_RATE_LIMIT_CONF_BASE64
• Los clústeres pueden renovar automáticamente los certificados de máquina virtual del nodo de plano de control; consulte Renovación automática de certificados del nodo de plano de control.
• (vSphere) Puede implementar clústeres de carga de trabajo de varios sistemas operativos que ejecuten nodos de trabajo basados en Linux y Windows, como se describe en Implementar un clúster de carga de trabajo de varios sistemas operativos. En esta versión, los clústeres de carga de trabajo de Windows se reemplazan por clústeres de carga de trabajo de varios sistemas operativos. Para obtener más información, consulte Cambios de comportamiento en Tanzu Kubernetes Grid v2.1.
  • Puede implementar clústeres de carga de trabajo de varios sistemas operativos con trabajadores en varias zonas de disponibilidad, como se describe en Implementar clústeres de carga de trabajo en varias zonas de disponibilidad (vista previa técnica de vSphere).
• (vSphere) Los clústeres de carga de trabajo basados en clases se pueden configurar con la administración de direcciones IP en clúster (IPAM) a través de un grupo de direcciones IP asignadas, lo que elimina la necesidad de configurar reservas de DHCP cuando cambian instancias o recuentos de nodos.
• (vSphere) Las etiquetas del objeto Machine del nodo de clúster identifican la dirección de su host ESXi, para admitir el uso de nodeSelector para ejecutar cargas de trabajo específicas en hardware especializado.
• (vSphere) Las imágenes OVA de Ubuntu utilizan el modo de interfaz de firmware extensible unificada (UEFI) para el arranque, reemplazando el modo de firmware de BIOS tradicional. El modo UEFI habilita las cargas de trabajo de la unidad de procesamiento gráfico (GPU) y mejora la seguridad del nodo. Para obtener más información sobre UEFI en Ubuntu, consulte UEFI en la documentación de Ubuntu.
• Puede utilizar Kube-VIP como servicio LoadBalancer de capa 4 para cargas de trabajo; consulte Equilibrador de carga de Kube-VIP (vista previa técnica).
• Puede implementar clústeres de carga de trabajo de nodo único que ejecuten tanto cargas de trabajo alojadas como la infraestructura del plano de control en un único host ESXi, para aplicaciones de Edge, como se describe en Clústeres de nodo único en vSphere (vista previa técnica).
  • Puede implementar un mínimo de clústeres de nodo único en función de las TKr tiny que minimicen su espacio.
• Puede realizar una copia de seguridad e implementar la infraestructura del clúster 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).
• Admite controladores de admisión de seguridad de pods (PSA) para reemplazar las directivas de seguridad de pods, como se describe en los espacios de nombres, como se indica enControlador de admisión de seguridad de pods (vista previa técnica).

Versiones de Kubernetes compatibles con Tanzu Kubernetes Grid v2.1

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

Cualquier versión de Tanzu Kubernetes Grid admite todas las versiones de TKr de las dos líneas secundarias anteriores de Kubernetes, excepto donde se indique Problema conocido. Por ejemplo, TKG v2.1.x admite las versiones de Kubernetes v1.23.x y v1.22.x que se enumeran a continuación, pero no v1.21.x ni versiones anteriores.

Versión de Tanzu Kubernetes Grid	Versión de Kubernetes del clúster de administración	Versiones de Kubernetes (TKr) proporcionadas
2.1.1	1.24.10	1.24.10, 1.23.16, 1.22.17
2.1.0	1.24.9	1.24.9, 1.23.15, 1.22.17
1.6.1	1.23.10	1.23.10, 1.22.13, 1.21.14
1.6.0	1.23.8	1.23.8, 1.22.11, 1.21.14
1.5.4	1.22.9	1.22.9, 1.21.11, 1.20.15
1.5.3	1.22.8	1.22.8, 1.21.11, 1.20.15
1.5.2, 1.5.1, 1.5.0	1.22.5	1.22.5, 1.21.8, 1.20.14

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

Tanzu Kubernetes Grid v2.1 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 los componentes que aparecen entre paréntesis se incluyen en Tanzu Kubernetes Grid v2.1.1. 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.28.1
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.6)
Redes de contenedores	Antrea (v1.7.2), Calico (v3.24.1)
Registro de contenedores	Harbor (v2.6.3)
Entrada	NSX Advanced Load Balancer Essentials y controlador Avi **** (v21.1.3- v21.1.6, v22.1.1, v22.1.2), Contour (v1.22.3)	Contour (v1.22.3)	Contour (v1.22.3)
Almacenamiento	Interfaz de almacenamiento del contenedor de vSphere (v2.5.2*) y almacenamiento nativo en la nube de vSphere	Controlador CSI de Amazon EBS (v1.8.0) y proveedores de nube en el árbol	Controlador CSI de discos de Azure (v1.19.0), controlador CSI de archivos de Azure (v1.21.0) 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.5)

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

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

Versiones de los componentes

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

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

^* Indica un nuevo componente o un nuevo bump de versiones desde la versión anterior. TKG v2.1.0 es anterior a v2.1.1, y v1.6.1 es anterior a v2.1.0.

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

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

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

Rutas de actualización admitidas

En la ruta de acceso de actualización de TKG, v2.1 sigue inmediatamente a v1.6. TKG v2.0 no es una versión descargable de TKG: es la versión de TKG que está integrada en el Supervisor de vSphere with Tanzu en vSphere 8.

Solo puede actualizar a Tanzu Kubernetes Grid v2.1.x desde v1.6.x. Si desea actualizar a Tanzu Kubernetes Grid v2.1.x desde una versión anterior a v1.6.x, primero debe actualizar a v1.6.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.21.x a v1.23.x. Debe actualizar un clúster de v1.21.x a v1.22.x antes de actualizar el clúster a v1.23.x.

Fechas de versión

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

• v2.1.0: 29 de enero de 2023
• v2.1.1: 21 de marzo de 2023

Cambios de comportamiento en Tanzu Kubernetes Grid v2.1

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

• La opción --include-management-cluster para tanzu cluster list requiere la opción -A para enumerar un clúster de administración independiente. Con la opción -A, el comando enumera los clústeres de todos los espacios de nombres.

• El complemento package de la CLI de Tanzu utiliza comandos de estilo kctrl de forma predeterminada. Consulte Paquete de Tanzu con kctrl en la referencia de comandos de CLI de Tanzu.

  • En TKG v1.6, el complemento package se ejecutaba de forma predeterminada con el modo kctrl desactivado, denominado modo heredado a continuación.

  • Los comandos del modo kctrl y del modo heredado se diferencian de la siguiente manera:

    • Para crear un archivo de valores predeterminados para la configuración del paquete, los comandos tanzu package available get del modo kctrl utilizan la marca--generate-default-values-file en lugar de --default-values-file-output.
    • Se elimina la marca --create-namespace. Si utiliza -n o --namespace para especificar un espacio de nombres de destino, el espacio de nombres ya debe existir.
    • Se eliminó la marca --create para package repository update.
    • El nombre de la marca --package-name se cambió a --package para package installed create y package install.
    • Se eliminó la marca --install para package installed update.
    • Se eliminó la marca global --verbose.
    • El nombre delas marcas --poll-interval y -poll-timeout se cambió a --wait-interval y --wait-timeout.
    • En los resultados de package available get, una tabla adicional enumera las versiones disponibles para el paquete.
    • En los resultados de la lista package available list, se eliminó la columna LATEST-VERSION y SHORT-DESCRIPTION no se muestra de forma predeterminada; para que se muestre, utilice la marca --wide.
    • En la salida de package repository list, las columnas REPOSITORY y TAG se reemplazaron por una columna SOURCE que consta de tipo de origen (por ejemplo, imgpkg), URL del repositorio y etiqueta.

  • Consulte los temas en Paquetes administrados por CLI en la documentación de TKG v1.6 para conocer cómo funciona el complemento tanzu package con el modo kctrl desactivado.

• El repositorio de paquetes tanzu-standard no está preinstalado en clústeres basados en clases. Para agregar el repositorio de paquetes, consulte Agregar un repositorio de paquetes.
• El proceso de creación de clústeres de administración de la CLI de Tanzu ya no admite la creación de una nueva VPC. La interfaz del instalador no incluye una opción para crear una nueva VPC, y los archivos de configuración del clúster ya no admiten las opciones AWS_* para crear una nueva VPC para un CIDR especificado. Si desea utilizar una nueva VPC, antes de implementar un clúster de administración independiente en AWS, debe crear una VPC para la implementación de TKG mediante la consola de AWS.

• CLI de Tanzu utiliza una nueva abstracción Targets para asociar diferentes grupos de comandos con el tipo de servidor al que se aplican los comandos. El comando tanzu context list hace referencia al mismo concepto que tipo de contexto, con la marca --target. Debido a que los grupos de comandos se basan en complementos de CLI:

  • Los complementos que definen comandos para clústeres de Kubernetes tienen el Target k8s
  • Los complementos que definen comandos para comandos de TMC tienen el Target tmc reservado para un uso futuro
  • Los complementos que definen comandos independientes del contexto no tienen Target
  • Los complementos con nombres idénticos para diferentes destinos permiten que los comandos personalizados de la CLI de Tanzu en los grupos de comandos, como tanzu cluster, se ajusten al contexto.

  En TKG v2.1, el único tipo de contexto o Target compatible es k8s, que también se indica mediante:

  • Kubernetes cluster operations en los resultados de los comandos tanzu help
  • kubernetes en la columna TARGET de los resultados de tanzu plugin list
• VMware no recomienda implementar clústeres de carga de trabajo que solo tengan trabajos basados en Windows, como se describe en la documentación de TKG v1.6. En su lugar, VMware recomienda crear clústeres con varios sistemas operativos, como se describe en Implementar un clúster de carga de trabajo de varios sistemas operativos. Los clústeres de varios sistemas operativos pueden ejecutar contenedores Windows y Linux, por lo que admiten tanto componentes de TKG basados en Linux como cargas de trabajo de Linux.
• Debido a los cambios en la gestión de certificados en Go v1.18, las máquinas de arranque de MacOS necesitan agregar el certificado de vCenter a sus cadenas de claves para poder ejecutar tanzu cluster create con verificación por huella digital; consulte Requisitos previos para la implementación de clústeres.

Documentación del usuario

Una nueva publicación, Implementar y administrar clústeres de administración independientes de TKG 2.1, 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.1.1
• Problemas resueltos en v2.1.0

Problemas resueltos en v2.1.1

Los siguientes problemas documentados como Problemas conocidos en Tanzu Kubernetes Grid v2.1.0 han resuelto en Tanzu Kubernetes Grid v2.1.1.

• No se puede implementar una CNI personalizada

  La opción CNI:none no funciona en los clústeres de carga de trabajo implementados desde un clúster de administración independiente. Las únicas opciones disponibles son antrea (valor predeterminado) y calico.

• La cuenta de usuario de TKG crea sesiones de vCenter inactivas

  La cuenta de vSphere para TKG crea sesiones de vCenter inactivas y como se indica en vSphere > Hosts y clústeres > su vCenter > pestaña Supervisor > Sesiones.

  Solución alternativa: Elimine las sesiones de vCenter inactivas iniciando y deteniendo todas las sesiones:

  1. ssh en vCenter como root
  2. Si se le solicita, escriba shell
  3. Ejecute service-control --stop --all
  4. Espere a que los servicios se muestren como Stopped
  5. Ejecute service-control --start --all

• Los servicios LoadBalancer para clústeres de carga de trabajo basados en clases en Azure necesitan una configuración manual de puerta de enlace o front-end

  Debido a una falta de coincidencia de nombre entre AzureClusterName y ClusterName, no se puede acceder desde Internet a los servicios de tipo LoadBalancer que se implementan para su uso por parte de aplicaciones en clústeres de carga de trabajo de Azure basados en clases.

  Solución alternativa: Proporcione su propia ruta para el servicio del equilibrador de carga, por ejemplo, a través de una puerta de enlace NAT, un proxy u otro enrutamiento interno, para permitir que los nodos detrás del equilibrador de carga accedan a Internet.

  VMware recomienda utilizar una puerta de enlace NAT, si está disponible, para la conectividad saliente. Si una puerta de enlace NAT no está disponible:

  1. En el portal de Azure, desplácese hasta el recurso LoadBalancer que crea CAPZ, que debe tener el mismo nombre que el de AzureCluster.
  2. Seleccione Configuración de IP de front-end (Frontend IP configuration) y haga clic en Añadir (Add).
  3. Cree una nueva dirección IP pública para el servicio del equilibrador de carga.

  4. Configure y cree el servicio con la siguiente especificación; establezca el valor loadBalancerIP en la dirección IP pública donde se indique con IP-ADDRESS:

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

• La actualización de clústeres no actualiza la versión de Kube-VIP

  Al actualizar los clústeres de carga de trabajo y administración independientes a la versión 2.1, no se actualiza su kube-vip a la versión actual.

  Solución alternativa: Para los clústeres actualizados que utilizan Kube-VIP para su endpoint de plano de control, tal como se configuró con AVI_CONTROL_PLANE_HA_PROVIDER = false, actualice el componente kube-vip:

  1. Recupere el archivo de TKr BoM actual utilizado para la actualización del clúster. Busque una copia local de este archivo en ~/.config/tanzu/tkg/bom/ con un nombre de archivo que empiece con tkr-. Por ejemplo, tkr-bom-v1.24.10+vmware.1-tkg.1.yaml.

  2. Enumere la versión actual kube-vip del archivo de la BoM, por ejemplo:

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

  3. Obtenga el objeto kcp para el clúster. El nombre de este objeto tiene el formato CLUSTER-NAME-control-plane.

     • Los objetos del clúster de administración se crean en el espacio de nombres tkg-system.
     • Los objetos del clúster de carga de trabajo se encuentran en el espacio de nombres utilizado para la creación del clúster o default si no se estableció NAMESPACE.

  4. Ejecute kubectl edit para editar el objeto kcp y actualice la ruta de acceso de kube-vip para que coincida con la versión actual de la imagen de la BoM. Busque la ubicación de este ajuste ejecutando:

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

• La actualización de los clústeres de administración de v1.5.x a v2.1.0 provoca un error de red de nodo debido a una avi_ingress_node_network_list nula en el secreto de operador de AKO

  Con clústeres de administración independientes creados originalmente en TKG v1.5 o versiones anteriores, la actualización a la versión 2.1.0 establece un valor nulo para avi_ingress_node_network_list en el secreto de operador de AKO. Esto provoca un error de red de nodo al actualizar a la versión 2.1.0 y genera errores de configuración de AVI faltantes en los registros.

  Solución alternativa: Después de actualizar CLI de Tanzu a la versión 2.1.0, pero antes de ejecutar tanzu mc upgrade:

  1. Cambie al contexto del clúster de administración:

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

  2. Recupere el secreto de operador de AKO y descodifique sus valores de datos:

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

  3. Abra el archivo values.yaml con un editor de texto. El ajuste avi_ingress_node_network_list tendrá este aspecto:

     avi_ingress_node_network_list: '""'
     

  4. Cambie el ajuste como este, con el rango de la red de nodos del clúster:

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

  5. Codifique en base64 los nuevos valores de datos y registre la cadena de resultados:

     base64 -w 0 values.yaml
     

  6. Edite el secreto de operador de AKO:

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

  7. Pegue la nueva cadena de valores de datos codificados como el valor de values.yaml en el secreto. Guarde y salga.

• TMC no puede implementar clústeres basados en clases con motores de servicio que no estén en el SEG Default-Group.

  Tanzu Mission Control, que se integra con TKG, no puede implementar nuevos clústeres basados en clases que utilicen NSX ALB y que estén configurados con motores de servicio que no estén en el grupo de motores de servicio Default-Group en NSX ALB. Esta limitación no afecta a la actualización de los clústeres de carga de trabajo existentes configurados con motores de servicio personalizados.

  Para obtener más información, consulte las Notas de la versión de Tanzu Mission Control.

• No se admite el catálogo de TMC para enumerar e implementar paquetes

  No se puede utilizar la función Catálogo de Tanzu Mission Control (TMC) para enumerar o instalar paquetes en clústeres de carga de trabajo de TKG v2.1, como se describe en Ver paquetes en la documentación de TMC. La interfaz de usuario de TMC mostrará el repositorio de paquetes bloqueado en un estado de conciliación.

Problemas resueltos en v2.1.0

Los siguientes problemas documentados como Problemas conocidos en Tanzu Kubernetes Grid v1.6.1 se han resuelto en Tanzu Kubernetes Grid v2.1.0.

• Las operaciones de clúster y pod que eliminan pods pueden fallar si DaemonSet está configurado para restaurar automáticamente volúmenes persistentes

  En instalaciones en las que un DaemonSet utiliza volúmenes persistentes (PV), es posible que se produzca un error en la eliminación de la máquina debido a que el proceso de purga de forma predeterminada ignora DaemonSets y el sistema espera de forma indefinida a que los volúmenes se desconecten del nodo. Las operaciones del clúster afectadas incluyen la actualización, la reducción horizontal y la eliminación.

• En vSphere with Tanzu, tanzu cluster list genera un error para los usuarios de desarrollo y operaciones

  Cuando un usuario con la función de ingeniero de desarrollo y operaciones, como se describe en Flujos de trabajo y funciones de usuario de vSphere with Tanzu, ejecuta tanzu cluster list, es posible que vea un error similar a Error: unable to retrieve combined cluster info: unable to get list of clusters. User cannot list resource "clusters" at the cluster scope.

  Esto sucede porque el comando tanzu cluster command sin una opción -n intenta acceder a todos los espacios de nombres, algunos de los cuales pueden no estar accesibles para un usuario ingeniero de desarrollo y operaciones.

  Solución alternativa: Al ejecutar tanzu cluster list, incluya un valor --namespace para especificar un espacio de nombres al que el usuario pueda acceder.

Problemas conocidos

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

• Actualizar
• Paquetes
• Operaciones del clúster
• Redes
• Administración de identidades y acceso
• Almacenamiento
• CLI
• vSphere
• AWS
• Clústeres de carga de trabajo de varios sistemas operativos y Windows
• Image Builder
• AVS

Actualizar

• Problemas conocidos en v2.1.1
• Problemas conocidos en v2.1.x

Problemas conocidos en v2.1.1

A continuación, se muestran los problemas de actualización conocidos de v2.1.1.

• Se produce un error al actualizar de v2.1 a v2.1.1 en vSphere

  En vSphere, se produce el siguiente error al actualizar de v2.1 a v2.1.1, Reconcile failed:Error. El error se produce porque el paquete tkg-clusterclass-vsphere no se concilia y la instalación está bloqueada.

  Solución alternativa: Anule la configuración de las siguientes variables de recursos de vSphere si están establecidas en el entorno local:

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

Problemas conocidos en v2.1.x

A continuación, se muestran los problemas de actualización conocidos de v2.1.x.

• Se produce un error al actualizar los clústeres en Azure

  En Azure, se produce un error al actualizar los clústeres de administración y los clústeres de carga de trabajo con errores como context deadline exceeded o unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane. Esto sucede porque las operaciones en Azure a veces tardan más que en otras plataformas.

  Solución alternativa: Vuelva a ejecutar tanzu management-cluster upgrade o tanzu cluster upgrade y especifique un tiempo de espera más largo en la marca --timeout. El tiempo de espera predeterminado es 30m0s.

• Se produce un error en la actualización de los clústeres de administración independientes creados originalmente en TKG v1.3 o versiones anteriores

  En TKG v2.1, los componentes que convierten un clúster genérico en un clúster de administración independiente de TKG se empaquetan en un paquete Carvel tkg-pkg. Los clústeres de administración independientes que se crearon originalmente en TKG v1.3 o versiones anteriores carecen de un secreto de configuración que el proceso de actualización requiere para instalar tkg-pkg, lo que provoca un error en la actualización.

  Solución alternativa: Realice los pasos adicionales que se indican en Actualizar clústeres de administración independientes para los clústeres de administración independientes creados en TKG v1.3 o versiones anteriores.

• Se produce un error en la actualización de los clústeres creados con el carácter comodín (*) en el ajuste TKG_NO_PROXY

  TKG v1.6 no permite el carácter comodín (*) en los ajustes del archivo de configuración del clúster para TKG_NO_PROXY. Los clústeres creados por versiones anteriores de TKG con esta opción requieren un control especial antes de actualizar, para evitar el error workload cluster configuration validation failed: invalid string '*' in TKG_NO_PROXY.

  Solución alternativa: Según el tipo de clúster que esté actualizando:

  • Clúster de administración:

    1. Cambie al contexto kubectldel clúster de administración.

    2. Edite configMap kapp-controller-config:

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

    3. Busque el campo data.noProxy y cambie su nombre de host comodín eliminando *. Por ejemplo, cambie *.vmware.com to .vmware.com

    4. Guarde y salga. El clúster está listo para actualizarse.

  • Clúster de carga de trabajo:

    1. Cambie al contexto de clúster de carga de trabajo kubectl

    2. Establezca variables de entorno para el nombre y el espacio de nombres del clúster, por ejemplo:

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

    3. Obtenga y descodifique los valores de datos del controlador kapp para el clúster de carga de trabajo:

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

    4. Edite el archivo ${CLUSTER_NAME}-${NS}-kapp-controller-data-values eliminando * de su ajuste kappController.config.noProxy. Por ejemplo, cambie *.vmware.com to a .vmware.com.

    5. Guarde y salga.

    6. Vuelva a codificar el archivo de valores de datos ${CLUSTER_NAME}-${NS}-kapp-controller-data-values:

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

    7. Edite el secreto ${CLUSTER_NAME}-${NS}-kapp-controller-data-values y actualice su ajuste data.value.yaml pegando la cadena de valores de datos recién codificados.

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

    8. Guarde y salga. El clúster está listo para actualizarse.

• Los TKr de versiones anteriores no están disponibles inmediatamente después de actualizar el clúster de administración independiente

  Al actualizar un clúster de administración independiente de TKG v1.6 a v2.1, se reemplaza el controlador de origen de TKr por una versión más reciente que admite clústeres basados en clases y, a continuación, se vuelven a sincronizar TKr. Como resultado, una vez que se complete el comando tanzu mc upgrade, es posible que tanzu cluster available-upgrades get y tanzu kubernetes-release get no muestren todas las versiones válidas de TKr y que la CLI de Tanzu no pueda actualizar inmediatamente los clústeres de carga de trabajo.

  Solución alternativa: Espere unos minutos para que los TKr se vuelvan a descargar.

Paquetes

• La actualización de la configuración requiere la actualización de algunos paquetes

  Problema conocido: v2.1.1

  El repositorio de paquetes Tanzu Standard para TKG v2.1.1 no tiene las siguientes versiones de paquetes que se encuentran en el repositorio de v2.1.0:

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

  Por este motivo, después de actualizar un clúster de carga de trabajo de TKG v2.1.0 a v2.1.1, no se puede ejecutar tanzu package installed update para actualizar las configuraciones de estos paquetes sin actualizar también los paquetes a las versiones más recientes:

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

  Este problema solo se genera si necesita cambiar la configuración del paquete; los paquetes instalados seguirán ejecutándose sin actualizar.

  Solución alternativa: Realice una de las siguientes acciones:

  • Si necesita actualizar la configuración del paquete cert-manager, external-dns o grafana:

    1. Ejecute tanzu package installed get para recuperar la versión del paquete.
    2. Como se indica anteriormente, si el repositorio v2.1.1 no tiene la versión del paquete instalada, pase la versión más reciente a la marca -v al ejecutar tanzu package installed update.

  • Después de actualizar los clústeres de carga de trabajo a TKG v2.1.1, actualice los tres paquetes a las versiones anteriores.

  Para obtener los comandos tanzu package, consulte , como se describe en Instalar y administrar paquetes.

• Se produce un error en la CNI de Multus en pods medium y más pequeños con NSX Advanced Load Balancer

  En vSphere, los clústeres de carga de trabajo con nodos de trabajo medium o más pequeños que ejecutan el paquete de la CNI de Multus con NSX ALB pueden generar errores con Insufficient CPU u otro tipo de errores.

  Solución alternativa: Para utilizar la CNI de Multus con NSX ALB, implemente clústeres de carga de trabajo con nodos de trabajo de tamaño large o extra-large.

• El archivo BoM de TKG contiene una versión errónea del paquete cert-manager

  El archivo de la lista de materiales (BoM) de TKG que la CLI de Tanzu instala en ~/.config/tanzu/tkg enumera las versiones v1.5.3 y v1.7.2 para el paquete cert manager (jetstack_cert-manager). La versión correcta para instalar es la 1.5.3, como se describe en Instalar cert-manager.

  Solución alternativa: Instale la versión 1.5.3 de cert-manager.

• Para desactivar Pinniped, es necesario eliminar Secret de forma manual en los clústeres heredados

  Cuando se desactiva la administración de identidades externa en un clúster de administración, el objeto Pinniped no utilizado Secret permanece presente en los clústeres de carga de trabajo heredados.

  Si un usuario intenta acceder al clúster mediante un kubeconfig antiguo, aparecerá una ventana emergente de inicio de sesión y se producirá un error.

  Solución alternativa: Elimine manualmente Pinniped Secret del clúster heredado, como se describe en Desactivar administración de identidades.

• 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.6.3, que es la versión empaquetada para TKG v2.1, tiene un problema conocido por el 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 asciende a 1 000 000 o más.

  Este problema de Harbor se resuelve en versiones posteriores de Harbor que están programadas para incluirse en versiones posteriores de TKG.

• No se admite la memoria caché del proxy de Harbor

  No se puede utilizar Harbor en la función caché del proxy para ejecutar Tanzu Kubernetes Grid v2.1 en un entorno con acceso a Internet restringido. Puede seguir utilizando una memoria caché de proxy de Harbor para aplicar el proxy a imágenes de versiones anteriores de Tanzu Kubernetes Grid, así como imágenes que no son de Tanzu, como las imágenes de aplicaciones.

  Solución alternativa: Ninguna

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

  Solución alternativa: Establezca las etiquetas audit=privileged y warn=privileged en los espacios de nombres del paquete afectado, como se describe en Controlador de admisión de seguridad de pods (vista previa técnica).

• 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

• Problemas conocidos en v2.1.1
• Problemas conocidos en v2.1.

Problemas conocidos en v2.1.1

Los siguientes son problemas conocidos de operaciones de clúster en la v2.1.1.

• 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 es la versión predeterminada de Kubernetes en TKG v1.6.1, como se indica en Versiones de Kubernetes compatibles en Tanzu Kubernetes Grid v2.1.

  TKG v2.1.1 es totalmente compatible con clústeres existentes que ejecutan versiones anteriores de Kubernetes.

  Solución alternativa: Cree un clúster de carga de trabajo que ejecute Kubernetes 1.24.10, 1.23.16 o 1.22.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.

Problemas conocidos en v2.1.

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

  Solución alternativa: En el segundo paso, al ejecutar tanzu cluster create por segunda vez y pasar el manifiesto del clúster generado, especifique los mismos valores de --tkr y de otras opciones que especificó en el primer paso, como se describe en Crear un clúster basado en clases.

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

• 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. Esto sucede porque en TKG 2.1.1, los recursos de AntreaConfig necesitan la etiqueta de tkg.tanzu.vmware.com/package-name label para que el administrador de complementos instale Antrea en el clúster de carga de trabajo designado. Este problema no se aplica a 2.1.0.

  Solución alternativa: Agregue las etiquetas que faltan a AntreaConfig en el archivo de configuración ClusterClass e intente crear el clúster de nuevo:

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

• No se admiten redes IPv6 en vSphere 8

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

Almacenamiento

• Al cambiar el objeto StorageClass predeterminado, se produce un error de conciliación en los clústeres de carga de trabajo

  Si se modifican las propiedades de un objeto StorageClass predeterminado incluido en TKG, se produce un error de conciliación de paquetes en los clústeres de carga de trabajo que utilizan la clase de almacenamiento.

  Solución alternativa: Para personalizar una clase de almacenamiento, cree una nueva definición de StorageClass con un name diferente, en lugar de modificar la definición de objeto predeterminada, y vuelva a configurar el clúster para que use la nueva clase de 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

• 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

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

  Solución alternativa: Establezca el parámetro de configuración o los parámetros enumerados en la salida de error como variables de entorno local. Como alternativa, para evitar este error, puede crear clústeres basados en clases en un paso, sin previsualizar su configuración, estableciendo la función auto-apply-generated-clusterclass-based-configuration en true y, a continuación, ejecutando tanzu cluster create. Para establecer auto-apply-generated-clusterclass-based-configuration en true, ejecute:

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

  Esto configura CLI de Tanzu para crear siempre clústeres basados en clases en un solo paso. Para obtener más información, consulte Crear un clúster basado en clases.

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

• Windows CMD: Caracteres extraños en los encabezados de las columnas de resultados de CLI

  En la línea de comandos de Windows (CMD), los resultados del comando de la CLI de Tanzu con formato en columnas incluye caracteres extraños en los encabezados de las columnas.

  El problema no ocurre en Windows Terminal ni PowerShell.

  Solución alternativa: En máquina de arranque de Windows, ejecute la CLI de Tanzu desde Windows Terminal.

• Error de AKODeploymentConfig que se puede ignorar durante la creación del clúster de administración

  Al ejecutar tanzu management-cluster create para crear un clúster de administración con resultados de NSX ALB, se produce el siguiente error: no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???. Se puede ignorar el error. Para obtener más información, consulte este artículo en la base de conocimientos.

• Los errores machinehealthcheck y clusterresourceset que se pueden ignorar durante la creación del clúster de carga de trabajo en vSphere

  Cuando se implementa un clúster de carga de trabajo en vSphere mediante el comando tanzu cluster create a través de vSphere with Tanzu, el resultado puede incluir errores relacionados con la ejecución de machinehealthcheck y el acceso a los recursos clusterresourceset, como se muestra a continuación:

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

  El clúster de carga de trabajo se creó correctamente. Puede ignorar los errores.

• La CLI informa de forma errónea temporalmente del estado de los nodos eliminados recientemente cuando se desactivan los MHC

  Cuando las comprobaciones de estado de las máquinas (MHC) se desactivan, los comandos de la CLI de Tanzu, como tanzu cluster status, pueden no informar del estado actualizado del nodo mientras se vuelve a crear la infraestructura.

  Solución alternativa: Ninguna

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.

• Con NSX ALB, no se pueden crear clústeres con nombres idénticos

  Si utiliza NSX Advanced Load Balancer para cargas de trabajo (AVI_ENABLE) o el plano de control (AVI_CONTROL_PLANE_HA_PROVIDER), es posible que el controlador AVI no pueda distinguir entre clústeres con nombres idénticos.

  Solución alternativa: Establezca un valor CLUSTER_NAME único para cada clúster:

  • Clústeres de administración: No cree varios clústeres de administración con el mismo valor CLUSTER_NAME, ni siquiera desde máquinas de arranque diferentes.

  • Clústeres de carga de trabajo: No cree varios clústeres de carga de trabajo que tengan el mismo CLUSTER_NAME y que también estén en el mismo espacio de nombres del clúster de administración, tal y como establece su valor NAMESPACE.

• Para añadir la administración de identidades externa a una implementación existente, es posible que sea necesario establecer un valor VSPHERE_CONTROL_PLANE_ENDPOINT ficticio

  Para integrar un proveedor de identidad externo con una implementación de TKG existente, es posible que sea necesario establecer un valor VSPHERE_CONTROL_PLANE_ENDPOINT ficticio en el archivo de configuración del clúster de administración utilizado para crear el secreto del complemento, como se describe en Generar el secreto del complemento Pinniped para el clúster de administración

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.

Clústeres de carga de trabajo de varios sistemas operativos y Windows

• No se puede crear una imagen de máquina Windows en una máquina MacOS

  Debido a un problema con la utilidad packer de código abierto utilizada por Kubernetes Image Builder, no se puede crear una imagen de máquina Windows en una máquina MacOS como se describe en Imágenes de máquina personalizadas de Windows.

  Solución alternativa: Use una máquina Linux para crear sus imágenes de máquina personalizadas de Windows.

• No se admiten la copia de seguridad ni la restauración para los clústeres de carga de trabajo de varios sistemas operativos

  No se pueden realizar copias de seguridad ni restaurar clústeres de carga de trabajo con nodos de trabajo basados en Windows.

  Solución alternativa: Ninguna

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.