Contenido de las notas de la versión

Las notas de la versión abarcan los siguientes temas:

Novedades

Novedades del 25 de junio de 2024

VMware vSphere 8.0 Update 3 | 25 de junio de 2024 

vCenter Server 8.0 Update 3 | 25 de junio de 2024 | Compilación ISO 24022515

VMware ESXi 8.0 Update 3 | 25 de junio de 2024 | Compilación ISO 24022510

VMware NSX Advanced Load Balancer avi-22.1.5 | 11 de octubre de 2023

HAProxy 2.2.2 Community Edition, API del plano de datos 2.1.0

Tanzu Kubernetes Grid 3.0 | 25 de junio de 2024

Plano de control de vSphere IaaS 8.0 Update 3 incluye las siguientes funciones y mejoras nuevas:

  • Rotación automática de certificados de TKG y supervisor: esta versión proporciona un nuevo mecanismo de rotación de certificados. Los certificados del clúster de TKG y supervisor se rotan automáticamente antes de que caduquen. Si se produce un error en la rotación automática, recibirá una notificación en vCenter y tendrá que renovar los certificados manualmente.

  • Compatibilidad con el supervisor y el pod de vSphere , y con el clúster de TKG en el clúster de vSAN ampliado: a partir de esta versión, puede configurar el supervisor para que se ejecute en un clúster ampliado de vSAN. Esta configuración solo es posible en un entorno totalmente nuevo. Esto significa que el clúster de vSAN debe ampliarse y la administración de cargas de trabajo y la biblioteca de contenido aún no se han configurado. Estos dos componentes se tienen que configurar con las directivas de almacenamiento de clúster ampliado de vSAN. Consulte la documentación para obtener más información.

  • La clase de máquina virtual para las máquinas virtuales del servicio de máquina virtual ahora está en el ámbito del espacio de nombres: en esta versión, cuando se utiliza kubectl para enumerar las clases de máquina virtual, se pueden ver solo las clases de máquina virtual que están en el ámbito del espacio de nombres específico de vSphere. Antes, las clases de máquina virtual eran un recurso del ámbito del clúster y era difícil determinar qué clases de máquina virtual estaban asignadas y disponibles en un espacio de nombres específico.

  • Copia de seguridad y restauración del supervisor: la copia de seguridad y la restauración del supervisor ahora es compatible en vSphere. Ahora puede configurar copias de seguridad de un supervisor como parte de una copia de seguridad de vCenter y puede restaurar un supervisor a partir de una copia de seguridad en el caso de recuperación ante desastres, errores en la actualización, una interrupción y otros escenarios de recuperación. Consulte Copia de seguridad y restauración del plano de control del supervisor.

  • Copia de seguridad y restauración de máquinas virtuales del servicio de máquina virtual: la copia de seguridad y la restauración de las máquinas virtuales del servicio de máquina virtual ahora se pueden realizar en vSphere. Ahora puede utilizar cualquier proveedor de copia de seguridad basado en VADP para proteger las máquinas virtuales del servicio de máquina virtual. En el caso de una interrupción u otros escenarios que impliquen la pérdida de datos, puede restaurar las máquinas virtuales en el espacio de nombres de vSphere a partir de una copia de seguridad.

  • La API de VM Operator v1alpha2 ya está disponible: la siguiente versión de la API de operador de máquina virtual está disponible con la versión de VM Operator v1alpha2. Esta versión desbloquea la compatibilidad mejorada de los proveedores de arranque, incluida la compatibilidad en línea con Cloud-Init y Windows, la configuración mejorada de redes de invitado, las capacidades de estado aumentadas, la compatibilidad con puertas de preparación definidas por el usuario, la nueva API VirtualMachineWebConsoleRequest, la documentación mejorada de API y otras capacidades. 

  • Uso de Fluent Bit para el reenvío de registros en el supervisor: ahora está disponible la compatibilidad con el reenvío de registros del plano de control del supervisor y los registros de los sistemas a una plataforma de supervisión de registros externa. Consulte la documentación para obtener más información.

  • Compatibilidad del registro privado con los servicios del supervisor: ahora puede definir los detalles del registro privado que permitirá que las cargas de trabajo implementadas como servicio de supervisor extraigan imágenes y paquetes de un registro privado. Es un requisito común para poder admitir un entorno aislado. Para obtener más información, consulte la documentación.

  • Mejoras en el flujo de trabajo de actualización del supervisor: ahora puede iniciar comprobaciones previas de actualización del supervisor al iniciar una actualización de la versión de Kubernetes del supervisor. Solo cuando todas las comprobaciones previas se realizan correctamente, se realiza la actualización real. Esta versión incorpora la capacidad de reanudar el proceso de actualización de los componentes desde el punto en el que se había producido un error anterior. Para obtener más información, consulte Actualizar el supervisor.

  • Compatibilidad del supervisor para Kubernetes 1.28: esta versión agrega la compatibilidad del supervisor para Kubernetes 1.28 y descarta la compatibilidad con Kubernetes 1.25.

Versiones de Kubernetes compatibles para supervisores:

Las versiones compatibles de Kubernetes en esta versión son 1.28, 1.27 y 1.26. Los supervisores que se ejecutan en la versión 1.25 de Kubernetes se actualizarán automáticamente a la versión 1.26 para garantizar que todos los supervisores se ejecuten en las versiones compatibles de Kubernetes.

Tanzu Kubernetes Grid Service for vSphere

  • Servicio de TKG como servicio de supervisor: esta versión desacopla los componentes del servicio de TKG de vCenter y los empaqueta como un servicio de supervisor que se puede actualizar y administrar independientemente de las versiones de vCenter y supervisor. Puede encontrar las notas de la versión del servicio de TKG aquí.

  • Compatibilidad con la implementación de clústeres del servicio de TKG en clúster de vSAN ampliado: esta versión admite la implementación de clústeres del servicio de TKG en la topología de clúster ampliado de vSAN. Para obtener más información sobre cómo configurar HA para clústeres del servicio de TKG en el clúster ampliado de vSAN, consulte la documentación.

  • Escalado automático de clústeres del servicio de TKG: esta versión admite la instalación del paquete de escalador automático de clústeres en un clúster del servicio de TKG para habilitar el escalado horizontal y vertical automatizado de los nodos de trabajo. 

  • Copia de seguridad y restauración de los clústeres de TKG: esta versión admite la copia de seguridad y la restauración de la base de datos del supervisor, lo que incluiría un objeto de espacio de nombres de vSphere y máquinas virtuales del clúster de TKG. Tenga en cuenta que es necesario realizar una copia de seguridad y restauración de las cargas de trabajo del clúster de TKG por separado.

  • Compatibilidad con la integración de Antrea-NSX y el servicio de proxy de administración de NSX: esta versión admite la integración de clústeres de TKG mediante la CNI de Antrea con NSX Manager para la observación y el control de las redes del clúster.

  • MachineHealthCheck configurable: esta versión admite la configuración de MachineHealthCheck para clústeres de v1beta1.

  • Configuración de PSA en todo el clúster: esta versión admite la configuración de PSA en todo el clúster durante la creación o actualización del clúster.

  • Actualizaciones de instalación de paquetes estándar: esta versión incluye actualizaciones de documentación para instalar el paquete estándar en clústeres de servicio de TKG. 

  • Actualizaciones en la API v1beta1 para aprovisionar clústeres de TKG: esta versión incluye los siguientes cambios en la API v1beta1:

    • Se agregó podSecurityStandard para la implementación de PSA en todo el clúster

    • Se actualizó controlPlaneCertificateRotation 

  • Compatibilidad con el escalado de volúmenes de nodos del plano de control para un clúster de TKG.

Actualizaciones de internacionalización

A partir de la próxima versión principal, reduciremos el número de idiomas de localizados admitidos. Los tres idiomas admitidos serán:

  • Japonés

  • Español

  • Francés

Ya no se admitirán los siguientes idiomas:

  • Italiano, alemán, portugués de Brasil, chino tradicional, coreano, chino simplificado

Impacto:

  • Los usuarios que hayan utilizado esos idiomas descartados ya no recibirán actualizaciones ni asistencia en estos idiomas.

  • Todas las interfaces de usuario, la documentación de ayuda y la asistencia al cliente solo estarán disponibles en inglés o en los tres idiomas admitidos mencionados anteriormente.

Novedades del 26 de marzo de 2024

VMware vSphere 8.0 Update 2c | 26 de marzo de 2024 

ESXi 8.0 Update 2b | 29 de febrero de 2024 | Compilación ISO 23305546

vCenter Server 8.0 Update 2c | 26 de marzo de 2024 | Compilación ISO 23504390

VMware NSX Advanced Load Balancer avi-22.1.5 | 11 de octubre de 2023

HAProxy 2.2.2 Community Edition, API del plano de datos 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18 de mayo de 2023

El plano de control de vSphere IaaS 8.0 Update 2c presenta las siguientes funciones y mejoras nuevas:

Nuevas funciones

  • Compatibilidad con TKr 1.27: esta versión agrega los cambios necesarios para admitir TKr 1.27 en vSphere 8.x, cuando se publique más adelante. Para obtener más información, consulte las Notas de la versión de las versiones de VMware Tanzu Kubernetes.

  • Compatibilidad con la actualización de vCenter 7.x a vCenter 8.x: para los usuarios que ejecutan TKr 1.27.6 en vSphere 7.x, esta versión proporciona una ruta de actualización a vCenter 8.x. Anteriormente, el TKr 1.27.6 que se lanzó para vSphere 7.x no era compatible con vCenter 8.x. Consulte el artículo 96501 de la base de conocimientos.

Problemas resueltos

  • Después de actualizar a vCenter 8.0 Update 2b, es posible que el servicio wcp administrado por vmon esté en estado STOPPED y que se produzca un error en la aplicación de revisiones vCenter.

  • Al desvincular una biblioteca o eliminar un espacio de nombres con una biblioteca compartida, se eliminan los elementos asociados de la biblioteca de contenido.

Novedades del 29 de febrero de 2024

VMware vSphere 8.0 Update 2b | 29 de febrero de 2024 

ESXi 8.0 Update 2b | 29 de febrero de 2024 | Compilación ISO 23305546

vCenter Server 8.0 Update 2b | 29 de febrero de 2024 | Compilación ISO 23319993

VMware NSX Advanced Load Balancer avi-22.1.5 | 11 de octubre de 2023

HAProxy 2.2.2 Community Edition, API del plano de datos 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18 de mayo de 2023

El plano de control de vSphere IaaS 8.0 Update 2b presenta las siguientes funciones y mejoras nuevas:

Nuevas funciones

  • Compatibilidad con la configuración de las clases de máquina virtual del servicio de máquina virtual a través de vSphere Client: el servicio de máquina virtual en el supervisor admite la implementación de máquinas virtuales con cualquier configuración que sea compatible actualmente con las máquinas virtuales de vSphere. Para configurar la CPU, la memoria, el hardware, los dispositivos de seguridad y los dispositivos de acceso directo para las clases de máquina virtual, ahora puede utilizar el asistente de clase de máquina virtual de vSphere Client. Con vSphere Client, se simplifica el proceso de definición y administración de las máquinas virtuales del servicio de máquina virtual que se utiliza para ejecutar las cargas de trabajo de AI/ML.

  • Los supervisores admiten la configuración de nube de AVI: si utiliza NSX Advanced Load Balancer, también conocido como equilibrador de carga AVI, ahora puede configurar una nube de Avi para cada supervisor. Esto permite que varias instancias de vCenter Server y centros de datos utilicen una sola instancia de AVI, lo que elimina la necesidad de configurar una instancia de AVI para cada instancia de vCenter Server o centro de datos que implementa un supervisor.

  • Compatibilidad con el inicio de sesión con FQDN: para los clústeres de supervisor y TKG, ahora puede reemplazar la dirección IP en la instancia generada de kubeconfigs por un FQDN válido. El FQDN y la dirección IP deben agregarse al DNS para garantizar una resolución de nombre de host adecuada.

  • Los supervisores admiten Kubernetes 1.27: el supervisor ahora admite Kubernetes 1.27 e interrumpe la compatibilidad con Kubernetes 1.24.

Versiones de Kubernetes compatibles

  • Las versiones de Kubernetes compatibles en esta versión son 1.27, 1.26 y 1.25. Los supervisores que se ejecutan en Kubernetes 1.24 se actualizarán automáticamente a la versión 1.25 para garantizar la compatibilidad.

Actualizar a 8.0 Update 2b

La actualización de cualquier versión de vSphere 8.x inferior a la versión 8.0 Update 2 a la versión 8.0 Update 2b iniciará una actualización gradual de todos los clústeres de TKGS aprovisionados para propagar los siguientes cambios:

  • 8.0 Update 2 contiene cambios en los TKR de vSphere 7 y vSphere 8 en la controladora TKGS como parte de ClusterClass.

  • Como los clústeres de TKGS de la versión 1.23 y versiones posteriores son compatibles con 8.0 Update 2b, todos los clústeres de TKGS se someterán a una actualización gradual.

Problemas resueltos

  • El proceso de actualización del supervisor se bloquea en el 20 %.

Novedades del 21 de septiembre de 2023

VMware vSphere 8.0.2 | 21 de septiembre de 2023

ESXi 8.0.2 | 21 de septiembre de 2023 | Compilación 22380479

vCenter Server 8.0.2 | 21 de septiembre de 2023 | Compilación 22385739

VMware NSX Advanced Load Balancer avi-22.1.3 | 31 de enero de 2023

HAProxy Community Edition 2.2.2, API del plano de datos 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18 de mayo de 2023

El plano de control de vSphere IaaS 8.0 Update 2 presenta las siguientes funciones y mejoras nuevas:

Supervisor

  • El servicio de máquina virtual ahora es compatible con el sistema operativo Windows, GPU y todas las demás opciones disponibles para las máquinas virtuales de vSphere tradicionales: el servicio de máquina virtual ahora admite la implementación de máquinas virtuales con cualquier configuración compatible actualmente con máquinas virtuales de vSphere, logrando una paridad completa con las máquinas virtuales tradicionales en vSphere, pero para las máquinas virtuales implementadas como parte de la infraestructura como servicio en el supervisor. Esto incluye compatibilidad con el aprovisionamiento de máquinas virtuales Windows junto con máquinas virtuales Linux, así como cualquier soporte de hardware, seguridad, dispositivo, personalizado o de varias NIC y dispositivos de acceso directo que sean compatibles con vSphere. Ahora puede aprovisionar máquinas virtuales de carga de trabajo mediante GPU para admitir cargas de trabajo de AI/ML.

  • Servicio de imágenes de máquinas virtuales: los equipos de desarrollo y operaciones, los desarrolladores y otros consumidores de máquinas virtuales pueden publicar y administrar imágenes de máquinas virtuales en forma de autoservicio mediante el servicio de imágenes de máquinas virtuales. El servicio permite a los consumidores publicar, modificar y eliminar imágenes mediante las API de K8s dentro de un registro de imágenes en el ámbito del espacio de nombres de supervisor. El servicio de imágenes de máquinas virtuales se crea automáticamente en cada región y proyecto de CCS, y el ámbito de la población de imágenes en el registro de imágenes se realiza según el nivel de perfil y de consumo, ya sea a nivel global o de proyecto. Las imágenes se pueden utilizar para la implementación de máquinas virtuales a través del servicio de máquina virtual.

    Tenga en cuenta que esta funcionalidad presenta un nuevo formato para el nombre de la imagen de máquina virtual. Para obtener información sobre cómo resolver posibles problemas causados por el cambio de nombre, consulte Cambios en el formato del nombre de imagen de máquina virtual en vSphere 8.0 U2.

  • Importar y exportar la configuración del supervisor: en versiones anteriores, la activación del supervisor era un proceso manual paso a paso que no permitía guardar las configuraciones. En la versión actual, ahora puede exportar y compartir la configuración del supervisor con compañeros en un formato legible o dentro de un sistema de control de origen, importar configuraciones en un nuevo supervisor y replicar una configuración estándar en varios supervisores. Revise la documentación para obtener detalles sobre cómo exportar e importar la configuración de supervisor.

  • Uso de GPU mejorado gracias a la reducción de la fragmentación: la colocación de cargas de trabajo ahora reconoce la GPU y DRS intentará colocar cargas de trabajo con requisitos de perfil similares en el mismo host. Esto mejora el uso de recursos, lo que reduce el coste, ya que se deben adquirir menos recursos de hardware de GPU para alcanzar el nivel de rendimiento deseado.

  • Supervisor admite Kubernetes 1.26: esta versión agrega la compatibilidad con Kubernetes 1.26 y descarta la compatibilidad con Kubernetes 1.23. Las versiones compatibles de Kubernetes en esta versión son 1.26, 1.25 y 1.24. Los supervisores que se ejecutan en Kubernetes versión 1.23 se actualizarán automáticamente a la versión 1.24 para garantizar que todos los supervisores se ejecuten en las versiones compatibles de Kubernetes.

  • Compatibilidad de NSX Advanced Load Balancer con un supervisor configurado con redes NSX: ahora puede habilitar un supervisor con NSX Advanced Load Balancer (Avi Networks) para el equilibrio de carga de capa 4, así como el equilibrio de carga para los nodos del plano de control de los clústeres supervisores y de Tanzu Kubernetes Grid con redes NSX. Revise la página de documentación para ver indicaciones sobre cómo configurar NSX Advanced Load Balancer con NSX.

  • Compatibilidad de Telegraf con la transmisión de métricas y eventos: ahora puede configurar Telegraf a través de las API de Kubernetes para insertar métricas de supervisor en cualquier servicio de métricas que sea compatible con la versión de Telegraf integrada. Consulte la documentación para configurar Telegraf.

Problemas conocidos de Tanzu Kubernetes Grid en el supervisor

  • Cumplimiento de STIG para TKR en vSphere 8.0: con vSphere U2, todos los clústeres de Tanzu Kubernetes Grid superiores a la versión 1.23.x cumplen con STIG (guía de implementación técnica de la seguridad) e incluyen documentación para las excepciones, que puede encontrar aquí. Estas mejoras representan un paso importante hacia la simplificación del proceso de conformidad y facilitan mucho más el cumplimiento de los requisitos de conformidad para que pueda utilizar de forma rápida y segura Tanzu Kubernetes Grid en el mercado federal de EE. UU. y en otros sectores regulados.

  • Activar la implementación del plano de control para los certificados que están a punto de caducar: la API v1beta1 para aprovisionar clústeres de TKG basados en una ClusterClass se actualiza para permitir que los clústeres renueven automáticamente sus certificados de máquina virtual del nodo de plano de control antes de que caduquen. Esta configuración se puede agregar como una variable a la especificación del clúster. Refiérase a la pestaña

    documentación de la API de clúster v1beta1 si desea obtener más información.

  • Compatibilidad con instantáneas de CSI para las TKR: los clústeres de TKG aprovisionados con Tanzu Kubernetes versión 1.26.5 y versiones posteriores admiten instantáneas de volumen CSI, lo que ayuda a cumplir los requisitos de protección de datos. Las instantáneas de volumen proporcionan una forma estandarizada de copiar el contenido de un volumen en un momento específico sin crear un volumen completamente nuevo. 

  • Instalar y administrar paquetes de Tanzu: un nuevo repositorio consolidado y la publicación para instalar y administrar paquetes de Tanzu en clústeres de TKG. Consulte la publicación "Instalar y usar paquetes de VMware Tanzu" para conocer todas las necesidades de paquetes que tiene.

  • Mejoras de ClusterClass personalizada: el flujo de trabajo para implementar clústeres de ClusterClass personalizada se simplifica para vSphere 8 U2.

  • Actualizaciones graduales para clústeres de TKG: cuando vaya a actualizar a vSphere 8 U2, puede esperar actualizaciones graduales para los clústeres de TKG aprovisionados en los siguientes escenarios:

    • Al actualizar desde cualquier versión de vSphere 8 publicada anteriormente a vSphere 8 U2, debido a lo siguiente:

      • vSphere 8 U2 contiene cambios de STIG a nivel de Kubernetes para las TKR como parte de la clusClusterClass

      • Los clústeres de TKG de la versión 1.23 y versiones posteriores se someterán a una actualización gradual para que sean compatibles con v8.0 U2

    • Al actualizar desde cualquier versión de vSphere 7 a vSphere 8 U2, debido a lo siguiente:

      • Los proveedores de CAPI subyacentes deben moverse de CAPW a CAPV

      • Los clústeres existentes se deben migrar desde clústeres de CAPI sin clase a clústeres de CAPI basados en clases

Problemas resueltos

  • Los archivos de registro de auditoría en /var/log/audit/ en las máquinas virtuales del plano de control del supervisor pueden alcanzar un tamaño muy grande y llenar el disco raíz. Debería ver errores "no hay más espacio en el dispositivo" en los registros de journald que reflejan este estado. Esto puede provocar errores en varios aspectos de la funcionalidad del plano de control del supervisor (como las API de Kubernetes).

Novedades del 7 de julio de 2023

VMware vSphere 8.0.1c | 27 de julio de 2023

ESXi 8.0.1c | 27 de julio de 2023 | Compilación 22088125

vCenter Server 8.0.1c | 27 de julio de 2023 | Compilación 22088981

VMware NSX Advanced Load Balancer avi-22.1.3 | 31 de enero de 2023

HAProxy Community Edition 2.2.2, API del plano de datos 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18 de mayo de 2023

Nuevas funciones

  • Los supervisores admiten Kubernetes 1.25: esta versión agrega la compatibilidad para Kubernetes 1.25 y descarta la compatibilidad con Kubernetes 1.22.

  • Tanzu Kubernetes Grid 2.2.0 en Supervisor: administre clústeres de Tanzu Kubernetes Grid 2.2.0 en el supervisor.

Versiones de Kubernetes compatibles

  • Las versiones compatibles de Kubernetes en esta versión son 1.25, 1.24 y 1.23. Los supervisores que se ejecutan en Kubernetes versión 1.22 se actualizarán automáticamente a la versión 1.23 para garantizar que todos los supervisores se ejecuten en las versiones compatibles de Kubernetes.

Soporte

  • Desuso de la creación de vRegistry: la creación de una instancia de Harbor integrada, vRegistry, ha caído en desuso. Las instancias de vRegistry existentes seguirán funcionando, pero la creación de nuevas instancias de vRegistry cae en desuso. Las API de creación de vRegistry se marcaron como obsoletas y la capacidad para implementar nuevas instancias de vRegistry se eliminará en una próxima versión. En su lugar, se recomienda utilizar Harbor como servicio de supervisor para administrar los repositorios y las imágenes de contenedor a fin de mejorar el rendimiento y la funcionalidad. Para migrar vRegistry existente a Harbor como servicio de supervisor, consulte "Migrar imágenes del registro integrado a Harbor" para obtener más información sobre la migración.

Problemas resueltos

  • Se mostrará un nuevo mensaje de alerta en vSphere Client para advertir sobre el certificado a punto de caducar en los clústeres de supervisor o TKG. La alerta proporcionará información detallada, incluido el nombre del supervisor y la fecha de caducidad del certificado. Además, contendrá un vínculo a KB 90627 que explica paso a paso cómo reemplazar los certificados afectados.

  • El comando kubectl get clustervirtualmachineimages devuelve un error o No resources found. En versiones anteriores, cuando se utilizaba el comando kubectl get clustervirtualmachineimages, se encontraba un error. Sin embargo, después de actualizar a 8.0 Update 1c, el comando ahora devuelve el mensaje: No resources found. Para recuperar información sobre las imágenes de máquinas virtuales, utilice el siguiente comando en su lugar: kubectl get virtualmachineimages

  • La CNI con enrutamiento antrea-nsx no funciona con clústeres de Tanzu Kubernetes v1alpha3 en las versiones 8.x del plano de control de vSphere IaaS.

  • El tiempo de espera de purga de nodos no se propaga correctamente para los clústeres de v1beta1.

Novedades del 18 de abril de 2023

VMware vSphere 8.0.1 | 18 de abril de 2023

ESXi 8.0.1 | 18 de abril de 2023 | Compilación 21495797

vCenter Server 8.0.1 | 18 de abril de 2023 | Compilación 21560480

VMware NSX Advanced Load Balancer avi-22.1.3 | 31 de enero de 2023

HAProxy Community Edition 2.2.2, API del plano de datos 2.1.0

Tanzu Kubernetes Grid 2.0 | 11 de octubre de 2022

Nuevas funciones

Supervisor

  • Los servicios de supervisor ahora están disponibles en los supervisores basados en VDS: anteriormente, la disponibilidad de los servicios de supervisor estaba restringida solo a los supervisores basados en NSX. Con la versión actual, puede implementar servicios de supervisor de Velero, Harbor, Contour, almacenamiento de objetos de S3 en supervisores basados en VDS. Nota: Las capacidades del servicio de supervisor en los supervisores basados en VDS requieren una actualización ESXi a la versión 8.0 U1.

  • Compatibilidad con el servicio de máquina virtual para todas las imágenes de Linux: ahora puede utilizar CloudInit para personalizar cualquier imagen de Linux en formato OVF conforme a la especificación de la imagen del servicio de VM así como utilizar la plantilla de OVF a través de vAppConfig para habilitar la implementación de imágenes de Linux heredadas.

  • Compatibilidad de Web-Console con máquinas virtuales de servicio de máquina virtual: después de implementar una máquina virtual de servicio de máquina virtual, como ingeniero de desarrollo y operaciones, ahora tendrá la capacidad de iniciar una sesión de Web consola para esa máquina virtual mediante la CLI de kubectl para habilitar la solución de problemas y la depuración en el sistema operativo invitado sin involucrar al administrador vSphere obtener acceso a la máquina virtual invitada.

  • Conformidad de supervisor: guías de implementación técnica de seguridad (STIG) para las versiones de supervisor del plano de control de vSphere IaaS 8. Consulte Fortalecimiento de STIG de Tanzu para obtener más información.

Problemas conocidos de Tanzu Kubernetes Grid 2.0 en el supervisor

  • Clase de clúster personalizada: incorpore su propia clase de clúster para los clústeres de TKG en el supervisor. Para obtener información, consulte https://kb.vmware.com/s/article/91826.

  • Imagen personalizada para el nodo de TKG: cree sus propias imágenes de nodo personalizadas mediante vSphere TKG Image Builder (Ubuntu y Photon).

    Nota: Para utilizar una TKR específica con la API v1alpha1, utilice fullVersion.

  • Nuevas imágenes de TKR: Consulte las notas de la versión de Tanzu Kubernetes para obtener más información.

REQUISITO CRÍTICO para los clientes del plano de control de vSphere IaaS 8.0.0 GA

Nota: Este requisito no se aplica a las bibliotecas de contenido que se utilizan para las máquinas virtuales aprovisionadas a través del servicio de máquina virtual. Solo se aplica a la biblioteca de contenido de TKR.

Si implementó el plano de control de vSphere IaaS 8.0.0 GA, antes de actualizar al plano de control de vSphere IaaS 8 U1, debe crear una biblioteca de contenido de TKR temporal para evitar un problema conocido que provoca que los pods de la controladora de TKG entren en CrashLoopBackoff cuando se insertan los TKR de TKG 2.0 en la biblioteca de contenido existente. Para solucionar este problema, siga estos pasos.

  1. Cree una nueva biblioteca de contenido suscrita con una URL de suscripción temporal que apunte a https://wp-content.vmware.com/v2/8.0.0/lib.json.

  2. Sincronice todos los elementos de la biblioteca de contenido temporal.

  3. Asocie la biblioteca de contenido temporal con cada espacio de nombres de vSphere en el que implementó un clúster de TKG 2.

  4. Ejecute el comando kubectl get tkr y compruebe que se crearon todos los TKr.

  5. En este punto, el controlador de TKG debe estar en estado de ejecución, que puede comprobar enumerando los pods en el espacio de nombres del supervisor.

  6. Si la controladora de TKG está en estado CrashLoopBackOff (CLBO), reinicie su implementación mediante el siguiente comando:

    kubectl rollout restart deployment -n vmware-system-tkg vmware-system-tkg-controller-manager

  7. Actualice al plano de control de vSphere IaaS 8 Update 1.

  8. Actualice cada espacio de nombres de vSphere para utilizar la biblioteca de contenido suscrita original en https://wp-content.vmware.com/v2/latest/lib.json.

Problemas resueltos

  • Los clústeres de Tanzu Kubernetes Grid 2.0 aprovisionados con la API v1beta1 deben basarse en la ClusterClass predeterminada

    Si va a crear un clúster de Tanzu Kubernetes Grid 2.0 en Supervisor mediante la API v1beta1, el clúster debe basarse en la ClusterClass tanzukubernetescluster predeterminada. El sistema no compatibiliza un clúster basado en una ClusterClass diferente.

Novedades del 30 de marzo de 2023

ESXi 8.0.0c | 30 de marzo de 2023 | Compilación 21493926

vCenter Server 8.0.0c | 30 de marzo de 2023 | Compilación 21457384

VMware NSX Advanced Load Balancer avi-22.1.3 | 31 de enero de 2023

HAProxy 2.2.2 Community Edition, API del plano de datos 2.1.0

Tanzu Kubernetes Grid 2.0 | 11 de octubre de 2022

Problemas resueltos:

  • Problema de configuración predeterminada no segura de Harbor

    En esta versión se resuelve el problema de configuración predeterminada no segura de Harbor que está presente si se habilitó el registro de Harbor integrado en Supervisor 7.0 u 8.0.

    Resuelto en esta la versión de vCenter 8.0.0c. Artículo 91452 de la base de conocimientos de VMware para obtener detalles sobre este problema y cómo solucionarlo mediante la instalación de esta versión o aplicando una solución alternativa temporal.

  • Después de actualizar a vCenter Server 8.0b, se produce un error al intentar iniciar sesión en un supervisor y clústeres de TKG

    Los componentes que se ejecutan en vCenter Server 8.0b no son compatibles con versiones anteriores de los supervisores implementados mediante vCenter Server en versiones anteriores.

    Solución alternativa: Actualice vCenter Server a una versión más reciente o actualice todos los supervisores implementados.

Novedades del 14 de febrero de 2023

ESXi 8.0.0b | 14 de febrero de 2023 | Compilación 21203435

vCenter Server 8.0.0b | 14 de febrero de 2023 | Compilación 21216066

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 15 de julio de 2022

HAProxy 2.2.2 Community Edition, API del plano de datos 2.1.0

Tanzu Kubernetes Grid 2.0 | 11 de octubre de 2022

Nuevas funciones:

  • Se agregó compatibilidad con emisores de clústeres de CA de Cert-Manager: proporciona a los administradores la capacidad de definir e implementar un emisor de CA en el ámbito del clúster en un supervisor como servicio de supervisor. La implementación de un emisor de CA con ámbito de clúster permite a los consumidores del espacio de nombres de supervisor solicitar y administrar certificados firmados por el emisor de CA. 

Además de esta nueva función, la versión proporciona correcciones de errores.

Problemas resueltos:

  • El disco raíz de las máquinas virtuales del plano de control de supervisor se llena

    Los archivos de registro de auditoría en /var/log/audit/ en las máquinas virtuales del plano de control del supervisor pueden alcanzar un tamaño muy grande y llenar el disco raíz. Debería ver errores "no hay más espacio en el dispositivo" en los registros de journald que reflejan este estado. Esto puede provocar errores en varios aspectos de la funcionalidad del plano de control del supervisor (como las API de Kubernetes).

    Resuelto en esta versión: vSphere 8.0.0b

Novedades del 15 de noviembre de 2022

ESXi 8.0 | 11 de octubre de 2022 | Compilación 20513097

vCenter Server 8.0.0a | 15 de diciembre de 2022 | Compilación 20920323

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 15 de julio de 2022

HAProxy 2.2.2 Community Edition, API del plano de datos 2.1.0

Tanzu Kubernetes Grid 2.0 | 11 de octubre de 2022

Nuevas funciones

  • Se agregó Harbor como servicio de supervisor: proporciona una instancia completa de Harbor (registro de imágenes OCI) que se ejecuta en el supervisor. La instancia de Harbor permite a los administradores de Harbor crear y administrar proyectos y usuarios, así como configurar la exploración de imágenes.

  • Desuso de vRegistry: la instancia de Harbor integrada conocida como vRegistry se eliminará en una versión futura. En su lugar, puede utilizar Harbor como servicio de supervisor. Consulte "Migrar imágenes del registro integrado a Harbor" para obtener más información sobre la migración.

  • Los supervisores admiten Kubernetes 1.24: esta versión agrega compatibilidad con Kubernetes 1.24 y descarta la compatibilidad con Kubernetes 1.21. Las versiones compatibles de Kubernetes en esta versión son 1.24, 1.23 y 1.22. Los clústeres supervisores que se ejecutan en Kubernetes versión 1.21 se actualizarán automáticamente a la versión 1.22 para garantizar que todos los clústeres supervisores se ejecuten en las versiones compatibles de Kubernetes.

  • API de zona de vSphere: una zona de vSphere es una construcción que permite asignar zonas de disponibilidad a clústeres de vSphere para que los clústeres supervisores y de Tanzu Kubernetes estén altamente disponibles. En vSphere 8.0, la funcionalidad Crear y administrar zona de vSphere estaba disponible en vSphere Client. Con la versión vSphere 8.0.0a, los usuarios pueden crear y administrar zonas de vSphere mediante DCLI o el explorador de API de vSphere Client. La compatibilidad completa con el enlace de SDK (por ejemplo, Java, Python, etc.) estará disponible en una versión futura.

Consideraciones sobre la actualización:

  • Se producirá una actualización de inscripción de clústeres de Tanzu Kubernetes en los siguientes escenarios de actualización de supervisor:

    • Cuando se actualiza de la versión 8.0 a la 8.0.0a seguida de la actualización de un supervisor de cualquier versión de Kubernetes al supervisor Kubernetes 1.24 y cuando se cumple una de estas condiciones.

      • Si utiliza la configuración de proxy con una lista nonempty noProxy en un clúster de Tanzu Kubernetes

      • Si vRegistry está habilitado en el supervisor. Esta configuración solo está disponible en supervisores basados en NSX.

    • Al actualizar de cualquier versión de vSphere 7.0 a vSphere 8.0.0a.

Problemas resueltos:

  • Las claves de licencia de Tanzu 7 se admiten en vSphere 8, a diferencia de las claves de licencia de Tanzu 8

    vCenter 8.0 admite las claves de licencia de Tanzu 7 en lugar de las claves de licencia de Tanzu 8. Este defecto no afecta a la capacidad para utilizar completamente las funciones de Tanzu en vCenter 8.0. Para obtener más detalles, consulte el artículo 89839 de la base de conocimientos de VMware antes de modificar las licencias de Tanzu en su implementación de vCenter 8.0.

  • Los equilibradores de carga y los clústeres invitados no se crean cuando existen dos grupos de motores de servicio (SE, Service Engine) en NSX-ALB.

    Si se agrega un segundo grupo de motores de servicio a NSX-ALB con o sin motores de servicio o servicios virtuales asignados a él, se produce un error en la creación de los nuevos clústeres invitados o supervisores, y no se pueden actualizar los clústeres supervisores existentes. Se produce el siguiente error al crear el servicio virtual en el controlador de NSX-ALB:

    get() returned more than one ServiceEngineGroup – it returned 2

    Como resultado, los equilibradores de carga nuevos no se pueden utilizar y no se pueden crear correctamente nuevos clústeres de carga de trabajo. Para obtener más información, consulte el artículo 90386 de la base de conocimientos de VMware.

Novedades (11 de octubre de 2022)

VMware vSphere 8.0 | 11 de octubre de 2022

ESXi 8.0 | 11 de octubre de 2022 | Compilación 20513097

vCenter 8.0 | 11 de octubre de 2022 | Compilación 20519528

VMware NSX Advanced Load Balancer 21.1.4 | 7 de abril de 2022

HAProxy 2.2.2 Community Edition, API del plano de datos 2.1.0

Tanzu Kubernetes Grid 2.0 | 11 de octubre de 2022

El plano de control de vSphere IaaS 8.0 incluye las siguientes funciones y mejoras nuevas:

  • Supervisión de la configuración de administración de cargas de trabajo: ahora puede realizar un seguimiento más detallado del estado de activación, desactivación y actualización del supervisor. Una vez que se inicia una activación, una desactivación o una actualización del supervisor, este intenta alcanzar el estado deseado. Para ello, intenta alcanzar diversas condiciones asociadas con distintos componentes del supervisor, como las máquinas virtuales del plano de control. Puede realizar un seguimiento del estado de cada condición, ver las advertencias asociadas, volver a intentar el estado, ver las condiciones que se alcanzaron y sus marcas de tiempo.

  • Zonas de vSphere: una zona de vSphere es una nueva construcción que permite asignar zonas de disponibilidad a los clústeres de vSphere. La implementación de un supervisor en zonas de vSphere permite aprovisionar clústeres de Tanzu Kubernetes Grid en zonas de disponibilidad y dominios de errores específicos. Esto permite que las cargas de trabajo abarquen varios clústeres, lo que aumenta la resiliencia ante errores de hardware y software.

  • Supervisor de varios clústeres: al utilizar zonas de vSphere, puede implementar un supervisor en varios clústeres de vSphere para proporcionar dominios de alta disponibilidad y errores para los clústeres de Tanzu Kubernetes Grid. Puede agregar un clúster de vSphere a una zona de vSphere independiente y activar un supervisor que abarque varias zonas vSphere. Esto proporciona una conmutación por error y resistencia a errores localizados de hardware y software. Cuando una zona o un clúster de vSphere se desconectan, el supervisor detecta el error y reinicia las cargas de trabajo en otra zona de vSphere. Puede utilizar zonas de vSphere en entornos que abarquen distancias siempre que no se superen los valores máximos de latencia. Para obtener más información sobre los requisitos de latencia, consulte Requisitos para la implementación del supervisor zonal.

  • El supervisor admite Kubernetes 1.23: esta versión agrega compatibilidad para Kubernetes 1.23 y descarta la compatibilidad con Kubernetes 1.20. Las versiones compatibles de Kubernetes en esta versión son 1.23, 1.22 y 1.21. Los supervisores que se ejecutan en Kubernetes versión 1.20 se actualizarán automáticamente a la versión 1.21 para garantizar que todos los supervisores se ejecuten en las versiones compatibles de Kubernetes.

  • Proporcionar directivas de red coherentes con las CRD de SecurityPolicy: la definición de recursos personalizados de SecurityPolicy proporciona la capacidad de configurar controles de seguridad de red para máquinas virtuales y pods de vSphere en un espacio de nombres de supervisor.

  • Tanzu Kubernetes Grid 2.0: Tanzu Kubernetes Grid ahora ha pasado a la versión 2.0. Tanzu Kubernetes Grid 2.0 es la culminación de una enorme innovación en la comunidad de Tanzu y Kubernetes, y proporciona la base para un conjunto común de interfaces a través de nubes privadas y públicas con Tanzu Kubernetes Grid. Las novedades de esta versión son estas dos funciones principales:

    • ClusterClass: Tanzu Kubernetes Grid 2.0 ahora es compatible con ClusterClass. ClusterClass proporciona una interfaz alineada con el flujo ascendente, sustituyendo al clúster de Tanzu Kubernetes, lo cual aporta capacidades de personalización a nuestra plataforma Tanzu Kubernetes Grid. ClusterClass permite a los administradores definir plantillas que funcionen con los requisitos de su entorno empresarial, al tiempo que reduce las reutilizaciones y habilita la personalización delegada.

    • Carvel: Carvel proporciona un conjunto de herramientas de composición confiables de un solo propósito que ayudan en la creación, la configuración y la implementación de aplicaciones en Kubernetes. En concreto, kapp y kapp-controller proporcionan compatibilidad, ciclo de vida y administración de paquetes a través de un conjunto de herramientas declarativas alineadas con el flujo ascendente. Junto con YTT para plantillas, esto da como resultado una capacidad de administración de paquetes flexible y administrable.

  • Nueva estructura de documentación y página de destino en vSphere 8: la documentación del plano de control de vSphere IaaS tiene ahora una nueva estructura mejorada que refleja mejor los flujos de trabajo usados con el producto y le permite tener una experiencia más centrada en el contenido. También puede acceder a toda la documentación técnica disponible para el plano de control de vSphere IaaS desde la nueva página de destino de documentación.


Instalación y actualizaciones de esta versión

Lea la documentación de Instalar y configurar el plano de control de vSphere IaaS para obtener instrucciones sobre cómo instalar y configurar el plano de control de vSphere IaaS. Para obtener información sobre cómo actualizar el plano de control de vSphere IaaS, consulte la documentación de Actualizar el plano de control de vSphere IaaS.

Al realizar las actualizaciones, tenga en cuenta lo siguiente:

  • Antes de actualizar a vCenter Server 8.0, asegúrese de que la versión de Kubernetes de todos los supervisores sea la 1.21 como mínimo y, a ser posible, la versión compatible más reciente. La versión de Tanzu Kubernetes de los clústeres de Tanzu Kubernetes Grid debe ser al menos la 1.21 y preferiblemente la versión compatible más reciente.

  • A partir del plano de control de vSphere IaaS 8.0 MP1, se permiten actualizaciones de TKGS TKr heredado a TKGS 2 TKr. Consulte las Notas de la versión de las versiones de Tanzu Kubernetes para ver la matriz de versiones compatibles. Consulte la documentación de Usar TKG en el supervisor con el plano de control de vSphere IaaS para obtener información sobre la actualización.

Problemas conocidos

Problemas conocidos del supervisor

  • En vSphere 8.0 Update 3, las opciones de anulación de red ya no están presentes en la página de creación de espacios de nombres de vSphere

    Antes de la versión 8.0 Update 3, un administrador de vSphere podía proporcionar la configuración de red personalizada en lugar de la configuración de red predeterminada que se utilizaba al crear un espacio de nombres de vSphere. En la versión 8.0 Update 3, la opción de interfaz de usuario para anular la configuración de red no está disponible.

    Solución alternativa: Puede utilizar la DCLI para crear el espacio de nombres de vSphere con una configuración de red personalizada.

  • En ocasiones, es posible que los hosts ESXi no puedan unirse a un clúster supervisor debido a que no se puede cargar el módulo vds-vsip

    Cuando los hosts ESXi no pueden unirse al clúster supervisor, puede ver el siguiente error en el archivo de registro de los hosts ESXi /var/run/log/spherelet.log:

    cannot load module vds-vsip: cmd '/bin/vmkload_mod /usr/lib/vmware/vmkmod/vds-vsip' failed with status 1: stderr: '', stdout:'vmkmod: VMKModLoad: VMKernel_LoadKernelModule(vds-vsip): Failure\nCannot load module /usr/lib/vmware/vmkmod/vds-vsip: Failure\n'

    Este problema puede producirse durante una actualización del clúster supervisor, una actualización del certificado o cualquier otro cambio en la configuración del supervisor que reinicie spherelet.

    Solución alternativa: Reinicie los hosts ESXi que no pueden cargar el módulo vds-vsip.

  • Se produce un error al intentar actualizar el entorno del plano de control de IaaS de vSphere de la versión 7.0 Update 3o a la versión 8.0 Update 3 con un supervisor que utiliza máquinas virtuales de plano de control de tamaño Muy pequeño

    Después de actualizar vCenter desde la versión 7.0 Update 3o a la versión 8.0 Update 3, el supervisor configurado con máquinas virtuales del plano de control de tamaño Muy pequeño no puede actualizarse desde Kubernetes v1.26.8 a 1.27.5.

    Se pueden observar los siguientes errores: Waiting for deployment \"snapshot-validation-deployment\" rollout to finish: 2 out of 3 new replicas have been updated...'kubectl get pods' in namespaces starting with the name 'vmware-system-' show pods in OutOfCpu state.

    Solución alternativa: Antes de la actualización, escale verticalmente el tamaño de las máquinas virtuales del plano de control de Muy pequeño a Pequeño o superior. Consulte Cambiar el tamaño del plano de control de un supervisor.

  • Después de actualizar vCenter y el entorno del plano de control de IaaS de vSphere a vSphere 8.0 U3, se produce un error al intentar crear pods de vSphere si el supervisor utiliza la versión 1.26 de Kubernetes

    Después de actualizar el entorno a vSphere 8.0 U3 y actualizar el supervisor a la versión 1.26 de Kubernetes, se produce un error en las operaciones de creación de pods de vSphere mientras el sistema intenta extraer la imagen. Puede observar el error failed to configure device eth0 with dhcp: getDHCPNetConf failed for interface incluso si el clúster está habilitado con la red estática.

    Solución alternativa: Actualice el plano de control de IaaS de vSphere y el supervisor a la versión 1.27 o posterior de Kubernetes.

  • En ocasiones, cuando se intenta eliminar simultáneamente una instantánea de volumen y realizar una operación de restauración de PVC, las operaciones no se completan debido a dependencias internas

    Los problemas pueden producirse en las siguientes circunstancias. Se inicia una operación de restauración para una instantánea de volumen y la operación de restauración tarda más tiempo de lo habitual en completarse o se vuelve a intentar debido a diferentes motivos internos. Mientras tanto, se activa la eliminación de la instantánea de origen. Como resultado, ambas operaciones entran en conflicto y se quedan incompletas. La eliminación de instantáneas sigue fallando debido a la operación de restauración en curso de esta instantánea, mientras que la operación de restauración comienza a fallar porque se activó la eliminación de la instantánea.

    Solución alternativa: Para solucionar este problema, debe eliminar la PVC restaurada para detener la operación de restauración y dejar que continúe la eliminación de la instantánea. En este caso, los datos de la instantánea se perderán y no se podrán restaurar porque la instantánea se elimina después de eliminar la PVC restaurada.

  • Las máquinas virtuales de servicio de máquina virtual no pueden utilizar las PVC en las que el parámetro volumeBindingMode en la clase de almacenamiento está establecido en WaitForFirstConsumer

    Cuando se utiliza este tipo de PVC para máquinas virtuales de servicio de máquina virtual, se producen errores y comportamientos impredecibles. Por ejemplo, puede observar el error Waiting for first consumer to be created before binding.

    Solución alternativa: Las máquinas virtuales del servicio de máquina virtual admiten PVC con volumeBidingMode inmediato en la clase de almacenamiento, pero no admiten WaitForFirstConsumer.

  • Un nuevo modelo de licencia cambia el comportamiento de NSX Container Plugin (NCP) en el entorno del plano de control de IaaS de VMware vSphere

    En la versión 8.0 Update 3, la licencia de NSX Distributed Firewall (DFW) se ofrece como una licencia complementaria independiente. Sin esta licencia, NCP en el entorno del plano de control de IaaS de VMware vSphere ajustará las reglas de DFW en NSX, lo que provocará un comportamiento impredecible.

    Por ejemplo, sin la licencia de DFW, las directivas de red y seguridad nuevas que se crean para el plano de control de IaaS de VMware vSphere no funcionan, ya que NCP no puede agregar reglas en NSX Manager. Asimismo, se puede acceder a recursos como los pods en un espacio de nombres recién creado desde otro espacio de nombres. En cambio, con la licencia de DFW, no se debe poder acceder a un espacio de nombres recién creado desde otro espacio de nombres de forma predeterminada.

    Solución alternativa: La licencia de NSX Distributed Firewall (DFW) se ofrece como una licencia complementaria independiente en NSX Manager. Para evitar problemas, agregue la licencia a NSX Manager.

  • Velero vSphere Operator se instala correctamente, pero es posible que se produzca un error al intentar crear una instancia de Velero

    Velero vSphere Operator implementa sus pods de operador en las máquinas virtuales del plano de control, mientras que las instancias de Velero se implementan como pods de vSphere.

    El problema de implementación puede producirse cuando vCenter se actualiza a 8.x y el supervisor utiliza redes VDS. Sin embargo, los hosts ESXi para ese supervisor no se actualizaron y utilizan una versión asincrónica anterior a la versión 8.x. En este escenario, los hosts ESXi no pueden implementar pods de vSphere. Como resultado, mientras Velero vSphere Operator se instala correctamente, no se puede crear una instancia de Velero cuando el administrador intenta utilizarlo.

    Solución alternativa: Para asegurarse de que el servicio de supervisor de Velero funciona correctamente, primero debe actualizar ESXi a la versión 8.x y, a continuación, debe actualizar vCenter y el supervisor a la misma versión 8.x.

  • El pod de operador de máquina virtual se bloquea por tener recursos insuficientes a escala

    Si los recursos de VirtualMachine tardan mucho en hacerse efectivos cuando están a escala, por ejemplo, miles de máquinas virtuales, es posible que el pod del operador de máquina virtual se bloquee porque la memoria sea insuficiente.

    Solución alternativa: Para obtener la solución alternativa y más información, consulte el artículo 88442 de la base de conocimientos.

  • Después de actualizar a vCenter 8.0 Update 2b, es posible que el servicio wcp administrado por vmon esté en estado STOPPED y que se produzca un error en la aplicación de revisiones de vCenter

    Este problema solo se produce cuando se actualiza vCenter 8.0 Update 1 o posterior a vCenter 8.0 Update 2b y tiene al menos un supervisor que utiliza la topología de redes de VDS y que está en Kubernetes 1.24.

    Solución alternativa: Para evitar este problema, actualice el supervisor a Kubernetes 1.25 o una versión posterior antes de actualizar vCenter a la versión 8.0 Update 2b. Para obtener más información, póngase en contacto con el soporte al cliente.

  • Se produce un error en las operaciones del supervisor cuando el tamaño de los certificados de vCenter personalizados es superior a 8 K

    En vSphere 8.0 Update 2b, el tamaño máximo de clave de una CSR en un sistema vCenter se reduce a 8192 bits desde 16384 bits. Cuando el tamaño de clave de su certificado es superior a 8192 bits, es posible que observe un comportamiento impredecible de las operaciones de supervisor. Por ejemplo, se pueden producir errores en operaciones como la habilitación o la actualización del supervisor.

    Solución alternativa:

    Vuelva a generar cualquier certificado de vCenter que tenga un tamaño de clave superior a 8192 bits.

    1. Identifique los certificados que tengan un tamaño de clave superior a 8192 bits.

      for store in TRUSTED_ROOTS MACHINE_SSL_CERT vpxd-extension wcp ; do echo $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store "$store" --text | grep Public-Key; done

    2. Reemplace los certificados cuyo tamaño de clave sea superior a 8192 bits.

    3. Vuelva a registrar vCenter en NSX si utiliza NSX.

    4. Reinicie el servicio WCP.

    Para obtener más información, consulte el artículo 96562 de la base de conocimientos.

  • Es posible que las plantillas se eliminen de la biblioteca de contenido en vCenter cuando la biblioteca está vinculada a varios espacios de nombres de vSphere

    Puede observar este problema cuando una biblioteca está vinculada a varios espacios de nombres en el plano de control de vSphere IaaS y la biblioteca se desvincula de un espacio de nombres o se elimina un espacio de nombres.

    Solución alternativa:

    Evite utilizar una biblioteca local si desea vincular la biblioteca a varios espacios de nombres. En su lugar, cree una biblioteca publicada en vCenter y cargue todas las plantillas en la biblioteca publicada. A continuación, cree una biblioteca suscrita que sincronize las plantillas de la biblioteca publicada en la misma instancia de vCenter y vincule esta biblioteca suscrita a varios espacios de nombres. En este caso, incluso cuando una biblioteca se desvincule de algún espacio de nombres o se elimine un espacio de nombres, los elementos de la biblioteca no se eliminarán de vCenter.

  • Se producen errores cuando se utilizan las REST API de VMware vSphere Automation para crear o actualizar una clase de máquina virtual e incluir campos enteros en configSpec

    Se pueden observar los siguientes errores cuando configSpec incluye campos enteros, como numCPU o memoryMB:

    Error desconocido: vcenter.wcp.vmclass.configspec.invalid: json: tipo discriminatorio no admitido: struct.

    Error desconocido: vcenter.wcp.vmclass.configspec.invalid: json: no se puede deserializar la cadena en el campo de estructura de Go VirtualMachineConfigSpec.<fieldName> del tipo int32.

    Este problema se produce debido a un problema conocido en el endpoint de VAPI que analiza el archivo JSON de configSpec de REST sin formato con enteros y pasa enteros como cadenas, provocando de este modo los errores. El problema solo se produce cuando se utilizan las REST API a través del Centro para desarrolladores de VMware.

    Solución alternativa: En lugar de las REST API, utilice la DCLI o vSphere Client para crear o actualizar las clases de máquinas virtuales.

    Si lo prefiere, puede utilizar vSphere Automation SDK para python/java. En el siguiente ejemplo se muestra cómo utilizar el servicio de transcodificador de protocolo público para convertir un objeto VirtualMachineConfigSpec (vim.vm.ConfigSpec) obtenido de vCenter mediante pyvmomi. La última entrada del ejemplo muestra cómo analizar un archivo JSON diseñado manualmente. A continuación, el objeto se puede enviar a la API VirtualMachineClasses.

  • Después de aplicar una licencia de vSphere VMware Foundation válida a un supervisor, la página Administración de cargas de trabajo sigue mostrando la licencia de evaluación anterior con una advertencia de caducidad

    Puede encontrar este problema si tiene el supervisor habilitado con una licencia de evaluación y aplica la licencia de vSphere VMware Foundation al supervisor. Sin embargo, la nueva licencia no aparece en la página Administración de cargas de trabajo de vSphere Client, en vCenter > Administración de cargas de trabajo > Supervisores > Supervisor. vSphere Client sigue mostrando la advertencia con la fecha de caducidad de la licencia de evaluación anterior aunque la nueva clave de licencia se haya aplicado correctamente.

    Solución alternativa: Ninguna. La nueva licencia aparece correctamente en vSphere Client en Administración > Licencias > Activos > Supervisores.

  • La regla de directiva de seguridad actualizada en la CRD de la directiva de seguridad no surte efecto si la regla agregada o eliminada no es la última

    Como integrante de desarrollo y operaciones, puede configurar la CRD de la directiva de seguridad para aplicar una directiva de seguridad basada en NSX a un espacio de nombres del clúster supervisor. Cuando se actualiza la CRD y se agrega o se elimina una regla de directiva de seguridad, la regla actualizada no surte efecto a menos que sea la última regla de la lista de reglas.

    Solución alternativa: Agregue la regla al final de la lista de reglas o utilice una directiva de seguridad independiente para agregar o eliminar reglas.

  • Los cambios en el formato de nombre de imagen de máquina virtual en vSphere 8.0 U2 pueden causar problemas cuando se utilizan nombres de imágenes de máquina virtual antiguos

    Antes de vSphere 8.0 Update 2, el nombre de un recurso de imagen de máquina virtual se derivaba del nombre de un elemento de la biblioteca de contenido. Por ejemplo, si un elemento de la biblioteca de contenido se denominaba photonos-5-x64, el recurso de VirtualMachineImage correspondiente también se denominaría photonos-5-x64. Esta circunstancia generaba problemas cuando los elementos de biblioteca de diferentes bibliotecas tenían el mismo nombre.

    En la versión vSphere 8.0 Update 2, se introdujo el servicio de imágenes de máquina virtual para que las imágenes de máquina virtual se pudieran administrar mediante el autoservicio. Consulte Crear y administrar bibliotecas de contenido para máquinas virtuales independientes en el plano de control de vSphere IaaS.

    Esta nueva funcionalidad permite que las bibliotecas de contenido se asocien con un espacio de nombres o con todo el clúster supervisor y requiere que los nombres de los recursos de imagen de máquina virtual en los clústeres de Kubernetes sean únicos y deterministas. Como resultado, para evitar posibles conflictos con los nombres de elementos de biblioteca, las imágenes de máquina virtual ahora siguen el nuevo formato de nombre vmi-xxx. Sin embargo, este cambio puede causar problemas en vSphere 8.0 Update 2 si utiliza varios archivos YAML de máquina virtual que hagan referencia a nombres de imagen anteriores, como photonos-5-x64 o centos-stream-8.

    Solución alternativa:

    1. Utilice los siguientes comandos para recuperar información sobre las imágenes de máquina virtual:

      • Para mostrar las imágenes asociadas con sus espacios de nombres, ejecute kubectl get vmi -n <namespace>.

      • Para recuperar las imágenes disponibles en el clúster, ejecute kubectl get cvmi.

    2. Después de obtener el nombre del recurso de imagen que aparece en la columna NAME, actualice el nombre en la especificación de implementación de máquina virtual.

  • Durante una actualización automática del supervisor, el proceso del servicio WCP en vSphere puede activar una detención y detenerse de forma inesperada

    Puede observar que hay un archivo de volcado de núcleo generado para el proceso del servicio WCP.

    Solución alternativa: Ninguna. El proceso de VMON reinicia automáticamente el servicio WCP y el servicio WCP reanuda la actualización sin problemas.

  • Se suspende la actualización de supervisor con el estado ErrImagePull y Error del proveedor en los pods de vSphere. Es posible que los volúmenes persistentes asociados a pods de vSphere (incluidos los servicios de supervisor) no se desasocien en caso de errores de ErrImagePull.

    Es posible que los volúmenes persistentes no se desasocien en los pods de vSphere que generan el error ErrImagePull. Esto puede provocar una cascada de pods de vSphere con errores, porque los volúmenes persistentes que se requieren están asociados a la instancia con errores. Durante la actualización de supervisor, los pods de vSphere dentro del supervisor podrían pasar al estado provider failed y, en consecuencia, dejar de responder.

    Solución alternativa: Elimine las instancias de pods de vSphere con errores que tengan volúmenes persistentes asociados. Es importante tener en cuenta que se pueden conservar las notificaciones de volumen persistente (PVC, Persistent Volume Claims) y los volúmenes persistentes que estén asociados con pods de vSphere. Después de completar la actualización, vuelva a crear los pods de vSphere con el mismo PodSpecPVC para mantener la integridad y la funcionalidad de los datos. Para mitigar este problema, cree pods de vSphere mediante ReplicaSets (DaemonSet, implementación) para mantener un conjunto estable de pods de vSphere de réplica que se ejecuten en cualquier momento dado.

  • La actualización del supervisor se bloquea al 50 % y se produce un error en la actualización de Pinniped debido a la elección del líder

    Los pods de Pinniped se bloquean en estado pendiente durante la implementación y se produce un error en la actualización del supervisor durante la actualización del componente de Pinniped.

    Los pasos para una solución alternativa son los siguientes:

    1. Ejecute kubectl get pods -n vmware-system-pinniped para comprobar el estado de los pods Pinniped.

    2. Ejecute kubectl get leases -n vmware-system-pinniped pinniped-supervisor -o yaml para comprobar que holderIdentity no sea alguno de los pods Pinniped con estado pendiente.

    3. Ejecute kubectl delete leases -n vmware-system-pinniped pinniped-supervisor para eliminar el objeto de concesión del supervisor pinniped que tiene un pod inactivo como holderIdentity.

    4. Ejecute kubectl get pods -n vmware-system-pinniped para asegurarse de que todos los pods de vmware-system-pinniped estén activos y en funcionamiento.

  • Un nodo de host ESXi no puede entrar en modo de mantenimiento con una máquina virtual del plano de control de supervisor en estado encendido

    En la configuración de supervisor con NSX Advanced Load Balancer, el host ESXi no puede entrar en modo de mantenimiento si hay una máquina virtual del motor de servicio de AVI en estado encendido, lo que afectará a la actualización del host ESXi y la actualización de NSX con modo de mantenimiento.

    Solución alternativa: Apague la máquina virtual del motor de servicio de AVI para que ESXi pueda entrar en modo de mantenimiento.

  • No se puede recibir el tráfico de bucle invertido mediante ClusterIP con pods de vSphere en VDIS

    Si una aplicación dentro de un pod vSphere intenta acceder a una ClusterIP a la que se atiende dentro del mismo pod de vSphere (en un contenedor diferente), el DLB dentro de VSIP no puede enrutar el tráfico de vuelta al pod de vSphere.

    Solución alternativa: Ninguna.

  • Las directivas de red no se aplican en un supervisor basado en VDS

    El YAML de servicio existente que utiliza NetworkPolicy no requiere ningún cambio. NetworkPolicy no se aplicará si está presente en el archivo.

    Solución alternativa: Debe establecer reglas basadas en directivas en las redes para VDS. Para la compatibilidad con NetworkPolicy, se requiere compatibilidad con redes NSX.

  • Es posible que el espacio de nombres de un servicio Carvel siga mostrándose en el vSphere Client después de desinstalar el servicio del supervisor

    Si el servicio Carvel tarda más de 20 minutos en desinstalarse del supervisor, es posible que su espacio de nombres siga apareciendo en el vSphere Client después de desinstalar el servicio.

    Los intentos de reinstalar el servicio en el mismo supervisor fallan hasta que se elimina el espacio de nombres. Además, el mensaje de ns_already_exist_error aparece durante la reinstalación.

    Verá la siguiente entrada en el archivo de registro:

    /var/log/vmware/wcp/wcpsvc.log should have the message - "Time out for executing post-delete operation for Supervisor Service with serviceID '<service-id>' from cluster '<cluster-id>'. Last error: <error>"

    Solución alternativa: Elimine manualmente el espacio de nombres del vSphere Client.

    1. En el menú de inicio de vSphere Client, seleccione Administración de cargas de trabajo.

    2. Haga clic en la pestaña Espacios de nombres.

    3. En la lista de espacios de nombres, seleccione el espacio de nombres no claro y haga clic en el botón REMOVE para eliminar el espacio de nombres.

  • La actualización de hosts ESXi de la versión 7.0 Update 3 a la 8.0 sin actualización del supervisor provoca que los hosts ESXi se muestren como No está listo (Not Ready) y que las cargas de trabajo se desconecten

    Cuando se actualizan los hosts ESXi que forman parte de un supervisor de vSphere 7.0 Update 3 a vSphere 8.0 y no se actualiza la versión de Kubernetes del supervisor, los hosts ESXi se muestran como No está listo (Not Ready) y las cargas de trabajo que se ejecutan en los hosts se desconectan.

    Solución alternativa: Actualice la versión de Kubernetes del supervisor a 1.21, 1.22 o 1.23, como mínimo.

  • Tras una actualización con un solo clic de vCenter Server, el supervisor no se actualizará automáticamente

    Si la versión de Kubernetes del supervisor es anterior a la 1.22, después de actualizar vCenter Server con un solo clic a la versión 8.0, el supervisor no puede realizar la actualización automática a la versión mínima compatible de Kubernetes para vCenter Server 8.0, que es la 1.23.

    Solución alternativa: Antes de actualizar vCenter Server a la versión 8.0, actualice la versión de Kubernetes del supervisor a la versión 1.22. Si ya ha actualizado vCenter Server a la versión 8.0, actualice manualmente la versión de Kubernetes del supervisor a la versión 1.23.

  • Si cambia las reglas en un recurso personalizado de directiva de seguridad, es posible que las reglas obsoletas no se eliminen

    Este problema puede ocurrir cuando se actualiza la directiva de seguridad. Por ejemplo, crea un recurso personalizado de directiva de seguridad que contiene las reglas A y B y después actualiza la directiva cambiando las reglas a B y C. Como resultado, la regla A no se elimina. El plano de administración de NSX sigue mostrando la regla A además de B y C.

    Solución alternativa: Elimine la directiva de seguridad y cree la misma.

  • Después de una actualización de vCenter Server y el plano de control de vSphere IaaS, un clúster de Tanzu Kubernetes Grid no puede completar su actualización debido a volúmenes que aparecen como asociados a los nodos del clúster

    Cuando el clúster de Tanzu Kubernetes Grid no se actualiza, puede observar que aparece un volumen como asociado a los nodos del clúster y que no se borra. Este problema puede deberse a un problema en la instancia de Kubernetes precedente.

    Solución alternativa:

    1. Obtenga información sobre el nodo del clúster de TKG que tiene la programación deshabilitada mediante el siguiente comando:

      kubectl get node tkc_node_name -o yaml

      Ejemplo:

      # kubectl get node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 -o yaml
apiVersion: v1
kind: Node
metadata:
  annotations:
    cluster.x-k8s.io/cluster-name: gcm-cluster-antrea-1
    cluster.x-k8s.io/cluster-namespace: c1-gcm-ns
    cluster.x-k8s.io/machine: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
    cluster.x-k8s.io/owner-kind: MachineSet
    cluster.x-k8s.io/owner-name: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7
    csi.volume.kubernetes.io/nodeid: '{"csi.vsphere.vmware.com":"gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"}'
    kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
….
….
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

      Compruebe si este nodo tiene algunos volúmenes de CSI de vSphere en la propiedad status.volumeAttached. Si hay algún volumen, continúe con el siguiente paso.

    2. Compruebe que no haya pods en ejecución en el nodo que se identificó en el paso 1. Use este comando:

      kubectl get pod -o wide | grep tkc_node_name

      Ejemplo:

      kubectl get pod -o wide | grep gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

      El resultado vacío de este comando indica que no hay pods. Continúe con el siguiente paso porque el resultado del paso 1 muestra un volumen asociado al nodo que no tiene ningún pod.

    3. Obtenga información sobre todos los objetos de nodo para asegurarse de que el mismo volumen esté asociado a otro nodo:

      kubectl get node -o yaml

      Ejemplo:

      Aparece el mismo nombre de volumen en dos objetos de nodo del clúster de TKG.

      On old node - "gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

On new node "gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
    ...
  volumesInUse:
  - kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
  ...

    4. Busque el PV según el identificador de volumen en el nombre del volumen.

      En el ejemplo anterior, el nombre del volumen es kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd y el identificador de volumen es 943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd.

      Obtenga todos los PV y busque el identificador del volumen anterior mediante este comando:

      kubectl get pv -o yaml

      En el ejemplo anterior, el PV con ese identificador de volumen es pvc-59c73cea-4b75-407d-8207-21a9a25f72fd.

    5. Utilice el comando volumeattachment para buscar el PV que se encontró en el paso anterior:

      kubectl get volumeattachment | grep pv_name

      Ejemplo:

      # kubectl get volumeattachment | grep pvc-59c73cea-4b75-407d-8207-21a9a25f72fd
NAME                                                                   ATTACHER                 PV                                         NODE                                                 ATTACHED   AGE
csi-2ae4c02588d9112d551713e31dba4aab4885c124663ae4fcbb68c632f0f46d3e   csi.vsphere.vmware.com   pvc-59c73cea-4b75-407d-8207-21a9a25f72fd   gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88   true       3d20h

      Puede observar una asociación de volúmenes asociada al nodo gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88 en lugar de al nodo gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95. Esto indica que status.volumeAttached en gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 es incorrecto.

    6. Elimine la entrada volumeAttached obsoleta del objeto de nodo:

      kubectl edit node tkc_node_name

      Ejemplo:

      kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

      Elimine la entrada de volumen obsoleta de status.volumeAttached.

    7. Repita los pasos anteriores para todos los volúmenes obsoletos en la propiedad status.volumeAttached.

    8. Si todavía está WCPMachines, elimínelo manualmente y espere unos minutos para conciliar el clúster.

      # kubectl get wcpmachines -n c1-gcm-ns
NAMESPACE   NAME                                       ZONE   PROVIDERID                                       IPADDR
c1-gcm-ns   gcm-cluster-antrea-1-workers-jrc58-zn6wl          vsphere://423c2281-d1bd-9f91-0e87-b155a9d291a1   192.168.128.17

# kubectl delete wcpmachine gcm-cluster-antrea-1-workers-jrc58-zn6wl -n c1-gcm-ns
wcpmachine.infrastructure.cluster.vmware.com "gcm-cluster-antrea-1-workers-jrc58-zn6wl" deleted

  • Un administrador de vSphere configura una plantilla de espacio de nombres de autoservicio con límites de recursos que superan la capacidad del clúster y no se activa una alerta.

    Cuando los administradores de vSphere configuran límites de recursos que superan la capacidad del clúster, los ingenieros de desarrollo y operaciones pueden utilizar la plantilla para implementar pods de vSphere con elevados recursos. Como consecuencia, se puede producir un error en las cargas de trabajo.

    Solución alternativa: Ninguna

  • Cuando se elimina un espacio de nombres de supervisor que contiene un clúster de Tanzu Kubernetes Grid, las notificaciones de volumen persistente presentes en el supervisor pueden permanecer en estado de finalización

    Este problema puede observarse cuando se produce un conflicto de recursos mientras el sistema elimina el espacio de nombres y separa los volúmenes de los pods en el clúster de Tanzu Kubernetes Grid.

    La eliminación del espacio de nombres de supervisor permanece incompleta y vSphere Client muestra el estado del espacio de nombres como finalizando. Las notificaciones de volumen persistente que se asociaron a los pods del clúster de Tanzu Kubernetes Grid también permanecen en estado de finalización.

    Si ejecuta los siguientes comandos, puede ver el error La operación no se puede completar en persistentvolumeclaims:

    kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

    kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c vsphere-syncer

    no se pudo actualizar PersistentVolumeClaim: \\\"<pvc-name>\\\" en el espacio de nombres: \\\"<supervisor-namespace>\\\". Error: La operación no se puede completar en persistentvolumeclaims \\\"<pvc-name>\\\": el objeto se ha modificado; aplique los cambios a la versión más reciente y vuelva a intentarlo\

    Solución alternativa:

    Utilice los comandos siguientes para solucionar el problema:

    kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

    kubectl patch pvc <pvc-name> -n <supervisor-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge

  • Al eliminar varios FCD y volúmenes de almacenes de datos compartidos como vSAN, es posible que observe cambios en el rendimiento

    Los cambios de rendimiento pueden deberse a un problema solucionado. Antes de estar solucionado, el problema provocaba que los volúmenes y los FCD obsoletos siguieran en el almacén de datos después de una operación de eliminación de FCD incorrecta.

    Solución alternativa: Ninguna. La operación de eliminación funciona como de costumbre a pesar del cambio de rendimiento.

  • Si un usuario de desarrollo y operaciones inicia operaciones de volumen o implementaciones de aplicaciones con estado mientras vCenter Server se reinicia, es posible que se produzca un error en las operaciones

    El problema se produce porque la cuenta de usuario de administración de almacenamiento de cargas de trabajo se bloquea y el complemento CSI de vSphere que se ejecuta en el supervisor no se puede autenticar. Como resultado, se produce un error en las operaciones de volumen con errores InvalidLogin.

    El archivo de registro /var/log/vmware/vpxd/vpxd.log muestra el siguiente mensaje:

    Se produjo un error en la autenticación: la cuenta del usuario que intenta autenticarse está bloqueada. :: la cuenta del usuario que intenta autenticarse está bloqueada. :: Cuenta de usuario bloqueada: {Nombre: workload_storage_management-<id>, dominio: <domain>})

    Solución alternativa:

    1. Obtenga el tiempo de desbloqueo de la cuenta.

      1. En vSphere Client, desplácese hasta Administración y haga clic en Configuración en Single Sign On.

      2. Haga clic en la pestaña Seleccionar cuentas.

      3. En la directiva de bloqueo, obtenga el tiempo de desbloqueo en segundos.

    2. Autentíquese con el supervisor mediante el complemento de vSphere para kubectl.

      kubectl vsphere login –server IP-ADDRESS --vsphere-username USERNAME

    3. Anote el recuento de réplicas original para la implementación de vsphere-csi-controller en el espacio de nombres vmware-system-csi-.

      kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'

      original-replica-count

    4. Escale horizontalmente el recuento de réplicas de implementación de vsphere-csi-controller a cero.

      kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi

    5. Espere el número de segundos indicado en Tiempo de desbloqueo.

    6. Escale verticalmente el recuento de réplicas de implementación de vsphere-csi-controller al valor original.

      kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi

Problemas conocidos de TKG en supervisor

  • Cuando se actualiza el entorno del plano de control de vSphere IaaS 7.0.x a vSphere 8.0.x, cualquier clúster de TKG de la versión 1.27.6 se vuelve incompatible

    vSphere 8.0.x no admite TKR 1.27.6.

    Como resultado, los clústeres de TKG de la versión 1.27.6 se vuelven incompatibles después de actualizar el plano de control de vSphere IaaS 7.0.x a vSphere 8.0.x. No recibirá ninguna advertencia de comprobación previa durante la actualización del supervisor.

    Solución alternativa:

  • Los nodos de trabajo del clúster de TKG no se encienden con el registro de error VIF restore activity already completed for attachment ID del pod nsx-ncp

    Los nodos de trabajo del clúster de TKG no se encienden y generan el siguiente error:

    nsx-container-ncp Generic error occurred during realizing network for VirtualNetworkInterface

    NCP registra un error:

    VIF restore activity already completed for attachment ID

    Cuando una máquina virtual de un nodo de clúster de TKG creado después de una copia de seguridad de NSX migra con vMotion inmediatamente después de la restauración de NSX, NCP no puede restaurar el puerto de la máquina virtual, ya que el identificador asociado se reutilizará en vMotion y bloqueará la solicitud de restauración de NCP.

    Solución alternativa:

    1. Vaya a NSX Manager para obtener los puertos de segmentos que se deben eliminar, tienen un nombre para mostrar con el formato <vm name>.vmx@<attachment id>

    2. Antes de eliminar el puerto recién creado, busque el host en el que se ejecuta la máquina virtual y desactive el ops-agent ejecutando /etc/init.d/nsx-opsagent stop en el host.

    3. Elimine el puerto mediante NSX API https://<nsx-mgr>/api/v1/logical-ports/<logical switch port id>?detach=true

    4. Para activar ops-agent, ejecute /etc/init.d/nsx-opsagent start en el host.

    5. Espere hasta que NCP restaure el puerto.

  • Los pods, los PV y las PVC de un clúster de TKG pueden quedarse bloqueados en el estado Terminating durante la limpieza del clúster de TKG o durante la recuperación de un tiempo de inactividad de hosts ESXi

    Como parte del proceso normal de eliminación y limpieza del clúster de TKG, se eliminan todas las implementaciones, statefulsets, PVC, PV y objetos similares. Sin embargo, en los clústeres de TKG basados en TKR v1.24 y versiones anteriores, es posible que algunos de los PV se bloqueen en el estado Terminating debido a errores de DetachVolume. El problema se genera cuando los errores de DetachVolume en un objeto VolumeAttachment provocan que no se eliminen los finalizadores de VolumeAttachment, lo que provoca un error al eliminar los objetos relacionados. Este escenario también puede producirse si hay tiempo de inactividad en los hosts ESXi.

    Solución alternativa: Ejecute el siguiente comando en el clúster de TKG para eliminar los finalizadores de volumeattachments con un detachError:

    kubectl get volumeattachments \
-o=custom-columns='NAME:.metadata.name,UUID:.metadata.uid,NODE:.spec.nodeName,ERROR:.status.detachError' \
--no-headers | grep -vE '<none>$' | awk '{print $1}' | \
xargs -n1 kubectl patch -p '{"metadata":{"finalizers":[]}}' --type=merge volumeattachments

  • No se puede acceder al clúster de TGK tras una copia de seguridad y restauración

    Si se crea un espacio de nombres de vSphere después de una copia de seguridad de NSX y se configura con un CIDR de entrada/salida personalizado, una vez que NSX se restaure a partir de una copia de seguridad, NCP no podrá completar el proceso de restauración y los clústeres de TKG en el espacio de nombres de vSphere no estarán disponibles. Se produce un error como el siguiente en NCP durante el proceso de restauración:

    NSX IP Pool ipp_<supervisor_namespace_id>_ingress not found in store

    Solución alternativa: En caso de que se creara una copia de seguridad del supervisor aproximadamente al mismo tiempo que la copia de seguridad de NSX, pero antes de crearse el espacio de nombres de vSphere afectado, restaure también el supervisor desde la copia de seguridad. Como alternativa, elimine el espacio de nombres de vSphere y los clústeres de TKG asociados, espere a que NCP se vuelva a sincronizar y, a continuación, vuelva a crear los recursos eliminados.

  • No se puede acceder al clúster de TKG tras una copia de seguridad y restauración de NSX

    Cuando un supervisor está configurado con un CIDR de entrada personalizado, después de una restauración de copia de seguridad de NSX, es posible que los clústeres de TKG dejen de estar disponibles, ya que el componente de NCP no puede validar correctamente la VIP de entrada de los clústeres de TKG.

    Solución alternativa: Mediante NSX API, configure manualmente las VIP para los clústeres de TKG en NSX para restaurar el acceso.

  • Los clústeres de Tanzu Kubernetes Grid existentes configurados con un servidor proxy no se pueden actualizar a un supervisor de vSphere 8

    CORREGIDO: Este problema conocido está solucionado en la versión vSphere 8 with Tanzu MP1.

    Si configuró un clúster de Tanzu Kubernetes Grid existente con un servidor proxy, no puede actualizar ese clúster de un supervisor de vSphere 7 a Tanzu Kubernetes Grid 2.0 en un supervisor de vSphere 8.

    Solución alternativa: El contenido del campo noProxy tiene conflictos con las comprobaciones de actualización. Debido a que este campo es obligatorio si el proxy se agrega a la especificación del clúster, debe eliminar la configuración del proxy por completo antes de actualizar a vSphere 8.

  • El pod antrea-resource-init se bloquea en estado Pendiente

    Después de actualizar la versión de Tanzu Kubernetes de un clúster de Tanzu Kubernetes Grid, el pod antrea-resource-init podría estar en estado Pendiente.

    Solución alternativa: Reinicie el pod en el supervisor.

  • Los clústeres de Tanzu Kubernetes Grid v1.21.6 pueden pasar al estado FALSE y es posible que algunas máquinas no se migren

    Después de actualizar a vCenter Server 8 y actualizar el supervisor, es posible que los clústeres de Tanzu Kubernetes Grid v1.21.6 pasen a un estado FALSE y que algunas WCPMachine no migren a vSphereMachine.

    Solución alternativa: ninguna

  • De forma predeterminada, la contraseña de la cuenta vmware-system-user caduca en 60 días para los clústeres de TKG que ejecutan TKR versión 1.23.8---vmware.2-tkg.2-zshippable

    Como parte del fortalecimiento de STIG, para los clústeres de TKG que ejecutan TKR versión 1.23.8---vmware.2-tkg.2-zshippable, la cuenta vmware-system-user está configurada para caducar en 60 días. Esto puede afectar a los usuarios que emplean la cuenta vmware-system-user para utilizar SSH en los nodos del clúster.

    Consulte el siguiente artículo de la base de conocimientos para actualizar la caducidad de la contraseña de vmware-system-user y permitir sesiones SSH en los nodos del clúster de TKG si es necesario: https://kb.vmware.com/s/article/90469

  • El pod tanzu-capabilities-controller-manager se reinicia continuamente y va a CLBO en el TKC en el plano de control de vSphere IaaS 8.0.0a

    A consecuencia de los problemas de permiso de la cuenta de servicio, el pod tanzu-capabilities-controller-manager en el clúster de TKG se bloquea en CLBO (bucle de bloqueo desactivado) cuando se utiliza TKR versión 1.23.8+ vmware.2- tkg.2-zshippable.

    Solución alternativa: Agregue los permisos necesarios a la cuenta de servicio de capacidades tanzu-capabilities-manager-sa en TKC.

    1. Pause la reconciliación del paquete de capacidades en TKC:

      kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"spec":{"paused": true}}' --type=merge

    2. Cree un nuevo archivo capabilities-rbac-patch.yaml:

      apiVersion: v1
kind: Secret
metadata:
  name: tanzu-capabilities-update-rbac
  namespace: vmware-system-tkg
stringData:
  patch-capabilities-rbac.yaml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"kind":"ClusterRole", "metadata": {"name": "tanzu-capabilities-manager-clusterrole"}}),expects="1+"
    ---
    rules:
      - apiGroups:
        - core.tanzu.vmware.com
        resources:
          - capabilities
        verbs:
          - create
          - delete
          - get
          - list
          - patch
          - update
          - watch
      - apiGroups:
          - core.tanzu.vmware.com
        resources:
          - capabilities/status
        verbs:
          - get
          - patch
          - update-rbac

    3. Aplique revisiones a la función de clúster de capacidades en TKC:

      //Replace tkc with the name of the Tanzu Kubernetes Grid cluster: kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"metadata":{"annotations":{"ext.packaging.carvel.dev/ytt-paths-from-secret-name.0":"tanzu-capabilities-update-rbac"}}}' --type=merge

    4. Elimine tanzu-capabilities-controller-manager en TKC.

  • Los clústeres de Tanzu Kubernetes Grid 2.0 en un supervisor implementado en tres zonas de vSphere no admiten máquinas virtuales con vGPU y almacenamiento de instancias.

    Los clústeres de Tanzu Kubernetes Grid 2.0 aprovisionados en una instancia de supervisor implementada en tres zonas de vSphere no admiten máquinas virtuales con vGPU y almacenamiento de instancias.

    Solución alternativa: ninguna

  • TKR versión 1.22.9 se muestra en la imagen de la biblioteca de contenido, pero no en el comando kubectl

    La biblioteca de contenido para imágenes TKR muestra TKR v1.22.9. El comando kubectl get tkr no muestra esta imagen como disponible, ya que TKR v1.22.9 no está disponible para su uso y no debe utilizarse. Esta imagen aparece en la biblioteca de contenido por error.

    Solución alternativa: Utilice un TKR distinto de TKR v1.22.9. Consulte las Notas de la versión de TKR para obtener una lista de los TKR disponibles.

  • No se puede aprovisionar un TKC mediante la API v1alpha1 y TKR v1.23.8 en el plano de control de vSphere IaaS 8.0.0a

    Cuando se utiliza la API TKC v1alpha1 para aprovisionar TKC con la versión 1.23.8. Se producirá un error en la solicitud con el mensaje "No se puede encontrar una versión completa compatible que coincida con la sugerencia de versión (1.23.8) y las etiquetas de sistema operativo predeterminadas: "os-arch=amd64,os-name=photon,os-type=linux,os-version=3.0".

    Solución alternativa: Cambiar a las API TKC v1alpha2 o v1alpha3 al aprovisionar TKC

  • Los clústeres de Tanzu Kubernetes Grid 2.0 aprovisionados con la API v1beta1 deben basarse en la ClusterClass predeterminada

    Si va a crear un clúster de Tanzu Kubernetes Grid 2.0 en Supervisor mediante la API v1beta1, el clúster debe basarse en la ClusterClass tanzukubernetescluster predeterminada. El sistema no compatibiliza un clúster basado en una ClusterClass diferente.

    Solución alternativa: A partir de la versión vSphere 8 U1, puede aprovisionar un clúster v1beta1 basado en una ClusterClass personalizada. Consulte el artículo de la base de conocimientos https://kb.vmware.com/s/article/91826.

Problemas conocidos de redes

  • En una configuración de NSX Advanced Load Balancer, no hay ninguna sección usage.ingressCIDRUsage en los resultados de clusternetworkinfo o namespacenetworkinfo

    En una configuración de NSX Advanced Load Balancer, la IP de entrada la asigna el controlador AVI, el uso de ingressCIDR no se mostrará en los resultados de clusternetworkinfo o namespacenetworkinfo.

    Solución alternativa: Obtenga el uso de ingressCIDR en la interfaz de usuario del controlador AVI en Aplicaciones > VIP de VS.

  • El CIDR del pod en la lista de prefijos de nivel 0 no se elimina después de eliminar el espacio de nombres de un supervisor enrutado

    En el supervisor enrutado, el CIDR del pod en una lista de prefijos de nivel 0 no se elimina después de eliminar el espacio de nombres.

    Solución alternativa: Elimine el objeto de listas de prefijos:

    curl -k -u ‘admin:U2.HzP7QZ9Aw’ -X PATCH -d ‘{“prefixes”:[{“network” : “10.246.0.0/16”,“le” : 28,“action” : “PERMIT”}]}’ https://<IP ADDRESS>/policy/api/v1/infra/tier-0s/ContainerT0/prefix-lists/pl_domain-c9:45c1ce8d-d2c1-43cb-904f-c526abd8fffe_deny_t1_subnets -H ‘X-Allow-Overwrite: true’ -H ‘Content-type: application/json

  • Los recursos de Kubernetes clusternetworkinfo y namespacenetworkinfo no contienen usage.ingressCIDRUsage cuando se utiliza NSX Advanced Load Balancer.

    Cuando se utiliza NSX Advanced Load Balancer en un supervisor basado en NSX, los recursos de Kubernetes clusternetworkinfo y namespacenetworkinfo ya no contienen los campos usage.ingressCIDRUsage. Esto significa que la ejecución de kubectl get clusternetworkinfo <supervisor-cluster-name> -o json o kubectl get namespacenetworkinfo <namespace-name> -n <namespace-name> -o json no contendrá el objeto de uso ingressCIDR en los resultados.

    Solución alternativa: Utilice la página de la interfaz de usuario del controlador AVI para acceder al uso de ingressCIDR.

  • Existen segmentos de nivel 1 obsoletos para algunos espacios de nombres después de la copia de seguridad y restauración de NSX

    Después de un procedimiento de copia de seguridad y restauración de NSX, los segmentos de nivel 1 obsoletos que tienen NIC del motor de servicio no se limpian.

    Cuando se elimina un espacio de nombres después de una copia de seguridad de NSX, la operación de restauración restaura los segmentos de nivel 1 obsoletos que están asociados con las NIC del motor de servicio de la controladora de NSX Advanced Load Balancer.

    Solución alternativa: Elimine manualmente los segmentos de nivel 1.

    1. Inicie sesión en NSX Manager.

    2. Seleccione Redes > Segmentos.

    3. Busque los segmentos obsoletos que están asociados con el espacio de nombres eliminado.

    4. Elimine las NIC obsoletas del motor de servicio en la sección Puertos/Interfaces.

  • Es posible que el monitor del equilibrador de carga deje de funcionar; el supervisor podría quedarse bloqueado en el estado "configurando" en vSphere Client

    Si NSX Advanced Load Balancer está habilitado, debido a la presencia de varios puntos de implementación en NSX, es posible que NCP no pueda extraer el estado del equilibrador de carga. Esto afecta a los supervisores existentes configurados con NSX Advanced Load Balancer una vez que se habilita en NSX. Este problema afecta a los supervisores nuevos que utilizan NSX Advanced Load Balancer. Los supervisores afectados por este problema seguirán funcionando, a excepción de la capacidad de supervisión del equilibrador de carga.

    Solución alternativa: Deshabilite NSX Advanced Load Balancer en NSX. Esto puede limitar la capacidad de implementar supervisores con NSX Advanced Load Balancer en entornos de WCP que tengan supervisores existentes que ejecuten NSX Advanced Load Balancer.

  • No se puede utilizar NSX Advanced Load Balancer con una instancia de vCenter Server que utilice una topología de modo vinculado integrado.

    Si configura el controlador de NSX Advanced Load Balancer, puede configurarlo en varias nubes. Sin embargo, no tiene una opción para seleccionar varias nubes al habilitar el plano de control de vSphere IaaS, ya que solo admite la opción Nube predeterminada. Como resultado, no se puede utilizar NSX Advanced Load Balancer con una versión de vCenter Server que utilice una topología de modo vinculado integrado.

    Configure el equilibrador de carga de NSX para cada instancia de vCenter Server.

Problemas conocidos del almacenamiento

  • Se observan varios errores de sincronización de volúmenes de CNS en un entorno en el que se comparte un almacén de datos entre sistemas vCenter

    CNS no admite la migración entre sistemas vCenter. Sin embargo, la sincronización periódica de CNS se realiza automáticamente y crea una contención de bloqueo para volúmenes en el almacén de datos compartido.

    Solución alternativa: Para evitar este problema, configure un intervalo de tiempo amplio para la sincronización periódica de CNS.

    1. Busque el archivo de configuración de CNS en vCenter:

      /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml

    2. Vaya a la siguiente línea:

      <newSyncInterval>60</newSyncInterval>

      De forma predeterminada, la sincronización periódica se establece en 60 segundos.

    3. Cambie el tiempo a un período más amplio; por ejemplo, 31536000 para 1 año.

  • No es posible cambiar el tipo de asignación de volumen para los discos de un almacén de datos de vSAN Direct

    Una vez que decida el tipo de asignación de volúmenes para los discos del almacén de datos de vSAN Direct, no podrá cambiarlo. Esto se debe a que las capas subyacentes no admiten la conversión de tipos. Sin embargo, sí es posible cambiar el tipo de asignación de volúmenes para el disco nuevo en operaciones como clonar y reubicar.

    Solución alternativa: ninguna

  • La máquina virtual eliminada provoca que las tareas de CNS se bloqueen en el estado en cola.

    Las operaciones enviadas a CNS devuelven un identificador de tarea, pero el estado de la tarea nunca pasa de en cola. Las tareas son para volúmenes asociados a una máquina virtual que se acaba de eliminar.

    Solución alternativa: Si la capa de aplicaciones puede corregir el pedido de llamada, no se debe hacer nada en el lado de CNS. De lo contrario, deshabilite la nueva serialización de CNS siguiendo los pasos que se indican a continuación:

    1. Abra /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml en vCenter.

    2. Cambie la siguiente configuración a false: <newSerializationEnabled>true</newSerializationEnabled>

    3. Reinicie vsan-health con vmon-cli -r vsan-health

    Consulte el artículo KB 93903 para obtener más información.

  • Los PV permanecen en estado finalizado después de eliminar correctamente las PVC

    Después de eliminar persistentVolumeClaim (PVC), la instancia de PersistentVolume (PV) correspondiente puede permanecer en un estado finalizado en Supervisor. Además, es posible que el vSphere Client muestre varias tareas con errores deleteVolume.

    Solución alternativa:

    1. Realice la autenticación con el supervisor:

      kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

    2. Obtenga el nombre del volumen persistente en estado finalizado:

      kubectl get pv

    3. Anote el identificador del volumen persistente:

      kubectl describe pv <pv-name>

    4. Con el identificador del volumen del paso anterior, elimine el recurso personalizado CnsVolumeOperationRequest en el supervisor:

      kubectl delete cnsvolumeoperationrequest delete-<volume-handle>

    Nota:

    Antes de eliminar un objeto PV, asegúrese de que ningún otro recurso del clúster lo esté utilizando.

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