Contenido de las notas de la versión

Actualizado: 6 de julio de 2023

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

Novedades del 6 de julio de 2023

Información de la compilación del 6 de julio de 2023

ESXi 7.0 Update 3m | 03 de mayo de 2023 | Compilación ISO 21686933

vCenter Server 7.0 Update 3n | 06 de julio de 2023 | Compilación ISO 21958406

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

Nuevas funciones

  • Compatibilidad de clústeres supervisores con Kubernetes 1.24: esta versión agrega compatibilidad para Kubernetes 1.24 y descarta la compatibilidad con Kubernetes 1.21.

Versiones de Kubernetes compatibles para clústeres supervisores:

Las versiones compatibles de Kubernetes en esta versión son 1.24, 1.23 y 1.22. Los 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 supervisores se ejecuten en las versiones compatibles de Kubernetes.

Novedades del 30 de marzo de 2023

Información de la compilación del 30 de marzo de 2023

ESXi 7.0 Update 3l | 30 de marzo de 2023 | Compilación ISO 21424296

vCenter Server 7.0 Update 3l | 30 de marzo de 2023 | Compilación ISO 21477706

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

Nuevas funciones:

  • Ninguna; solo se trata de una versión de corrección de errores.

Versiones de Kubernetes compatibles para clústeres supervisores

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 una versión compatible de Kubernetes.

Problemas resueltos

Esta revisión corrige los siguientes problemas.

  • Con la activación de la descarga de recepción grande (Large Receive Offload, LRO), las máquinas virtuales de clúster de Tanzu Kubernetes Grid que utilizan Antrea-ENCAP pueden experimentar problemas de rendimiento de red.

  • Habilitar el registro de Harbor integrado en el supervisor puede provocar una configuración predeterminada no segura.

Novedades del 23 de febrero de 2023

Información de la compilación del 23 de febrero de 2023

ESXi 7.0 Update 3i | 8 de diciembre de 2022 | Compilación ISO 20842708

vCenter Server 7.0 Update 3k | 23 de febrero de 2023 | Compilación ISO 21290409

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

Nuevas funciones:

Supervisor

  • Compatibilidad de clústeres supervisores con 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 una versión compatible de Kubernetes.

Novedades del 8 de diciembre de 2022

Información de la compilación del 8 de diciembre de 2022

ESXi 7.0 Update 3i | 8 de diciembre de 2022 | Compilación ISO 20842708

vCenter Server 7.0 Update 3i | 8 de diciembre de 2022 | Compilación ISO 20845200

VMware NSX Advanced Load Balancer avi-21.1.4-9009 | 7 de abril de 2022

Nuevas funciones:

Nueva CRD de SecurityPolicy: vSphere 7.0 Update 3i introduce una CRD de SecurityPolicy para que los usuarios apliquen una directiva de seguridad basada en NSX en las máquinas virtuales y los pods del supervisor. Esto proporciona la capacidad de configurar la "directiva de red de Kubernetes" a través de código al ampliar la directiva de red de Kubernetes a través de una CRD para los espacios de nombres de supervisor.

Soporte: La versión de TLS que se utiliza en los pods del sistema y del servicio kube-apiserver-authproxy-svc se actualizó a TLSv1.2.

Novedades del 13 de septiembre de 2022

Información de la compilación del 13 de septiembre de 2022

ESXi 7.0 Update 3g | 13 de septiembre de 2022 | Compilación ISO 20328353

vCenter Server 7.0 Update 3h | 13 de septiembre de 2022 | Compilación ISO 20395099

VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 29 de marzo de 2022

Nuevas funciones

  • Ninguna; solo se trata de una versión de corrección de errores.

Problemas resueltos:

Esta revisión soluciona el problema con la actualización de vCenter Server a la versión 70u3f que fallaba debido a que el servicio WCP no se iniciaba después de la actualización. El error se producía al intentar actualizar vCenter Server con vSphere with Tanzu activado en las versiones anteriores a 70u3d. Se producía un error al intentar actualizar vCenter Server desde una versión anterior a 70u3d a vCenter Server 70u3d y, a continuación, a vCenter Server 70u3f.

Para obtener más información sobre el problema resuelto, lea el artículo 89010 de la base de conocimientos.

Novedades del 12 de julio de 2022

Información de la compilación del 12 de julio de 2022

ESXi 7.0 Update 3f | 12 de julio de 2022 | Compilación ISO 20036589

vCenter Server 7.0 Update 3f | 12 de julio de 2022 | Compilación ISO 20051473

VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 29 de marzo de 2022

Nuevas funciones

  • Clúster supervisor

    • Compatibilidad con valor de cadena de IP del equilibrador de carga para Servicio de máquina virtual: permite al usuario proporcionar un valor de cadena al valor de spec.LoadBalancerIP que representa o corresponde a un IPPool creado y etiquetado en NSX-T.

    • Copia de seguridad y restauración de máquinas virtuales de Servicio de máquina virtual: ahora VMware admite la copia de seguridad y la restauración de máquinas virtuales de Servicio de máquina virtual en vSphere local y en VMware Cloud on AWS mediante un completo flujo de trabajo totalmente documentado que admite Veeam y otros proveedores de copias de seguridad basados en las API for Data Protection (vADP) de Almacenamiento de vSphere, lo que garantiza una solución de protección de datos más completa y la disponibilidad general de Servicio de máquina virtual en VMware Cloud on AWS.

Novedades del 12 de mayo de 2022

Información de la compilación del 12 de mayo de 2022

ESXi 7.0 Update 3d | 29 de marzo de 2022 | Compilación ISO 19482537

vCenter Server 7.0 Update 3e | 12 de mayo de 2022 | Compilación ISO 19717403

VMware NSX Advanced Load Balancer 20.1.7-9154 | 29 de marzo 2022

Nuevas funciones

  • Se agregó compatibilidad con la directiva de seguridad de red para las máquinas virtuales implementadas a través del servicio de operador de máquina virtual: las directivas de seguridad en NSX-T se pueden crear a través de grupos de seguridad basados en etiquetas. Ahora es posible crear una directiva de seguridad basada en NSX-T y aplicarla a las máquinas virtuales implementadas a través del operador de máquina virtual basado en etiquetas de NSX-T.

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

Consideraciones de actualización

Si actualizó vCenter Server desde una versión anterior a 7.0 Update 3c y el clúster supervisor utiliza Kubernetes 1.19.x, los pods de tkg-controller-manager entran en un estado CrashLoopBackOff, lo que hace que los clústeres invitados no se puedan administrar. Aparecerá un error similar al siguiente:

Pánico observado: Dirección de memoria no válida o desreferencia de puntero nulo

Solución alternativa: Para obtener información sobre este problema y solucionarlo, lea el artículo 88443 de la base de conocimientos.

Novedades del 29 de marzo de 2022

Información de la compilación del 29 de marzo de 2022

ESXi 7.0 Update 3d | 29 de marzo de 2022 | Compilación ISO 19482537

vCenter Server 7.0 Update 3d | 29 de marzo de 2022 | Compilación ISO 19480866

VMware NSX Advanced Load Balancer 20.1.7-9154 | 29 de marzo 2022

Nuevas funciones

  • Ninguna; solo se trata de una versión de corrección de errores.

Problemas resueltos

  • Se produce un error en las instalaciones de VIB de Spherelet en hosts vTPM

    • Se produce el siguiente error al instalar el VIB de Spherelet: 'No se pudo encontrar un firmante de confianza: certificado autofirmado' en un host vTPM.

  • La actualización de vSphere hace que el clúster supervisor se vuelva inestable

    • Después de actualizar vSphere de la versión 7.0 Update 1 a la versión 7.0 Update 2, el clúster supervisor pasa al estado de configuración.

  • La habilitación del clúster supervisor se detiene cuando se utiliza NSX-T Advanced Load Balancer

    • La habilitación del clúster supervisor con NSX-T Advanced Load Balancer puede provocar que la configuración se detenga en función de la configuración de autenticación predeterminada.

Novedades del 21 de octubre de 2021

Información de la compilación del 21 de octubre de 2021

ESXi 7.0 Update 3 | 27 de enero de 2022 | Compilación ISO 19193900

vCenter Server 7.0 Update 3a | 21 de octubre de 2021 | Compilación ISO 18778458

VMware NSX Advanced Load Balancer 20.1.7 | 21 de octubre de 2021 | Compilación ISO 18778458

IMPORTANTE: VMware retiró ESXi 7.0 Update 3, 7.0 Update 3a y 7.0 Update 3b de todos los sitios el 19 de noviembre de 2021 debido a un problema que afectaba a la actualización. La compilación 19193900 para el archivo ISO de ESXi 7.0 Update 3c reemplaza a la compilación 18644231. Consulte las Notas de la versión de VMware ESXi 7.0 Update 3c para obtener más información.

Nuevas funciones

  • Tanzu Kubernetes Grid Service for vSphere

    • Habilite cargas de trabajo en contenedor para aprovechar la aceleración de GPU en el clúster de Tanzu Kubernetes: los administradores de vSphere ahora pueden aprovisionar máquinas virtuales con aceleración de GPU en clústeres de Tanzu Kubernetes, y los desarrolladores ahora pueden agregar máquinas virtuales con aceleración de GPU a sus clústeres de Tanzu Kubernetes Grid con comandos de Kubernetes nativos.

    • Versión de Tanzu Kubernetes (TKr) basada en Ubuntu 20.04: esta es nuestra primera versión de TKr basada en Ubuntu 20.04. Esta imagen se optimizó y se probó específicamente para cargas de trabajo de GPU (AI/ML). Consulte las Notas de la versión de TKr para obtener más información.

Novedades del 5 de octubre de 2021

Información de compilación del 28 de septiembre de 2021

ESXi 7.0 Update 3 | 27 de enero de 2022 | Compilación ISO 19193900

vCenter Server 7.0 Update 3 | 5 de octubre de 2021 | Compilación ISO 18700403

VMware NSX Advanced Load Balancer 20.1.6 | 5 de octubre de 2021 | Compilación ISO 18700403

IMPORTANTE: VMware retiró ESXi 7.0 Update 3, 7.0 Update 3a y 7.0 Update 3b de todos los sitios el 19 de noviembre de 2021 debido a un problema que afectaba a la actualización. La compilación 19193900 para el archivo ISO de ESXi 7.0 Update 3c reemplaza a la compilación 18644231. Consulte las Notas de la versión de VMware ESXi 7.0 Update 3c para obtener más información.

Nuevas funciones

  • Clúster supervisor

    • vSphere Services: mediante el marco de servicios vSphere, los administradores de vSphere ahora pueden administrar los servicios de supervisor de forma asíncrona, incluidos MinIO, Cloudian Hyperstore, Dell ObjectScale y Velero. La naturaleza disociada que poseen los servicios de supervisor permite a los administradores agregar nuevos servicios al catálogo de servicios fuera de una versión de vCenter Server, lo que fortalece a la comunidad de desarrollo y operaciones aún más. Los servicios de supervisor solo están disponibles en los clústeres supervisores configurados con redes de NSX-T Data Center. Consulte la documentación para obtener información sobre la administración de servicios de supervisor en vSphere Client.

    • Compatibilidad con vGPU en Servicio de máquina virtual: los administradores de vSphere ahora pueden proporcionar acceso de autoservicio a los desarrolladores para uso de GPU a través de máquinas virtuales que utilizan Kubernetes, con los límites impuestos por las clases de máquinas virtuales. Los usuarios de desarrollo y operaciones pueden entonces crear rápidamente máquinas virtuales con GPU mediante estas imágenes y clases de máquinas virtuales predefinidas.

    • Habilitar la administración de cargas de trabajo con redes DHCP: esta versión agrega Red DHCP como una ruta de configuración de red alternativa para simplificar la habilitación para obtener una validación técnica más rápida. Los administradores de vSphere pueden configurar la red de administración y la red de cargas de trabajo con DHCP simplemente seleccionando la red y el grupo de puertos. Todas las demás entradas, incluidas DNS, NTP e IP flotante, se adquieren automáticamente mediante DHCP.

    • Comprobación del estado del equilibrador de carga y la red durante la habilitación: durante la habilitación, las comprobaciones del estado de conectividad de red, DNS, NTP y equilibrador de carga validan el éxito de la habilitación del clúster supervisor y ofrecen mensajes de error legibles para el usuario a fin de ayudar a diagnosticar y tomar medidas para los problemas más comunes. Consulte la documentación para obtener más instrucciones sobre cómo resolver los mensajes de error.

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

    • Etiquetas y anotaciones para espacios de nombres de supervisor: los espacios de nombres creados por los usuarios de desarrollo y operaciones a través de la plantilla de autoservicio de espacio de nombres ahora pueden tener anotaciones y etiquetas de Kubernetes.

    • Editar la configuración del clúster supervisor después de la habilitación: después de habilitar los clústeres supervisores con la pila de redes de vSphere, los administradores de vSphere ahora pueden editar la siguiente configuración tanto desde la API como desde vSphere Client: Nombre de usuario y contraseña del equilibrador de carga, Dominios de búsqueda de DNS de red de administración y Servidores DNS de red de carga de trabajo, Servidores NTP, expanda el rango de IP del servicio y agregue una nueva red de carga de trabajo. Para los clústeres que utilizan redes de vSphere o NSX-T, puede escalar verticalmente el tamaño del plano de control después de la habilitación. Tenga en cuenta que solo puede aumentar la escala del clúster; por el momento, no se admite la reducción de la escala. Consulte la documentación para obtener información sobre cómo cambiar la configuración del clúster supervisor mediante vSphere Client.

    • Caducidad de la clave de licencia de Tanzu: los administradores de vSphere ahora tienen más flexibilidad para administrar las claves de licencia caducadas de Tanzu Edition. Cuando las claves de licencia de Tanzu caduquen, las restricciones no se aplicarán automáticamente, lo que permite a los administradores obtener y asignar una nueva clave de licencia sin afectar a las operaciones normales.

  • Tanzu Kubernetes Grid Service for vSphere

    • Compatibilidad con RWX para volúmenes persistentes de vSAN: las cargas de trabajo que se ejecutan en clústeres de Tanzu Kubernetes ahora pueden montar volúmenes persistentes basados en vSAN con RWX.

    • Actualización de la API de Tanzu Kubernetes Grid Service v1alpha2: actualizaciones de API para la API de clústeres de Tanzu Kubernetes, donde se exponen nuevos campos que permiten una configuración mejorada de Tanzu Kubernetes Grid Service, incluida la compatibilidad con varios grupos de nodos de trabajo. Desuso de la API v1alpha1 en favor de la nueva API v1alpha2. Para obtener más información, consulte la documentación.

    • Servidor de métricas: el servidor de métricas ahora se incluye de forma predeterminada en los clústeres de Tanzu Kubernetes a partir de las versiones 1.20.9+ y 1.21 de Tanzu Kubernetes.

    • Capacidad para admitir topología sin NAT (enrutada): los clústeres de Tanzu Kubernetes ahora se pueden crear con una topología de red que permite que los nodos del clúster se enruten fuera de la red del clúster. Para obtener más información, consulte la documentación.

Novedades del 24 de agosto de 2021

Información de compilación del 24 de agosto de 2021

ESXi 7.0 Update 2c | 24 de agosto de 2021 | Compilación ISO 18426014

vCenter Server 7.0 Update 2c | 24 de agosto de 2021 | Compilación ISO 18356314

VMware NSX Advanced Load Balancer 20.1.5 | 24 de agosto de 2021 | Compilación ISO 18379150

Nuevas funciones

  • Clúster supervisor

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

    • Compatibilidad del complemento de Velero para vSphere con pods de vSphere: esta versión es compatible con Velero 1.5.1 y el complemento velero para vSphere 1.1.0 y versiones posteriores para la copia de seguridad y la restauración de pods de vSphere.

  • Tanzu Kubernetes Grid Service for vSphere

    • Harbor y external-dns como nuevas extensiones en clúster: los operadores de plataforma ahora tienen acceso a dos extensiones en clúster compatibles adicionales: Harbor y external-dns. Harbor es el registro de contenedores graduados de CNCF y external-dns es una herramienta popular para configurar dinámicamente registros de DNS basados en servicios de equilibrio de carga de Kubernetes.

    • Corrección mejorada de los nodos del plano de control: los clústeres de Tanzu Kubernetes ahora corregirán automáticamente los errores comunes de los nodos del plano de control, lo que proporciona un tiempo de ejecución de Kubernetes más robusto.

    • Compatibilidad del complemento de Velero para vSphere con cargas de trabajo de clústeres de Tanzu Kubernetes: esta versión proporciona compatibilidad con Velero 1.5.1 y versiones posteriores, y el complemento de Velero para vSphere 1.1.0 y versiones posteriores para la copia de seguridad y la restauración de cargas de trabajo que se ejecutan en clústeres de Tanzu Kubernetes.

    • Compatibilidad independiente de Velero con cargas de trabajo de clústeres de Tanzu Kubernetes: esta versión proporciona compatibilidad con Velero 1.6 para hacer copias de seguridad y restaurar cargas de trabajo de clústeres de Tanzu Kubernetes mediante Velero independiente con Restic.

Novedades del 27 de abril de 2021

Información de la compilación del 27 de abril de 2021

ESXi 7.0 | 09 de marzo de 2021 | Compilación ISO 17630552

vCenter Server 7.0 | 27 de abril de 2021 | Compilación ISO 17920168

Nuevas funciones

  • Clúster supervisor

    • Administración de máquinas virtuales con Kubernetes a través del servicio de máquina virtual. Esta versión agrega el servicio de máquina virtual a los servicios de infraestructura de vSphere with Tanzu, incluida la administración de máquinas virtuales nativas de Kubernetes para desarrolladores. El servicio de máquina virtual permite a los desarrolladores implementar y administrar este tipo de máquinas en un espacio de nombres con los comandos de Kubernetes. Al mismo tiempo, el administrador de vSphere puede regir el consumo de recursos y la disponibilidad del servicio, y proporcionar a los desarrolladores una experiencia de nube nativa.

    • Creación de autoservicio de espacios de nombres para desarrolladores. Los administradores de vSphere ya pueden crear y configurar un espacio de nombres de supervisor como una plantilla de espacio de nombres de autoservicio. Esta plantilla define los límites de recursos y los permisos de uso. Los desarrolladores pueden utilizarla a continuación para aprovisionar un espacio de nombres y ejecutar cargas de trabajo en él, sin necesidad de solicitarlas ni esperar su aprobación.

  • Tanzu Kubernetes Grid Service for vSphere

    • IMPORTANTE: Corrección de CVE para TKR: Hay nuevas versiones de Tanzu Kubernetes disponibles para solucionar CVE-2021-30465.

    • IMPORTANTE: Corrección de CVE para la extensión de entrada de Contour: Hay una nueva versión de imagen Envoy para solucionar CVE-2021-28682, CVE-2021-28683 y CVE-2021-29258. Consulte el artículo de KB asociado para obtener más información.

    • Nuevo flujo de trabajo para usar clases de máquinas virtuales predeterminadas. Hay un nuevo flujo de trabajo para usar las clases de máquinas virtuales predeterminadas para aprovisionar clústeres de Tanzu Kubernetes. Antes de crear un nuevo clúster, agregue las clases de máquinas virtuales predeterminadas al espacio de nombres de vSphere en el que aprovisiona el clúster. Consulte la documentación para obtener instrucciones.

    • Los webhooks mutantes del sistema ahora admiten el modo dry-run. Los usuarios ya pueden integrar herramientas populares, como el proveedor Terraform Kubernetes, con el servicio Tanzu Kubernetes Grid. Anteriormente, los webhooks del sistema no admitían el modo dry-run, indispensable para el comando `plan` de Terraform.

    • Clases de máquinas virtuales personalizadas. Los clústeres de Tanzu Kubernetes pueden consumir clases personalizadas de máquinas virtuales a través del servicio de máquina virtual. Así, los usuarios pueden configurar diferentes cantidades de CPU y memoria asignadas a las máquinas virtuales que configuran un clúster de Tanzu Kubernetes.

Novedades del 9 de marzo de 2021

Información de la compilación del 9 de marzo de 2021

ESXi 7.0 | 09 de marzo de 2020 | Compilación ISO 17630552

vCenter Server 7.0 | 09 de marzo de 2021 | Compilación ISO 17694817

VMware NSX Advanced Load Balancer | 12 de octubre de 2020 | 20.1.X

Nuevas funciones

  • Clúster supervisor

    • Compatibilidad de NSX Advanced Load Balancer en un clúster supervisor configurado con redes de VDS. Ahora puede habilitar un clúster supervisor con NSX Advanced Load Balancer (Avi Networks) para el equilibrio de carga de capa 4. También puede habilitar el equilibrio de carga para los nodos del plano de control de los clústeres de Tanzu Kubernetes y supervisor. Revise la documentación para obtener ayuda sobre cómo configurar NSX Advanced Load Balancer.

    • Actualización del clúster supervisor a Kubernetes 1.19 con actualización automática de un clúster supervisor que ejecuta Kubernetes 1.16. Puede actualizar el clúster supervisor a Kubernetes 1.19. Con esta actualización, se admiten las siguientes versiones de clúster supervisor: 1.19, 1.18 y 1.17. Los clústeres supervisores que ejecutan Kubernetes 1.16 se actualizarán automáticamente a la versión 1.17 una vez que se actualice vCenter Server. De esta forma se garantizará que todos los clústeres supervisores se ejecuten con la versión compatible de Kubernetes.

    • Expansión de las notificaciones de volumen persistente (Persistent Volume Claim, PVC). Ahora puede expandir los volúmenes existentes modificando el objeto PersistentVolumeClaim, incluso cuando un volumen se utiliza activamente. Esto se aplica a los volúmenes del clúster supervisor y de los clústeres de Tanzu Kubernetes.

    • Administración del ciclo de vida del clúster supervisor mediante vSphere Lifecycle Manager. En el caso de los clústeres supervisores configurados con redes de NSX-T, puede utilizar vSphere Lifecycle Manager para configurar la infraestructura y administrar el ciclo de vida.

  • Tanzu Kubernetes Grid Service for vSphere

    • Compatibilidad con los registros de contenedores privados. Los administradores de vSphere y los operadores de la plataforma de Kubernetes ya pueden definir otros certificados de entidades de certificación (Certificate Authority, CA) para usarlos en clústeres de Tanzu Kubernetes y confiar en registros de contenedores privados. Esta función permite que los clústeres de Tanzu Kubernetes extraigan imágenes de contenedor de los registros de contenedores que tengan certificados empresariales o autofirmados. Puede configurar como predeterminadas las entidades de certificación privadas para los clústeres de Tanzu Kubernetes en todo el clúster supervisor o por clúster de Tanzu Kubernetes. Para obtener más información sobre cómo configurar la compatibilidad de registros de contenedores privados en clústeres de Tanzu Kubernetes, consulte la documentación.

    • IP definidas por el usuario para el tipo de servicio: LoadBalancer con NSX-T y NSX Advanced Load Balancer. Los operadores de aplicaciones de Kubernetes ya pueden proporcionar un valor de LoadBalancerIP definido por el usuario al configurar un tipo de servicio: LoadBalancer que permite un endpoint de IP estática para el servicio. Esta función avanzada requiere el equilibrio de carga de NSX-T o NSX Advanced Load Balancer con el clúster supervisor. Para obtener información sobre cómo configurar esta función, consulte la documentación.

    • ExternalTrafficPolicy y LoadBalancerSourceRanges para el tipo de servicio: LoadBalancer con NSX-T. Los operadores de aplicaciones de Kubernetes ya pueden configurar ExternalTrafficPolicy para 'local', con el objetivo de que los servicios propaguen la dirección IP de cliente a los pods finales. También puede definir loadBalancerSourceRanges para que los servicios restrinjan qué direcciones IP de cliente pueden acceder al servicio de equilibrio de carga. Estas dos funciones avanzadas requieren el equilibrio de carga de NSX-T con el clúster supervisor.

    • Administración de versiones de Kubernetes e indicaciones. Ya puede utilizar kubectl para inspeccionar la compatibilidad de TanzuKubernetesReleases con el entorno subyacente del clúster supervisor. Los clústeres de Tanzu Kubernetes ahora también indican si hay una actualización de Kubernetes disponible y recomiendan que se utilice la siguiente o siguientes TanzuKubernetesRelease(s). Para obtener más información sobre el uso de esta nueva función, consulte la documentación.

    • Estado mejorado del clúster a primera vista. En una versión anterior, VMware amplió las definiciones de recursos personalizados (Custom Resource Definition, CRD) de WCPCluster y WCPMachine mediante la implementación de informes de estado condicional para descubrir problemas y errores comunes. Con la versión vSphere 7.0 Update 2, se mejoraron los CRD TanzuKubernetesCluster para resumir los informes de estado condicional de los componentes de subsistemas, de manera que se proporcionen respuestas inmediatas e instrucciones detalladas que ayuden a investigar los problemas. Para obtener información sobre cómo configurar esta función, consulte la documentación.

    • Configuración de proxy HTTP por clúster de Tanzu Kubernetes. Ya puede definir la configuración de proxy HTTP/HTTPS para cada clúster de Tanzu Kubernetes o, si lo prefiere, en todo el clúster supervisor, a través de la configuración predeterminada. Para obtener información sobre cómo configurar esta función, consulte la documentación.

    • Compatibilidad con las extensiones de Tanzu Kubernetes Grid. Las extensiones en clúster ya son totalmente compatibles con el servicio Tanzu Kubernetes Grid, incluidas Fluent Bit, Contour, Prometheus, AlertManager y Grafana.

Consideraciones sobre la actualización de clústeres de Tanzu Kubernetes

La versión vSphere 7.0 Update 2 incluye una funcionalidad que actualiza automáticamente el clúster supervisor cuando vCenter Server está actualizado. Si tiene clústeres de Tanzu Kubernetes aprovisionados en su entorno, lea el artículo 82592 de la base de conocimientosantes de actualizar a vCenter Server 7.0 Update 2. El artículo proporciona instrucciones para ejecutar una comprobación previa que permita determinar si algún clúster de Tanzu Kubernetes se volverá incompatible después de que el clúster supervisor se actualice automáticamente.

Problemas resueltos

  • El certificado SSL del registro de contenedor integrado no se copia en los nodos del clúster de Tanzu Kubernetes

    • Cuando el registro de contenedor integrado está habilitado para ese clúster supervisor, el certificado SSL de Harbor no se incluye en ningún nodo del clúster de Tanzu Kubernetes creado en ese clúster supervisor y no es posible conectarse al registro desde esos nodos.

  • Después de actualizar Tanzu Kubernetes Grid 1.16.8 a la versión 1.17.4, el pod "guest-cluster-auth-svc" en uno de los nodos del plano de control se paraliza en el estado "Creación de contenedor"

    • Después de actualizar un clúster de Tanzu Kubernetes del servicio Tanzu Kubernetes Grid 1.16.8 a la versión 1.17.4, el pod "guest-cluster-auth-svc" en uno de los nodos del plano de control del clúster se paraliza en el estado "Creación de contenedor"

  • El usuario no puede administrar los pods existentes en un clúster de Tanzu Kubernetes durante una actualización del clúster o después de esta

    • El usuario no puede administrar los pods existentes en un clúster de Tanzu Kubernetes durante una actualización del clúster o después de esta

  • Se produce un error en el trabajo de actualización del clúster de Tanzu Kubernetes y se muestra el mensaje "Se agotó el tiempo de espera para que se aprobara la comprobación de estado de etcd"

    • Se produce un error en el trabajo de actualización del espacio de nombres vmware-system-tkg asociado a la actualización de un clúster de Tanzu Kubernetes y se muestra el mensaje "Se agotó el tiempo de espera para que se aprobara la comprobación de estado de etcd". El problema se debe a que faltan direcciones PodIP para los pods de etcd.

  • Antrea CNI no se admite en la versión actual de TKC

    • Al aprovisionar un clúster de Tanzu Kubernetes, aparece el error "Antrea CNI no se admite en la versión actual de TKC".

      Opción 1 (recomendada): Actualice el clúster de Tanzu Kubernetes para utilizar la versión de OVA que admite Antrea (1.17.8 o posterior).

      Opción 2: En el YAML de la especificación del clúster de Tanzu Kubernetes, escriba "calico" en la sección spec.settings.network.cni.

      Opción 3: Cambie el CNI predeterminado a Calico. Consulte el tema en la documentación para saber cómo hacerlo.

Novedades del 2 de febrero de 2021

Información de la compilación del 2 de febrero de 2021

ESXi 7.0 | 17 de diciembre de 2020 | Compilación ISO 17325551

vCenter Server 7.0 | 02 de febrero de 2021 | Compilación ISO 17491101

Nuevas funciones

  • Clúster supervisor

    • Actualización de clústeres supervisores con redes de vSphere: Ahora puede actualizar los clústeres supervisores que utilizan redes de vSphere de una versión anterior de Kubernetes a la versión más reciente disponible. Las nuevas versiones del clúster supervisor harán que también estén disponibles las funciones más recientes del servicio Tanzu Kubernetes Grid.

Problemas resueltos

  • Las nuevas funciones del servicio Tanzu Kubernetes Grid no estaban disponibles en los supervisores existentes con redes de vSphere

    • En la versión anterior, las nuevas capacidades del servicio Tanzu Kubernetes Grid y las correcciones de errores solo estaban disponibles en los clústeres supervisores recién creados cuando se usaban redes de vSphere. En esta versión, los usuarios ahora pueden actualizar los clústeres supervisores con redes de vSphere para aprovechar las últimas funciones y correcciones de errores del servicio Tanzu Kubernetes Grid.

Novedades del 17 de noviembre de 2020

Información de la compilación del 17 de diciembre de 2020

ESXi 7.0 | 17 de diciembre de 2020 | Compilación ISO 17325551

vCenter Server 7.0 | 17 de diciembre de 2020 | Compilación ISO 17327517

Nota: Para aprovechar las nuevas capacidades del servicio Tanzu Kubernetes Grid y las correcciones de errores de esta versión, es necesario crear un nuevo clúster supervisor si se utilizan redes de vSphere.

Nuevas funciones

  • Clúster supervisor

    • Aislamiento del espacio de nombres de supervisor con enrutador T1 dedicado. Los clústeres supervisores que usan redes NSX-T utilizan una nueva topología, en la que cada espacio de nombres tiene su propio enrutador T1 dedicado.

      • Los clústeres supervisores recién creados usan esta nueva topología automáticamente.

      • Los clústeres supervisores existentes se migran a esta nueva topología durante una actualización.

    • Compatibilidad de clústeres supervisores con NSX-T 3.1.0. Los clústeres supervisores son compatibles con NSX-T 3.1.0.

    • Sin compatibilidad con la versión 1.16.x de los clústeres supervisores. Se ha eliminado la versión 1.16.x de estos clústeres. Los clústeres supervisores que ejecutan la versión 1.16.x deben actualizarse a una nueva versión.

  • Tanzu Kubernetes Grid Service for vSphere

    • Compatibilidad con servidores proxy HTTP/HTTPS. Los clústeres de Tanzu Kubernetes recién creados pueden utilizar un proxy HTTP/HTTPS global para el tráfico de salida y para extraer imágenes de contenedor de los registros de Internet.

    • Integración con el servicio de registro. Los clústeres de Tanzu Kubernetes recién creados funcionan desde el comienzo con el servicio de registro de vSphere. Los clústeres existentes, una vez actualizados a una nueva versión, también funcionan con el servicio de registro.

    • Almacenamiento del nodo configurable. Los clústeres de Tanzu Kubernetes ya pueden montar un volumen de almacenamiento adicional en las máquinas virtuales, lo que aumenta la capacidad de almacenamiento disponible del nodo. Esto permite a los usuarios implementar imágenes de contenedor más grandes que pueden superar el tamaño de volumen raíz predeterminado de 16 GB.

    • Información de estado mejorada. Las definiciones de recursos personalizados de WCPCluster y WCPMachine implementan ahora informes de estado condicional. La administración correcta del ciclo de vida de los clústeres de Tanzu Kubernetes depende de una serie de subsistemas (por ejemplo, supervisor, almacenamiento y redes) y entender el motivo de los errores puede ser difícil. Ahora, las definiciones de recursos personalizados (Custom Resource Definitions, CRD) de WCPCluster y WCPMachine muestran las condiciones de error y de estado habituales para facilitar la solución de problemas.

Problemas resueltos

  • Faltan nuevas clases de máquinas virtuales predeterminadas introducidas en vCenter Server 7.0 Update 1

    • Después de actualizar a vSphere 7.0.1 y, a continuación, realizar una actualización de los espacios de nombres de vSphere del clúster supervisor, al ejecutar el comando "kubectl get virtualmachineclasses" no se enumeran los nuevos tamaños de clase de máquina virtual 2x-large, 4x-large y 8x-large. Este problema se ha resuelto y todos los clústeres supervisores se configurarán con el conjunto correcto de clases de máquinas virtuales predeterminadas.

Novedades del 6 de octubre de 2020

Información de la compilación del 6 de octubre de 2020

ESXi 7.0 | 06 de octubre de 2020 | Compilación ISO 16850804

vCenter Server 7.0 | 06 de octubre de 2020 | Compilación ISO 16860138

Nuevas funciones

  • Clúster supervisor

    • Configuración de clústeres supervisores con redes de vSphere. Se introdujeron las redes de vSphere para los clústeres supervisores, lo que le permite distribuir una plataforma preparada para desarrolladores mediante su infraestructura de red existente.

    • Compatibilidad con el equilibrador de carga de HAproxy para configurar clústeres supervisores con redes de vSphere. Si se configuran clústeres supervisores con redes de vSphere, es necesario agregar un equilibrador de carga para procesar las cargas de trabajo modernas. Puede implementar y configurar su equilibrador de carga con un HAproxy OVA.

    • Administración del ciclo de vida del clúster supervisor mediante vSphere Lifecycle Manager. En el caso de los clústeres supervisores configurados con redes de vSphere, puede utilizar vSphere Lifecycle Manager para configurar la infraestructura y administrar el ciclo de vida.

    • Oportunidad de probar vSphere with Tanzu en su hardware. Ahora le ofrecemos una versión de prueba en el producto si desea habilitar un clúster supervisor en su hardware y probar esta moderna plataforma de aplicaciones sin ningún coste adicional.

  • Tanzu Kubernetes Grid Service for vSphere

    • Exposición de las versiones de Kubernetes para los usuarios de desarrollo y operaciones. Se introdujo una nueva definición de recursos personalizados ('TanzuKubernetesRelease') en el clúster supervisor. Esta definición de recursos personalizados proporciona información detallada al usuario de desarrollo y operaciones sobre las versiones de Kubernetes que puede utilizar en los clústeres de Tanzu Kubernetes.

    • Integración de VMware Container Networking con Antrea para Kubernetes. Se integró una versión de Antrea con soporte comercial como CNI predeterminada para los nuevos clústeres de Tanzu Kubernetes. Antrea aporta un conjunto completo de funciones de directiva de red empresarial al servicio Tanzu Kubernetes Grid. Para obtener más información, consulte el anuncio de la versión. Aunque Antrea es la CNI predeterminada, los administradores de vSphere y los usuarios de desarrollo y operaciones aún pueden elegir Calico como CNI para los clústeres de Tanzu Kubernetes.

    • Compatibilidad con entornos de clústeres supervisores que utilizan redes de vSphere. Ahora se admiten entornos de clústeres supervisores que usan redes de vSphere para que pueda aprovechar su infraestructura de red existente.

Problemas resueltos

  • No hay ninguna lista. Este es una versión de actualización de funciones.

Novedades del 25 de agosto de 2020

Información de la compilación del 25 de agosto de 2020

ESXi 7.0 | 23 de junio de 2020 | Compilación ISO 16324942

vCenter Server 7.0 | 25 de agosto de 2020 | Compilación ISO 16749653

Nuevas funciones

  • Ninguna; solo se trata de una versión de corrección de errores.

Problemas resueltos

  • Uso elevado de CPU tras la actualización a la revisión del 30 de julio

    • vCenter Server genera un uso elevado de CPU después de la actualización a la revisión del 30 de julio. Este problema se solucionó.

  • Error de habilitación del clúster supervisor debido a un certificado con finales de línea de Windows

    • Es posible que se produzca un error al habilitar el clúster supervisor si hay finales de línea de Windows en el certificado. Este problema se solucionó.

Novedades del 30 de julio de 2020

Información de la compilación del 30 de julio de 2020

ESXi 7.0 | 23 de junio de 2020 | Compilación ISO 16324942

vCenter Server 7.0 | 30 de julio de 2020 | Compilación ISO 16620007

Nuevas funciones

  • Clúster supervisor: nueva versión de Kubernetes, compatibilidad con certificados personalizados y cambios de PNID

    • El clúster supervisor ahora es compatible con Kubernetes 1.18.2 (y con las versiones 1.16.7 y 1.17.4)

    • Ahora se admite el reemplazo de certificados SSL de máquina con certificados personalizados

    • La actualización del PNID de vCenter ahora se admite cuando hay clústeres supervisor en vCenter Server

  • Tanzu Kubernetes Grid Service for vSphere: se agregaron nuevas funciones para el escalado vertical de clústeres, redes y almacenamiento

    • Ya se pueden reducir horizontalmente los clústeres del servicio Tanzu Kubernetes Grid

    • Las reglas de firewall de entrada ahora se aplican de forma predeterminada en todos los clústeres del servicio Tanzu Kubernetes Grid

    • Envío periódico de forma asíncrona de nuevas versiones de Kubernetes a las revisiones de vSphere; las versiones actuales son 1.16.8, 1.16.12, 1.17.7 y 1.17.8

  • Servicio de red: nueva versión de NCP

    • SessionAffinity ahora es compatible con los servicios de ClusterIP

    • IngressClass, PathType y dominio comodín son compatibles con el ingreso en Kubernetes 1.18

    • La autenticación de cliente ahora es compatible con el controlador de entrada

  • Servicio de registro: nueva versión de Harbor

    • El servicio de registro se actualizó a la versión 1.10.3

Para obtener más información e instrucciones sobre cómo actualizar, consulte la documentación de Actualizar clústeres de vSphere with Tanzu.

Problemas resueltos

  • Problema de sincronización de NTP de clúster del servicio Tanzu Kubernetes Grid

Novedades del 23 de junio de 2020

Información de compilación del 23 de junio de 2020

ESXi 7.0 | 23 de junio de 2020 | Compilación ISO 16324942

vCenter Server 7.0 | 23 de junio de 2020 | Compilación ISO 16386292

OVA de clústeres de Tanzu Kubernetes: v1.16.8+vmware.1-tkg.3.60d2ffd

Nuevas funciones

  • Ninguna; solo se trata de una versión de corrección de errores.

Problemas resueltos

  • Error de actualización del clúster de servicio Tanzu Kubernetes Grid

    • Resolvimos un problema por el que se podía producir un error en la actualización de un clúster de servicio Tanzu Kubernetes Grid debido a "Error: nodo anterior desconocido".

  • Error de actualización del clúster de supervisor

    • Resolvimos un problema que provocaba que una actualización del clúster de supervisor se bloqueara si la instancia de Harbor integrada mostraba un estado con errores.

Novedades del 19 de mayo de 2020

Información de compilación del 19 de mayo de 2020

ESXi 7.0 | 2 de abril de 2020 | Compilación ISO 15843807

vCenter Server 7.0 | 19 de mayo de 2020 | Compilación ISO 16189094

OVA de clústeres de Tanzu Kubernetes: v1.16.8+vmware.1-tkg.3.60d2ffd

Nuevas funciones

  • Tanzu Kubernetes Grid Service for vSphere: actualización gradual y de servicios

    • Los clientes ahora pueden realizar actualizaciones graduales en los nodos de trabajo y los nodos de plano de control para Tanzu Kubernetes Grid Service for vSphere, así como actualizar los servicios pvCSI, Calico y authsvc. Esto incluye comprobaciones previas y compatibilidad de actualizaciones para esta matriz de servicios.

    • Las actualizaciones graduales se pueden utilizar para escalar o reducir verticalmente los nodos de trabajo, es decir, cambiar la clase de máquina virtual de los nodos de trabajo a un tamaño más grande o a uno más pequeño.

  • Clúster supervisor: nuevas versiones de Kubernetes y actualización admitida

    • El clúster supervisor ahora admite Kubernetes 1.17.4.

    • El clúster supervisor ahora admite la actualización de Kubernetes 1.16.x a la versión 1.17.x.

Problemas resueltos

  • Conflicto de nomenclatura para espacios de nombres eliminados

    • Se resolvió un problema por el que, si un usuario eliminaba un espacio de nombres de vSphere y luego creaba uno nuevo con el mismo nombre, existía un conflicto de nomenclatura que provocaba que no se pudieran crear clústeres de Tanzu Kubernetes.

  • Nombres de distribución mejorados

    • Se hizo más claro cuál es la versión de Kubernetes que se ejecuta. Para ello, se transfirió la información de versiones de OVF a una columna independiente.

Información de la compilación de la versión inicial de vSphere with Kubernetes

Información de compilación del 2 de abril de 2020

ESXi 7.0 | 2 de abril de 2020 | Compilación ISO 15843807

vCenter Server 7.0 | 2 de abril de 2020 | Compilación ISO 15952498

OVA de clústeres de Tanzu Kubernetes: v1.16.8+vmware.1-tkg.3.60d2ffd

Más información sobre vSphere with Tanzu

VMware proporciona una variedad de recursos que puede utilizar para obtener información sobre vSphere with Tanzu.

  • Obtenga información sobre cómo configurar, administrar y usar vSphere with Tanzu en Configuración y administración de vSphere with Tanzu. Esta guía está diseñada para equipos de desarrollo y operaciones y administradores del sistema vSphere, y proporciona detalles sobre la arquitectura, los servicios, las licencias, los requisitos del sistema, la configuración y el uso de vSphere with Tanzu.

  • Utilice las guías de compatibilidad de VMware para obtener información sobre compatibilidad de hardware e interoperabilidad de productos para vSphere with Tanzu. vSphere with Tanzu tiene los mismos requisitos de hardware que vSphere 7.0. Para determinadas configuraciones, también se requiere que se empleen máquinas virtuales de NSX-T Edge, las cuales tienen su propio subconjunto más pequeño de compatibilidad de CPU. Consulte la Guía de instalación de NSX-T Data Center para obtener más información.

  • Para averiguar qué idiomas están disponibles en vSphere with Tanzu, visite la sección sobre internacionalización de las notas de la versión de vSphere 7.0. Estos son los mismos idiomas que VMware proporciona para vSphere.

  • Para ver los derechos de autor y las licencias de los componentes de código abierto de vSphere with Tanzu, visite la sección sobre código abierto de las notas de la versión de vSphere 7.0. Las notas de la versión de vSphere 7.0 también le indican dónde descargar los componentes de código abierto de vSphere.

Problemas resueltos

  • La tarjeta de servicio de máquina virtual de la página Resumen de espacios de nombres desaparece después de una actualización de vCenter a la versión vCenter Server 7.0 Update 2c

    Después de actualizar vCenter de la versión vCenter Server 7.0 Update 2a a vCenter Server 7.0 Update 2c, los espacios de nombres existentes que se crearon antes de la actualización no muestran la tarjeta Bibliotecas de contenido y clase de máquina virtual en la vista Resumen de espacios de nombres. Esto es específico del origen vCenter Server 7.0 Update 2a y no debe afectar a la actualización desde versiones anteriores como vCenter Server 7.0 Update 2

    Para los espacios de nombres afectados, la actualización del clúster supervisor debe restaurar las tarjetas en la vista Resumen de espacios de nombres

  • Pueden producirse errores en ciertas operaciones en máquinas virtuales creadas con Servicio de máquina virtual debido a una versión de hardware incompatible de estas máquinas

    Se producirá un error en las operaciones de las máquinas virtuales si la correspondiente versión de hardware de la imagen de OVF no es compatible con dichas operaciones. Por ejemplo, si una imagen tiene la versión de hardware virtual vmx-11, se producirá el siguiente error al asociar un volumen persistente:

    Attach a virtual disk: The device or operation specified at index '-1' is not supported for the current virtual machine version 'vmx-11'. A minimum version of 'vmx-13' is required for this operation to succeed

    Solución alternativa: Ninguna

  • Durante la actualización del clúster supervisor, es posible que se creen pods de vSphere adicionales y se queden bloqueados con el estado pendiente si se utiliza el conjunto de daemons

    Durante la actualización del clúster supervisor, el controlador del conjunto de daemons crea pods de vSphere adicionales para cada nodo de plano de control de supervisor. Esto se debe a un problema de Kubernetes anterior en el flujo de trabajo.

    Solución alternativa: Agregue NodeSelector/NodeAffinity a la especificación del pod de vSphere, de modo que el controlador del conjunto de daemons pueda omitir los nodos de plano de control al crear pods.

  • Error intermitente al crear pods:

    Algunos entornos han informado de que la creación de pods falla de forma intermitente y aparece el error ""No se pudo obtener la imagen". Se agotó el tiempo de espera de conexión con un error No hay una ruta al host". Se debe a un tiempo de espera predeterminado de 3 segundos durante la solicitud de recuperación de imágenes.

    Póngase en contacto con GSS para aumentar el valor del tiempo de espera predeterminado.

  • El servicio de supervisor puede bloquearse si VC tiene una gran cantidad de hosts desconectados:

    En entornos donde muchos hosts están desconectados debido a un nombre de usuario y una contraseña incorrectos, es posible que el servicio de supervisor se haya bloqueado y no pueda activarse de nuevo.

    Este problema se solucionó en la versión más reciente.

  • Es posible que se produzca un error al configurar un clúster supervisor con NSX-T Data Center en vCenter Server 7.0 Update 3

    Es posible que, al configurar un clúster supervisor con NSX-T Data Center, no se pueda instalar el VIB de Spherelet en hosts ESXi y se muestre el siguiente error:

    Could not find a trusted signer: self signed certificate

    Se incluye un VIB de Spherelet autofirmado con vCenter Server 7.0 Update 3. Sin embargo, si el arranque seguro no está habilitado en el host ESXi que forma parte del clúster de vSphere o los hosts no tienen vSphere Life Cycle Manager (vLCM) habilitado en el clúster, la operación de habilitación del clúster supervisor se realizará correctamente. Este problema ya se solucionó en la versión más reciente.

  • La actualización de vCenter a 70u3f no se realizó correctamente porque el servicio WCP no se inició

    Consulte el artículo 89010 de la base de conocimientos

    Esta solución alternativa se puede aplicar directamente en vCenter Server 7.0u3f, que es el estado de error, o bien en vCenter Server 7.0u3d, que es antes de iniciar la actualización a 7.0u3f.

    1. Conéctese a la sesión SSH de vCenter Server con credenciales raíz.

    2. Conéctese a la base de datos de WCP mediante el siguiente comando:

    PGPASSFILE=/etc/vmware/wcp/.pgpass /opt/vmware/vpostgres/current/bin/psql -d VCDB -U wcpuser -h localhost

    3. Ejecute el siguiente comando para comprobar las entradas cuyo instance_id es nulo:

    SELECT cluster, instance_id FROM cluster_db_configs WHERE instance_id is NULL;

    4. Actualice instance_id en cluster_db_configs a un UUID aleatorio donde sea nulo:

    UPDATE cluster_db_configs SET instance_id=gen_random_uuid() WHERE instance_id is NULL;

    5. El servicio WCP (y cualquier otro servicio que no se haya iniciado después de la actualización) debe reiniciarse una vez que se haya solucionado la entrada de la base de datos.

    service-control --status --all

    service-control --restart --all (--stop or --start)

    o

    service-control --restart wcp (--stop or --start)

    6. Vuelva a ejecutar los pasos 2 y 3 para comprobar que instance_id no sea NULO (NULL). Ahora vCenter Server debería estar en funcionamiento.

    7. En esta etapa, si el usuario aplicó esta solución alternativa en vCenter Server 70u3d, continúe con la actualización a vCenter Server 70u3f, o si aplicó la solución alternativa en vCenter Server 70u3f, visite la interfaz de administración de dispositivos de VMware (VAMI) o el instalador de CLI y reanude la actualización.

  • Es posible que la función de directiva de seguridad no esté disponible después de la actualización

    Si NSX-T 3.1.x/3.0.x está presente y se actualiza vCenter seguido del supervisor y, por último, NSX-T a la versión 3.2 o superior, es posible que la función SecurityPolicy no esté disponible porque NCP no estaba al tanto de la actualización de NSX-T.

  • Rendimiento de red mejorado en máquinas virtuales de clúster de Tanzu Kubernetes Grid que utilizan Antrea-ENCAP con LRO activada

    Se agregaron optimizaciones de ruta de datos para mejorar el rendimiento de la red en los clústeres de Tanzu Kubernetes Grid que utilizan Antrea-ENCAP con la LRO habilitada.

    Ninguno

  • Habilitar el registro de Harbor integrado en el supervisor puede provocar una configuración predeterminada no segura

    Si completó los pasos descritos en "Habilitar el registro de Harbor integrado en el clúster supervisor", es posible que haya una configuración predeterminada no segura en el registro de Harbor integrado. Puede obtener más información al respecto en el artículo 91452 de la base de conocimientos de VMware.

    Solución alternativa: El problema se puede resolver instalando esta versión o implementando una solución alternativa temporal, como se describe en el artículo 91452 de la base de conocimientos.

Problemas conocidos

Los problemas conocidos se agrupan del siguiente modo:

Clúster supervisor

  • <span style="color:#FF0000">NUEVO:</span> 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.

  • Cuando se mueve un nodo ESXi desconectado de un clúster, pero permanece en el mismo centro de datos, los pods y las PVC que se ejecutan en el nodo permanecen en estado de finalización

    Si un host ESXi está en estado No responde debido a PSOD y se mueve dicho host fuera del clúster, en el mismo centro de datos, los pods y las PVC que se ejecutan en el host se bloquean en estado de finalización. El problema se produce incluso cuando hay un nodo de reserva disponible en el clúster.

    Este problema suele aparecer cuando ocurre lo siguiente:

    1. Se habilita el servicio de partners en el clúster supervisor y se crean instancias del servicio.

    2. Un nodo ESXi donde se ejecutan las instancias de servicio experimenta PSOD.

    3. Se desconecta el host que no responde y se mueve fuera del clúster en el mismo centro de datos.

      Cuando el host está fuera del clúster, puede observar que los pods y las PVC presentes en el nodo permanecen en estado de finalización.

    Solución alternativa: Elimine el host del inventario en lugar de sacarlo del clúster en el mismo centro de datos.

  • En ocasiones, se produce un error en la creación de un pod en un clúster supervisor cuando DRS está establecido en modo manual

    Los clústeres donde se habilita la administración de cargas de trabajo también deben tener habilitado HA y DRS automatizado. Si se habilita la administración de cargas de trabajo en los clústeres donde HA y DRS no están habilitados o donde DRS se está ejecutando en modo manual, puede producirse un comportamiento incoherente y errores en la creación del pod.

    Solución alternativa: Habilite DRS en el clúster y configúrelo en Totalmente automatizado o Parcialmente automatizado. Asimismo, asegúrese de que HA esté habilitado en el clúster.

  • Se muestra la clase de almacenamiento cuando se ejecuta kubectl get sc, incluso después de eliminar la directiva de almacenamiento correspondiente

    Si ejecuta kubectl get sc después de crear la directiva de almacenamiento y agregar la directiva a un espacio de nombres, a continuación, se elimina la directiva; la respuesta de comando seguirá mostrando la clase de almacenamiento correspondiente.

    Solución alternativa: Ejecute kubectl describe namespace para ver las clases de almacenamiento que se asocian realmente al espacio de nombres.

  • Se devuelven todas las clases de almacenamiento al ejecutar kubectl describen storage-class o kubectl get storage-class en un clúster supervisor en lugar de solo las del espacio de nombres de supervisor

    Cuando se ejecutan los comandos kubectl describe storage-class o kubectl get storage-class en un clúster supervisor, el comando devuelve todas las clases de almacenamiento en lugar de solo las del espacio de nombres de supervisor.

    Solución alternativa: Deduzca los nombres de clase de almacenamiento asociados con el espacio de nombres a partir del nombre detallado de la cuota.

  • El botón Compartir endpoint de API de Kubernetes ignora el FQDN, aunque esté configurado

    Incluso si el FQDN está configurado para la IP del plano de control de Kubernetes del espacio de nombres del clúster supervisor, el botón Compartir espacio de nombres proporciona la dirección IP en lugar del FQDN.

    Solución alternativa: Comparta manualmente el espacio de nombres del clúster supervisor con el FQDN.

  • No se puede acceder al equilibrador de carga a través del inicio de sesión de kubectl vSphere

    No se puede acceder al servidor de API a través del inicio de sesión de kubectl vSphere cuando se utiliza un endpoint con equilibrio de carga.

    Solución alternativa: Este problema puede manifestarse de dos maneras.

    1. Compruebe si se puede acceder al servidor de API a través del plano de control <curl -k https://vip:6443 (o 443)>

      1. Si no puede acceder al equilibrador de carga desde el servidor de API, significa que este último aún no está activo.

      2. Solución alternativa: Espere unos minutos hasta que se pueda acceder al servidor de API.

    2. Compruebe si el estado del nodo de la máquina virtual de Edge está activo.

      1. Inicie sesión en NSX Manager.

      2. Vaya a Sistema > Tejido > Nodos > Nodos de transporte Edge. El estado del nodo debe ser activo.

      3. Vaya a Redes > Equilibradores de carga > Servidores virtuales. Busque las direcciones VIP que finalicen en kube-apiserver-lb-svc-6443 y kube-apiserver-lb-svc-443. Si su estado no está activo, utilice la siguiente solución alternativa.

      4. Solución alternativa: Reinicie la máquina virtual de Edge. La máquina virtual de Edge se volverá a configurar después del reinicio.

  • La configuración de un clúster de vSphere with Tanzu muestra errores de tiempo de espera agotado durante la configuración

    Durante la configuración del clúster, es posible que se muestren los siguientes mensajes de error:

    Api request to param0 failed

    o

    Config operation for param0 node VM timed out

    Solución alternativa: Ninguna. La habilitación de vSphere with Tanzu puede demorar entre 30 y 60 minutos. Estos mensajes de tiempo de espera agotado para param0 o mensajes similares no se tratan de errores y se pueden ignorar de forma segura.

  • Deshabilitar y volver a habilitar inmediatamente un servicio de vSphere en vSphere with Tanzu hace que el espacio de nombres correspondiente en vCenter Server deje de responder.

    Cuando se deshabilita el servicio de vSphere y se vuelve a habilitar inmediatamente, el espacio de nombres en el clúster supervisor se elimina y se vuelve a crear. Sin embargo, el espacio de nombres correspondiente en vCenter Server permanece en estado "Finalizando". Como resultado, no se pueden asignar cuotas de recursos al espacio de nombres en vCenter Server, y los ingenieros de desarrollo y operaciones no pueden crear recursos como pods y PVC en el espacio de nombres. Además, se produce un error en la implementación del complemento de interfaz de usuario porque no se puede ejecutar el pod del operador de servicio.

    Puede obtener los registros de la plataforma de aplicaciones ejecutando el siguiente comando en el clúster supervisor: kubectl -n vmware-system-appplatform-operator-system logs vmware-system-appplatform-operator-mgr-0.

    Solución alternativa:

    Antes de volver a habilitar el servicio, espere a que el espacio de nombres se elimine por completo de vCenter Server.

    Si el espacio de nombres se bloquea en el estado de finalización, realice los siguientes pasos:

    1. Vuelva a deshabilitar el servicio.

    2. Reinicie el servicio wcp en vCenter Server.

    3. Espere a que se elimine el espacio de nombres. Este paso puede tardar algún tiempo.

    4. Vuelva a habilitar el servicio.

  • Se produce un error al habilitar el registro de contenedor

    Cuando el usuario habilita el registro de contenedor desde la interfaz de usuario, se produce un error debido a que se agota el tiempo de espera en la acción de habilitación después de 10 minutos.

    Solución alternativa: Deshabilite el registro de contenedor y vuelva a intentar la habilitación. Tenga en cuenta que es posible que se vuelva a producir un error de tiempo de espera.

  • Se produce un error al habilitar un clúster después de deshabilitarlo

    Habilitar un clúster poco después de deshabilitarlo puede crear un conflicto en el proceso de restablecimiento de la contraseña de la cuenta del servicio. Se produce un error en la acción de habilitación.

    Solución alternativa: Reinicie mediante el comando vmon-cli --restart wcp.

  • La eliminación de una etiqueta de imagen del contenedor en un registro de contenedor integrado puede eliminar todas las etiquetas de imagen que comparten la misma imagen del contenedor físico

    Se pueden insertar varias imágenes con diferentes etiquetas en un proyecto de un registro de contenedor integrado a partir de la misma imagen del contenedor. Si se elimina una de las imágenes del proyecto, se eliminarán todas las demás imágenes con etiquetas diferentes que se inserten desde la misma imagen.

    Solución alternativa: La operación no se puede deshacer. Vuelva a insertar la imagen en el proyecto.

  • La operación de purga con errores en un proyecto de registro da como resultado que el proyecto se encuentre en el estado de 'error'

    Cuando se realiza una operación de purga en un proyecto de registro, el proyecto se muestra temporalmente como si estuviera en un estado de error. No podrá insertar ni extraer imágenes de ese proyecto. En intervalos regulares, el proyecto se comprobará, y se eliminarán y se volverán a crear todos los proyectos que tengan estado de error. Cuando esto ocurre, todos los miembros del proyecto previo se volverán a agregar al proyecto que se volvió a crear, y todos los repositorios y las imágenes que existían anteriormente en el proyecto se eliminarán; esto completará de forma efectiva la operación de purga.

    Solución alternativa: Ninguna.

  • Se produce un error en la habilitación del registro de contenedor cuando la capacidad de almacenamiento es inferior a 2.000 mebibytes

    Existe un requisito mínimo de capacidad de almacenamiento total para el registro de contenedor, que se conoce como el campo "límite" en VMODL. Esto se debe a que algunos pods de Kubernetes necesitan suficiente espacio de almacenamiento para funcionar correctamente. Para obtener la funcionalidad del registro de contenedor, la capacidad mínima es de 5 gigabytes. Tenga en cuenta que este límite no ofrece ninguna garantía de rendimiento mejorado ni mayor cantidad o tamaño de las imágenes que se pueden admitir.

    Solución alternativa: Este problema se puede evitar si se implementa el registro de contenedor con una capacidad total más grande. El volumen de almacenamiento recomendado no de 5 gigabytes como mínimo.

  • Si reemplaza el certificado TLS del equilibrador de carga de NSX por un clúster de Kubernetes, es posible que no pueda iniciar sesión en el registro de Harbor integrado desde un cliente de Docker o la interfaz de usuario de Harbor

    Para reemplazar el certificado TLS del equilibrador de carga de NSX por un clúster de Kubernetes, desplácese hasta Configurar > Espacios de nombres > Certificados > Equilibrador de carga de NSX > Acciones en la interfaz de usuario de vSphere y haga clic en Reemplazar certificado. Cuando se reemplaza el certificado de NSX, en la operación de inicio de sesión en el registro de Harbor integrado desde un cliente de Docker o la interfaz de usuario de Harbor se pueden producir los errores unauthorized: authentication required o Invalid user name or password.

    Solución alternativa: Reinicie el pod del agente de registro en el espacio de nombres vmware-system-registry:

    1. Ejecute el comando kubectl get pod -n vmware-system-registry.

    2. Elimine la salida del pod mediante la ejecución del comando kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry .

    3. Espere hasta que se reinicie el pod.

  • Los pods implementados con DNSDefault utilizarán la configuración de clusterDNS

    Cualquier pod de vSphere implementado en clústeres supervisor que emplean DNSDefault recurrirán al uso de la instancia de clusterDNS configurada para el clúster.

    Solución alternativa: Ninguna.

  • Es posible que todos los hosts de un clúster se actualicen al mismo tiempo al actualizar un clúster supervisor

    En determinados casos, todos los hosts de un clúster se actualizarán en paralelo durante el proceso de actualización del clúster supervisor. Esto provocará un tiempo de inactividad en todos los pods que se ejecutan en este clúster.

    Solución alternativa: Durante la actualización del clúster supervisor, no reinicie wcpsvc ni elimine o agregue hosts.

  • La actualización del clúster supervisor puede paralizarse de forma indefinida si se utiliza VMCA como entidad de certificación intermedia

    La actualización del clúster supervisor puede paralizarse de forma indefinida en el estado "Configurando" si se utiliza VMCA como entidad de certificación intermedia.

    Solución alternativa: Utilice una entidad de certificación que no sea intermedia para VMCA y elimine las máquinas virtuales del plano de control paralizadas en el estado "Configurando".

  • Se producirá un error en la implementación del pod de vSphere si se asigna una directiva de almacenamiento con cifrado habilitado para los discos efímeros del pod

    Si se utiliza una directiva de almacenamiento con cifrado habilitado para los discos efímeros del pod, la creación de pods de vSphere generará el error "Error de AttachVolume.Attach para el volumen".

    Solución alternativa: Use una directiva de almacenamiento sin cifrado para los discos efímeros del pod.

  • La actualización del clúster supervisor deja de responder cuando alcanza el 50 % durante el paso de actualización del host de la actualización del clúster de espacios de nombres

    El problema se produce cuando un pod de vSphere deja de responder en el estado FINALIZACIÓN durante la actualización del nodo de plano de control de Kubernetes. El controlador del nodo de plano de control intenta actualizar el proceso de Spherelet y, durante esa fase, los pods de vSphere se expulsan o se eliminan en ese nodo de plano de control para eliminar del registro el nodo del plano de control de Kubernetes. Por esta razón, la actualización del clúster supervisor deja de responder en una versión anterior hasta que los pods de vSphere con el estado FINALIZACIÓN se eliminan del inventario.

    Solución alternativa:

    1. Inicie sesión en el host ESXi en el que el pod de vSphere está bloqueado con el estado FINALIZACIÓN.

    2. Elimine los pods de vSphere con el estado FINALIZACIÓN mediante los siguientes comandos:

    # vim-cmd vmsvc/getallvms

    # vim-cmd vmsvc/destroy

    Después de este paso, los pods de vSphere se muestran con un estado huérfano en vSphere Client.

    3. Elimine los pods de vSphere huérfanos. Para ello, agregue primero un usuario al grupo ServiceProviderUsers.

    a) Inicie sesión en vSphere Client, seleccione Administración -> Usuarios y grupos -> Crear usuario y haga clic en Grupos.

    b) Busque el grupo ServiceProviderUsers o Administrators, y agregue un usuario al grupo.

    4. Inicie sesión en vSphere Client con el usuario que acaba de crear y elimine los pods de vSphere huérfanos.

    5. En kubectl, use el siguiente comando:

    kubectl patch pod -p -n '{"metadata":{"finalizers":null}}'

  • La interfaz de usuario de administración de cargas de trabajo muestra el siguiente error de licencia: Ninguno de los hosts conectados a esta instancia de vCenter tiene licencia para la administración de cargas de trabajo

    Después de habilitar correctamente la administración de cargas de trabajo en un clúster de vSphere, es posible que vea el siguiente error de licencia después de reiniciar vCenter Server o actualizar los hosts ESXi donde la administración de cargas de trabajo está habilitada: Ninguno de los hosts conectados a esta instancia de vCenter tiene licencia para la administración de cargas de trabajo. Este es un error cosmético de la interfaz de usuario. La licencia seguirá siendo válida y las cargas de trabajo seguirán ejecutándose.

    Solución alternativa: Los usuarios deben borrar la caché del explorador para vSphere Client.

  • Es posible que los entornos de vSphere de gran tamaño tarden mucho tiempo en sincronizarse en una nube con la controladora de VMware NSX Advanced Load Balancer

    Los entornos de vSphere con inventarios que contienen más de 2.000 hosts ESXi y 45.000 máquinas virtuales pueden tardar hasta 2 horas en sincronizarse en una nube mediante una controladora de NSX Advanced Load Balancer.

    Solución alternativa: ninguna

  • El registro del contenedor privado del clúster supervisor puede estar en mal estado después de cambiar el certificado raíz de VMware Certificate Authority (VMCA) en una instancia de vCenter Server 7.0 Update 2

    Después de cambiar el certificado raíz de VMware Certificate Authority (VMCA) en un sistema vCenter Server 7.0 Update 2, el registro del contenedor privado del clúster supervisor puede tener un estado incorrecto y las operaciones de registro pueden dejar de funcionar según lo esperado. El siguiente mensaje de estado del registro del contenedor se muestra en la interfaz de usuario de configuración del clúster:

    Harbor registry harbor-1560339792 on cluster domain-c8 is unhealthy. Reason: failed to get harbor health: Get https://30.0.248.2/api/health: x509: certificate signed by unknown authority

    Solución alternativa:

    Reinicie el pod del agente de registro manualmente en el espacio de nombres vmware-system-registry en el clúster de Kubernetes de vSphere:

    1. Ejecute el comando kubectl get pod -n vmware-system-registry para obtener el pod del agente de registro.

    2. Ejecute el comando kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry para eliminar la salida del pod.

    3. Espere hasta que se reinicie el pod.

    4. Actualice el registro de imágenes en la interfaz de usuario de configuración del clúster y el estado de mantenimiento debería aparecer como en ejecución en breve.

  • Los proyectos de espacios de nombres creados recientemente en el clúster supervisor no se crean automáticamente en el registro del contenedor privado

    Es posible que los proyectos no se creen automáticamente en el registro del contenedor privado para los espacios de nombres que se acaben de crear en un clúster supervisor. El estado del registro del contenedor sigue apareciendo como correcto, pero no se muestran proyectos en el registro de contenedores del clúster cuando se crea un espacio de nombres nuevo. No se pueden insertar ni extraer imágenes en los proyectos de los espacios de nombres nuevos en el registro del contenedor.

    Solución alternativa:

    1. Ejecute el comando kubectl get pod -n vmware-system-registry para obtener el pod del agente de registro.

    2. Ejecute el comando kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry para eliminar la salida del pod.

    3. Espere hasta que se reinicie el pod.

    4. Inicie sesión en el registro del contenedor privado para comprobar que se hayan creado los proyectos para los espacios de nombres del clúster.

  • Es posible que observe ErrImgPull al crear pods con 10 réplicas

    Es posible que tenga este problema cuando intente utilizar una implementación con pods con 10 réplicas en un archivo YAML. Cuando se intenta crear con este YAML mediante el registro del contenedor privado, de 10 réplicas, al menos pueden aprobarse 7 y 3 pueden fallar con el problema "ErrImgPull".

    Solución alternativa: Utilice conjuntos de réplicas más pequeños, con 5 como máximo.

  • La controladora de NSX Advanced Load Balancer no se admite cuando vCenter Server se implementa con un puerto personalizado

    No se puede registrar vCenter Server con la controladora de NSX Advanced Load Balancer porque no existe ninguna opción para proporcionar un puerto de vCenter Server personalizado en la interfaz de usuario de la controladora de NSX Advanced Load Balanced durante el registro.

    La controladora de NSX Advanced Load Balancer solo funciona cuando vCenter Server se implementa con los puertos predeterminados 80 y 443.

  • Al realizar el redireccionamiento de dominio en una instancia de vCenter Server que ya contiene clústeres supervisores en ejecución, los clústeres supervisores pasarán al estado Configurando

    El redireccionamiento de dominios no se admite en instancias de vCenter Server que tengan clústeres supervisores. Al intentar realizar el redireccionamiento del dominio, los clústeres supervisores existentes pasarán al estado Configurando y las máquinas virtuales del plano de control y del clúster de Tanzu Kubernetes dejarán de aparecer en el inventario en la vista Hosts y clústeres.

    Solución alternativa: Ninguna

  • La asignación de etiquetas y atributos personalizados no funciona para las máquinas virtuales creadas mediante Kubernetes en un clúster supervisor

    Cuando se intenta asignar etiquetas o atributos personalizados a una máquina virtual creada en un clúster de supervisor mediante el cliente de interfaz de usuario de vSphere o el complemento API de vCloud Suite (vCloud Suite API, vAPI), se produce un error en la operación y aparece el mensaje "Error al asignar etiquetas".

    Solución alternativa: Ninguna

  • Los desarrolladores con permiso para utilizar espacios de nombres de autoservicio no pueden acceder a recursos en el ámbito del clúster (como las clases de almacenamiento)

    Los desarrolladores pueden intentar enumerar clases de almacenamiento en el ámbito del clúster con el comando kubectl

    kubectl get storageclass -n test-ns or kubectl get storageclass

    Seguidamente, se produce el siguiente error:

    Error from server (Forbidden): storageclasses.storage.k8s.io is forbidden: User "<sso:DEVUSER@DOMAIN>" cannot list resource "storageclasses" in API group "storage.k8s.io" at the cluster scope

    Solución alternativa: Este es el comportamiento esperado, ya que los desarrolladores solo tienen acceso a las clases de almacenamiento asignadas a la plantilla de espacio de nombres a la que pueden acceder, tal y como determina previamente el administrador de vSphere.

    Puede enumerar las clases de almacenamiento asociadas al espacio de nombres con el comando siguiente:

    kubectl get resourcequota <NAMESPACE>-storagequota -n <NAMESPACE>

  • Se produce un error al utilizar "kubectl apply -f" para realizar el autoservicio de un espacio de nombres

    Si se intenta crear un espacio de nombres mediante un manifiesto con kubectl apply -f , se produce un error en la operación y aparece el siguiente mensaje:

    Error from server (Forbidden): namespaces is forbidden: User "sso:[email protected]"cannot list resource "namespaces"inAPI group ""at the cluster scope

    Solución alternativa: En su lugar, los desarrolladores pueden crear un espacio de nombres con el comando kubectl create -f .

  • Se produce un error intermitente al crear pods de vSphere en un espacio de nombres de autoservicio

    Si intenta crear un pod de vSphere en un espacio de nombres generado con la plantilla de espacio de nombres de autoservicio, puede aparecer un mensaje que indica que no se pueden crear pods del recurso.

    Solución alternativa: Espere unos segundos tras generar el espacio de nombres para crear pods de vSphere en él.

  • Los desarrolladores no pueden agregar etiquetas ni anotaciones a los espacios de nombres creados con la plantilla de espacio de nombres de autoservicio

    Si se intenta especificar etiquetas y anotaciones en el manifiesto utilizado para crear o modificar un espacio de nombres con el comando kubectl apply -f , se produce el siguiente error:

    Error from server (Forbidden): User "sso:[email protected]"cannot patch resource "namespaces"inAPI group ""inthe namespace ""

    Solución alternativa: En su lugar, agregue las etiquetas y anotaciones necesarias al manifiesto del espacio de nombres con kubectl create -f .

  • No se puede utilizar la plantilla de espacio de nombres hasta que se ejecute una actualización del clúster supervisor

    Cuando se inicia una actualización del clúster supervisor, cualquier tarea relacionada con la plantilla de espacio de nombres, como la activación, la desactivación o las actualizaciones, permanece en una cola hasta que se completa la actualización.

    Solución alternativa: Espere a que se complete la operación de actualización antes de ejecutar comandos para manipular la plantilla de espacio de nombres.

  • Se produce un error al intentar asociar un volumen persistente a un pod en un clúster de Tanzu Kubernetes con el mensaje "CNS: Failed to attach disk because missing SCSI controller” error message

    Cuando se intenta asociar un volumen persistente a un pod en un clúster de Tanzu Kubernetes, se produce un error en los intentos y el pod permanece en estado pendiente. El mensaje de error indica que falta la controladora SCSI aunque la máquina virtual del nodo de trabajo tenga una controladora PVSCSI configurada.

    Este problema puede producirse cuando la máquina virtual del nodo de trabajo alcanza su límite de volumen de bloque de 60 volúmenes. Sin embargo, Kubernetes ignora los límites de volumen vSphere y programa la creación de volúmenes de bloque en ese nodo.

    Solución alternativa: Agregue un nuevo nodo de trabajo al clúster. Elimine el pod para programar su implementación en el nuevo nodo de trabajo.

  • Eliminar un pod con estado después de una sesión de vCenter Server inactiva e intentar reutilizar o eliminar posteriormente su volumen en el clúster de Tanzu Kubernetes puede provocar errores y un comportamiento impredecible

    Cuando se elimina un pod con estado después de un día o más de estar inactivo, su volumen parece desasociarse correctamente de la máquina virtual del nodo del clúster de Tanzu Kubernetes. Sin embargo, cuando se intenta crear un nuevo pod con estado con ese volumen o se elimina el volumen, se produce un error en los intentos debido a que el volumen aún está asociado a la máquina virtual del nodo en vCenter Server.

    Solución alternativa: Utilice la API de CNS para desasociar el volumen de la máquina virtual del nodo para sincronizar el estado del volumen en el clúster de Tanzu Kubernetes y vCenter Server. Reinicie también la controladora CSI en el clúster supervisor para renovar la sesión inactiva.

  • La actualización del clúster supervisor se bloquea o no se completa debido al agotamiento del rango de IP en la red de cargas de trabajo principal del clúster supervisor (si se utiliza vSphere redes) o los CIDR del pod de la red del clúster de NCP (si se utiliza NSX-T Container Plugin).

    La actualización del clúster supervisor se bloquea en estado pendiente, con el mensaje: "Namespaces cluster upgrade is in provision a new master step".

    Las nuevas máquinas virtuales del plano de control implementadas durante la actualización del clúster solo reciben una interfaz de red. Las máquinas virtuales del plano de control deben tener 2 interfaces de red, una conectada a la red de administración y la otra a la red de cargas de trabajo.

    Algunos pods del sistema, como coredns, que se supone que se implementan en la nueva máquina virtual del plano de control, pueden quedar bloqueados en estado pendiente.

    Solución alternativa: Elimine una pequeña cantidad de cargas de trabajo (máquinas virtuales, podvm, clústeres de TKG) para liberar suficientes direcciones IP para que se complete el proceso de actualización. Se deben liberar al menos 3 direcciones IP.

  • Actualice los pares clave-valor o las credenciales del registro para una configuración de servicio de supervisor

    Es posible que desee cambiar los pares clave-valor del registro de configuración de un servicio de supervisor porque ha introducido credenciales de inicio de sesión incorrectas o porque la contraseña del registro puede haber caducado.

    Solución alternativa:

    1. Cree un nuevo recurso secreto en el clúster supervisor.

    kubectl -n vmware-system-supervisor-services create secret generic new-secret --from-literal=registryName= --from-literal=registryPasswd= --from-literal=registryUsername=

    2. Actualice la referencia de servicio para el recurso de servicio de supervisor.

    # kubectl edit supervisorservice svc-minio -n vmware-system-supervisor-services

    3. Actualice la sesión de spec.config:

    spec:

    config:

    secretNamespace: vmware-system-supervisor-services

    secretRef: new-secret

  • Los complementos de la interfaz de usuario de Tanzu Kubernetes Grid Service y Supervisor Service no funcionan

    Cuando vCenter Server está firmado por un certificado de CA personalizado y el clúster supervisor está habilitado, el complemento de la interfaz de usuario del servicio Tanzu Kubernetes Grid y los complementos de la interfaz de usuario del servicio de supervisor implementados en vSphere Client no funcionan. Los complementos de la interfaz de usuario experimentan problemas de autenticación SSL al intentar comunicarse con sus respectivos servidores back-end en el clúster supervisor. El complemento Tanzu Kubernetes Grid Service muestra el siguiente error:

    The Tanzu Kubernetes Grid Service failed to authenticate with kubernetes; see the browser console for more technical details

    Solución alternativa: Agregue la raíz de confianza en un archivo independiente (no en vmca.pem) en /etc/ssl/certs y vuelva a generar los hash mediante c_rehash. Debe realizar esta acción en las tres máquinas virtuales del plano de control.

    Tenga en cuenta que no se recomienda editar /etc/ssl/certs/vmca.pem, ya que update-controller sobrescribirá el contenido de este archivo en cada sincronización del clúster.

    Tenga en cuenta que, si se vuelve a implementar una de las máquinas virtuales del plano de control en el clúster supervisor (por ejemplo, después de cambiar el tamaño de las máquinas virtuales del plano de control o debido a una operación de reparación), el certificado agregado manualmente a /etc/ssl/certs se perderá y la solución alternativa tendrá que volver a aplicarse a esa máquina virtual.

  • El clúster supervisor deja de responder en el estado de configuración

    Después de configurar un clúster de vSphere como clúster supervisor, el clúster deja de responder en el estado de configuración. No se pueden crear pods de vSphere ni clústeres de Tanzu Kubernetes.

    Solución alternativa: Reinicie el servicio wcp con el siguiente comando:

    vmon-cli restart wcp

    Revise la documentación para obtener instrucciones más detalladas.

  • "kubectl get virtualmachineimages" no devuelve ningún resultado, incluso cuando la biblioteca de contenido asociada se rellena con imágenes de máquina virtual

    Si la biblioteca de contenido que utiliza el servicio de máquina virtual está habilitada con una directiva de seguridad, el servicio de máquina virtual no podrá leer las imágenes y las máquinas virtuales no podrán implementarse mediante imágenes de esta biblioteca de contenido.

    Solución alternativa: Desasocie la biblioteca de contenido con la directiva de seguridad del espacio de nombres de supervisor. Elimine la opción "Directiva de seguridad de OVF predeterminada" de la biblioteca de contenido correspondiente y, a continuación, vuelva a asociar la biblioteca de contenido con el espacio de nombres.

  • Los desarrolladores verán un POWERSTATE incorrecto para las máquinas virtuales con dispositivos de acceso directo y vGPU administrados por el servicio de máquina virtual cuando el host entre en modo de mantenimiento.

    Cuando un host entra en modo de mantenimiento, DRS apagará automáticamente las máquinas virtuales con dispositivos de acceso directo y vGPU administrados por el servicio de máquina virtual. Sin embargo, el resultado de kubectl get vm muestra el estado de energía y las máquinas virtuales anteriores. Esto hace que se muestre POWERSTATE=poweredOn incluso cuando la máquina virtual está apagada en vCenter.

    Ninguna.

  • En un clúster supervisor con configuración de NSX-T, es posible que los hosts ESXi sigan utilizando VIB de Spherelet autofirmados

    Si configuró o actualizó el clúster supervisor con la versión de Kubernetes disponible en vCenter Server 7.0 Update 3 y actualizó aún más la versión de Kubernetes del clúster supervisor a una versión disponible en vCenter Server 7.0 Update 3a, es posible que los hosts ESXi sigan usando VIB de Spherelet autofirmados. Esto se debe a que la versión de los VIB de Spherelet autofirmados instalada en vCenter Server 7.0 Update 3 y vCenter Server 7.0 Update 3a es idéntica. Este problema no se aplica a un clúster supervisor configurado con la pila de redes de vSphere.

    Solución alternativa 1:

    Si el clúster de vSphere no se basa en vSphere Lifecycle Manager, realice los siguientes pasos para obtener los VIB de Spherelet certificados por VMware instalados:

    1. Ponga un host ESXi en modo de mantenimiento y espere hasta que el clúster supervisor lo marque como "no está listo".

    2. Mueva ese host fuera del clúster como host independiente y espere a que los VIB de Spherelet y de NSX-T se desinstalen.

    3. Vuelva a mover el mismo host al clúster, salga del modo de mantenimiento y espere a que los nuevos VIB de Spherelet y NSX-T vuelvan a configurarse.

    4. Repita los pasos anteriores para cada host ESXi dentro del clúster.

    Si el clúster supervisor está habilitado con vSphere Lifecycle Manager, desactive el clúster supervisor y vuelva a configurarlo.

    Solución alternativa 2:

    Una vez que vCenter Server se actualice a vCenter Server 7.0 Update 3a, desactive el clúster supervisor y vuelva a configurarlo. Esto se aplica tanto a los clústeres habilitados con vSphere Lifecycle Manager como a los clústeres no basados en vLCM/VUM.

  • Algunos vSphere Pods muestran un estado NodeAffinity después de reiniciar el host o actualizar el clúster supervisor

    Después de reiniciar el host o actualizar el clúster supervisor, es posible que aparezca el estado NodeAffinity para algunos vSphere Pods. Este comportamiento se debe a un problema de Kubernetes precedente en el que el programador de Kubernetes crea pods redundantes con el estado NodeAffinity en el clúster después del reinicio de kubelet. Este problema no afecta a la funcionalidad del clúster. Para obtener información sobre el problema de Kubernetes precedente, lea https://github.com/kubernetes/kubernetes/issues/92067.

    Solución alternativa: Elimine los pods redundantes con el estado NodeAffinity.

  • El operador del servicio vDPp y los pods de instancia habilitados en vSphere with Tanzu entran en estado pendiente después de actualizar el entorno a la versión 7.0 Update 3e o posterior

    Este problema se produce si la versión del servicio de partners instalada en el clúster supervisor no es compatible con la versión 1.22 de Kubernetes. Después de actualizar el entorno de vSphere with Tanzu a la versión 7.0 Update 3e o posterior conforme con la versión 1.22, el servicio se vuelve incompatible. Como resultado, el operador y los pods de instancia entran en estado pendiente.

    Se produce un error al intentar actualizar el servicio a una versión más reciente.

    Solución alternativa: Actualice el servicio vDPp a una versión compatible con Kubernetes 1.22 antes de actualizar vSphere with Tanzu a la versión 7.0 Update 3e.

  • No se puede completar la actualización automática de un clúster de Kubernetes 1.19.1 a 1.20.8

    En casos excepcionales, la actualización automática de un clúster de Kubernetes 1.19.1 a 1.20.8 puede generar el siguiente error:

    No se encontró la tarea para actualizar. Vuelva a activar la actualización.

    Solución alternativa: Inicie manualmente la actualización del clúster.

  • Las operaciones en el espacio de nombres de supervisor pueden fallar si este se ha reutilizado en un breve período de tiempo:

    Cuando se elimina un espacio de nombres de supervisor y se vuelve a crear con el mismo nombre en un breve período de tiempo, es posible que se produzca un error en las operaciones debido a una entrada no válida en la memoria caché.

    Este problema se solucionó en la versión más reciente.

  • El paquete de soporte de supervisor incluye el paquete de soporte de VC:

    Al generar un paquete de soporte de supervisor, el paquete de soporte de VC no se incluye automáticamente.

    Solucionado en la versión más reciente.

  • El contenido de la lista de comprobación de compatibilidad de red no está localizado.

    Durante la habilitación de la administración de cargas de trabajo, es posible descargar una hoja de lista de comprobación de red. La localización no se aplica a la hoja.

    Solucionado en la versión más reciente.

  • En una configuración de clúster de Tanzu Kubernetes ampliada se han observado problemas de OOM en los pods del sistema WCP capi-kubeadm-control-plane-controller-manager

    Documentado en el artículo de la base de conocimientos

    https://kb.vmware.com/s/article/88914

    Consulte el artículo de la base de conocimientos

  • La actualización del clúster supervisor se bloquea en el paso de actualización de los componentes debido a un error de actualización de TKG o capw.

    Documentado en el artículo de la base de conocimientos

    https://kb.vmware.com/s/article/88854

  • La directiva de seguridad no elimina las reglas actualizadas.

    Si se crea un CR de directiva de seguridad que contenga las reglas A y B y, a continuación, se actualiza la directiva y se cambian las reglas a B y C, la regla A sigue surtiendo efecto.

    Solución alternativa: Eliminar la directiva de seguridad y volver a crearla con reglas actualizadas

  • Los equilibradores de carga y los clústeres de Tanzu Kubernetes no se crean cuando existen dos grupos de motores de servicio (Service Engine, SE) en NSX Advanced Load Balancer.

    Si se agrega un segundo grupo de SE a NSX Advanced Load Balancer con o sin motores de servicio o servicios virtuales asignados a él, se produce un error al crear nuevos clústeres supervisores o clústeres de Tanzu Kubernetes, 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 Advanced Load Balancer:

    "get() devolvió más de un ServiceEngineGroup: devolvió 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.

    Solución alternativa: Solo se debe utilizar el grupo de SE “Default-Group” para crear VirtualService. Elimine todos los demás grupos de SE de NSX Advanced Load Balancer excepto el grupo default-group y reintente la operación.

  • La directiva de seguridad actualizada no surte efecto.

    Si se crea un CR de directiva de seguridad que contenga las reglas A y B y, a continuación, se actualiza y se cambian las reglas a B y C, la regla A sigue surtiendo efecto y no se elimina.

    Solución alternativa: Cree y aplique una nueva directiva que incluya las reglas B y C, y elimine la directiva anterior que contiene A y B.

  • En ocasiones, la API de administración de espacios de nombres puede devolver un error HTTP 500, el cual no permite autorizar una solicitud

    Una solicitud a Administración de cargas de trabajo puede generar errores de forma intermitente. La API devolverá un código de estado 500 y no se procesará ninguna solicitud. Encontrará un mensaje de registro en el que se indique que se produjo un error inesperado durante la autorización. Este problema es intermitente, pero es más probable que se produzca cuando Administración de cargas de trabajo está bajo carga; por ejemplo, cuando se configuran activamente uno o varios supervisores.

    Solución alternativa: Vuelva a intentar la operación que estaba en marcha cuando se produjo el error.

  • De forma intermitente, el clúster supervisor puede permanecer en el estado CONFIGURANDO o ERROR.

    Durante la habilitación, la actualización u otra reimplementación de nodos de un clúster supervisor, este puede permanecer en el estado CONFIGURANDO o ERROR y mostrar el siguiente mensaje de error:

    "Error en la solicitud de API a VMware vCenter Server (vpxd). Detalles 'ServerFaultCode: Se produjo un error general del sistema: los códigos de error de VIX = (1, 0) pueden bloquearse".

    Los registros relevantes se pueden encontrar en: /var/log/vmware/wcp/wcpsvc.log

    Elimine la instancia de vSphere Agent Manager (EAM) correspondiente a la máquina virtual del plano de control que experimenta el problema para forzar la reimplementación del nodo.

  • Las instancias de PV permanecen en estado finalizado después de eliminar correctamente los objetos PVC

    Después de eliminar un objeto PersistentVolumeClaim (PVC), la instancia de PersistentVolume (PV) correspondiente puede permanecer en un estado finalizado en el supervisor. Además, vSphere Client puede mostrar varias tareas "deleteVolume" con errores.

    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.

Redes

  • Se produce un error en la implementación de la máquina virtual de NSX Edge en redes lentas

    Hay un tiempo de espera combinado de 60 minutos para la implementación de OVF de NSX Edge y el registro de la máquina virtual de NSX Edge. En redes o entornos más lentos con un almacenamiento más lento, si el tiempo transcurrido para la implementación y el registro de Edge supera los 60 minutos, se producirá un error en la operación.

    Solución alternativa: Limpie las instancias de Edge y reinicie la implementación.

  • Las instancias de NSX Edge no se actualizan si se cambian la configuración de vCenter Server DNS, NTP o Syslog después de la configuración del clúster

    La configuración de DNS, NTP y Syslog se copia de vCenter Server a las máquinas virtuales de NSX Edge durante la configuración del clúster. Si se cambia cualquiera de estos ajustes de vCenter Server después de la configuración, no se actualizarán las instancias de NSX Edge.

    Solución alternativa: Utilice las API de NSX Manager para actualizar la configuración de DNS, NTP y Syslog de las instancias de NSX Edge.

  • La configuración de la red de administración de NSX Edge solo proporciona la configuración de la subred y la puerta de enlace en grupos de puertos seleccionados

    La lista desplegable de compatibilidad de redes de administración de NSX Edge mostrará la información de la subred y la puerta de enlace solo si hay VMKnic de ESXi configuradas en el host que estén respaldadas por una DVPG en el VDS seleccionado. Si selecciona un grupo de puertos distribuidos sin una VMKnic asociada, debe proporcionar una subred y una puerta de enlace para la configuración de red.

    Solución alternativa: Utilice una de las siguientes configuraciones:

    • Grupo de puertos discretos: aquí no reside actualmente ninguna VMK. Debe proporcionar la información de subred y puerta de enlace adecuada para este grupo de puertos.

    • Grupos de puertos de administración compartida: aquí reside la VMK de administración de hosts ESXi. La información de la subred y de la puerta de enlace se extrae automáticamente.

  • No se puede utilizar VLAN 0 durante la configuración del clúster

    Cuando se intenta utilizar VLAN 0 para la configuración de vínculo superior o endpoints de túnel de superposición, se produce un error en la operación y aparece el siguiente mensaje:

    Argument 'uplink_network vlan' is not a valid VLAN ID for an uplink network. Please use a VLAN ID between 1-4094

    Solución alternativa: Habilite manualmente la compatibilidad con VLAN 0 mediante uno de los siguientes procesos:

    1. Utilice SSH en el VC implementado (root/vmware).

    2. Abra /etc/vmware/wcp/nsxdsvc.yaml. Tendrá contenido similar al siguiente: 

    logging: 
  level: debug
  maxsizemb: 10

    a. Para habilitar la compatibilidad con VLAN 0 en redes de superposición de clústeres de NSX, anexe las siguientes líneas a /etc/vmware/wcp/nsxdsvc.yaml y guarde el archivo.

    experimental:
 supportedvlan: 
  hostoverlay: 
    min: 0 
    max: 4094 
  edgeoverlay: 
    min: 1 
    max: 4094 
  edgeuplink: 
    min: 1 
    max: 4094

    b. Para habilitar la compatibilidad con VLAN 0 en redes de superposición de NSX Edge, anexe las siguientes líneas a /etc/vmware/wcp/nsxdsvc.yaml y guarde el archivo.

    experimental: 
 supportedvlan: 
  hostoverlay: 
    min: 1 
    max: 4094 
  edgeoverlay: 
    min: 0 
    max: 4094 
  edgeuplink: 
    min: 1 
    max: 4094

    c. Para habilitar la compatibilidad con VLAN 0 en redes de vínculo superior de NSX Edge, anexe las siguientes líneas a /etc/vmware/wcp/nsxdsvc.yaml y guarde el archivo.

    experimental: 
 supportedvlan: 
  hostoverlay: 
    min: 1 
    max: 4094 
  edgeoverlay: 
    min: 1 
    max: 4094 
  edgeuplink: 
    min: 0 
    max: 4094

    3. Reinicie el servicio de administración de cargas de trabajo con vmon-cli --restart wcp.

  • vSphere with Tanzu y NSX-T no se pueden habilitar en un clúster en el que esté habilitada la imagen de vSphere Lifecycle Manager

    vSphere with Tanzu y NSX-T no son compatibles con la imagen de vSphere Lifecycle Manager. Solo son compatibles con las líneas base de vSphere Lifecycle Manager. Cuando la imagen de vSphere Lifecycle Manager está habilitada en un clúster, no se puede habilitar vSphere with Tanzu ni NSX-T en ese clúster.

    Solución alternativa: Mueva los hosts a un clúster en el que esté deshabilitada la imagen de vSphere Lifecycle Manager. Debe usar un clúster con líneas base de vSphere Lifecycle Manager. Una vez que se mueven los hosts, puede habilitar NSX-T y, a continuación, vSphere with Tanzu en ese nuevo clúster.

  • Cuando se configuran las redes de vSphere with Tanzu con NSX-T, no se admite "ExternalTrafficPolicy: local"

    En el servicio de Kubernetes de tipo LoadBalancer no se admite la configuración "ExternalTrafficPolicy: local".

    Solución alternativa: Ninguna.

  • Cuando las redes de vSphere with Tanzu se configuran con NSX-T, el número de servicios de tipo LoadBalancer que un clúster de Tanzu Kubernetes puede admitir está limitado por el rango NodePort del clúster supervisor

    Cada instancia de VirtualMachineService de tipo LoadBalancer se traduce en un servicio de Kubernetes de tipo LoadBalancer y un endpoint de Kubernetes. Se puede crear un máximo de 2.767 servicios de Kubernetes de tipo LoadBalancer en un clúster supervisor, incluidos los creados en el propio clúster supervisor y los que se crearon en clústeres de Tanzu Kubernetes.

    Solución alternativa: Ninguna.

  • La controladora de NSX Advanced Load Balancer no admite que se cambie el PNID de vCenter Server

    Una vez que configure el clúster supervisor con NSX Advanced Load Balancer, no podrá cambiar el PNID de vCenter Server.

    Solución alternativa: Si debe cambiar el PNID de vCenter Server, elimine la controladora de NSX Advanced Load Balancer y cambie el PNID de vCenter Server. Después, vuelva a implementar y configurar la controladora de NSX Advanced Load Balancer con el nuevo PNID de vCenter Server.

  • En los entornos de vSphere Distributed Switch (vDS), es posible configurar clústeres de Tanzu Kubernetes con rangos de CIDR de red que se superponen o entran en conflicto con los del clúster supervisor y viceversa, lo que provoca que los componentes no puedan comunicarse.

    En los entornos de vDS, no se realiza ninguna validación de red en tiempo de diseño cuando se configuran los rangos de CIDR para el clúster supervisor o cuando se configuran los rangos de CIDR para los clústeres de Tanzu Kubernetes. Como resultado, pueden surgir dos problemas:

    1) Se crea un clúster supervisor con rangos de CIDR que entran en conflicto con los rangos de CIDR predeterminados reservados para los clústeres de Tanzu Kubernetes.

    2) Se crea un clúster de Tanzu Kubernetes con un rango de CIDR personalizado que se superpone con el rango de CIDR utilizado para los clústeres supervisores.

    Solución alternativa: En los entornos de vDS, cuando se configura un clúster supervisor, no se debe usar ninguno de los rangos de CIDR predeterminados que se utilizan para los clústeres de Tanzu Kubernetes, incluidos 192.168.0.0/16, que está reservado para los servicios, y 10.96.0.0/12, que está reservado para los pods. Consulte también "Parámetros de configuración para los clústeres de Tanzu Kubernetes" en la documentación de vSphere with Tanzu.

    En los entornos de vDS, al crear un clúster de Tanzu Kubernetes, no utilice el mismo rango de CIDR que se utiliza para el clúster supervisor.

  • Se produce un error en la creación de la red virtual del clúster invitado si hay más de 18 etiquetas personalizadas asociadas

    Si el usuario desea crear un clúster invitado y máquinas virtuales en un espacio de nombres correctamente, el usuario puede agregar un máximo de 18 etiquetas personalizadas para el espacio de nombres; de lo contrario, la red virtual para el clúster invitado en el espacio de nombres no se puede crear correctamente.

    Elimine las etiquetas del espacio de nombres hasta que solo haya 18 o menos. El mecanismo de reintento de NCP volverá a intentar crear el espacio de nombres, pero, en función del intervalo, puede tardar hasta 6 horas.

  • Zona de transporte de soporte creada a través de la API de directiva para WCP:

    Si se creó una zona de transporte de NSX a través de la API de directiva, es posible que se haya producido un error en la habilitación del supervisor. Ahora se admite la creación de la zona de transporte de NSX a través de la API de directiva y, al mismo tiempo, la compatibilidad con versiones anteriores de zonas de transporte de NSX creadas con la API de MP.

    Solucionado en la versión más reciente.

  • 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 vSphere with Tanzu, ya que solo admite la opción Default-Cloud. 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.

Almacenamiento

  • <span style="color:#FF0000">NUEVO:</span> Los intentos de ejecutar la operación Quitar disco en un almacén de datos de vSAN Direct generan el error VimFault: no se puede completar la operación

    Por lo general, este error aparece cuando se produce uno de los siguientes escenarios:

    • Como parte de la operación Quitar disco, todos los volúmenes persistentes ubicados en el almacén de datos de vSAN Direct se reubican en otros almacenes de datos de vSAN Direct en el mismo host ESXi. Se puede producir un error en la reubicación si no hay espacio disponible en los almacenes de datos de vSAN Direct de destino. Para evitar este error, asegúrese de que los almacenes de datos de vSAN Direct de destino tengan suficiente espacio de almacenamiento para ejecutar aplicaciones.

    • La operación Quitar disco también puede fallar cuando los almacenes de datos de vSAN Direct de destino en el host ESXi tienen suficiente almacenamiento. Esto puede ocurrir cuando la operación de reubicación del volumen persistente subyacente, generada por la operación Quitar disco principal, tarda más de 30 minutos debido al tamaño del volumen. En este caso, puede observar que la reconfiguración del pod de vSphere subyacente permanece en curso en la vista Tareas.

      El estado en curso indica que, a pesar de que se agota el tiempo de espera de la operación Quitar disco y no se realiza correctamente, la reubicación del volumen persistente subyacente realizada por la reconfiguración del pod de vSphere no se interrumpe.

    Solución alternativa:

    Una vez finalizada la tarea de reconfiguración del pod de vSphere, vuelva a ejecutar la operación Quitar disco. La operación Quitar disco se completa correctamente.

  • La expansión de una PVC del clúster supervisor en modo en línea o sin conexión no da como resultado la expansión de la PVC del clúster de Tanzu Kubernetes correspondiente

    Un pod que utiliza la PVC del clúster de Tanzu Kubernetes no puede utilizar la capacidad expandida de la PVC del clúster supervisor porque no se cambió el tamaño del sistema de archivos.

    Solución alternativa: Cambie el tamaño de la PVC del clúster de Tanzu Kubernetes por otro igual o mayor que el de la PVC del clúster supervisor.

  • Se produce un error de coincidencia de tamaños entre la PVC de TKG aprovisionada de forma estática y el volumen subyacente

    El aprovisionamiento estático en Kubernetes no comprueba si los volúmenes persistente (Persistent Volume, PV) y de respaldo tienen el mismo tamaño. Si crea una PVC de forma estática en un clúster de Tanzu Kubernetes, y su tamaño es inferior al de la PVC del clúster supervisor correspondiente subyacente, es posible que pueda utilizar más espacio que el que solicitó en el PV. Si el tamaño de la PVC creada de forma estática en el clúster de Tanzu Kubernetes es mayor que el de la PVC del clúster supervisor subyacente, puede aparecer el error No space left on device incluso antes de agotar el tamaño solicitado en el PV del clúster de Tanzu Kubernetes.

    Solución alternativa:

    1. En el volumen persistente del clúster de Tanzu Kubernetes, cambie el valor de persistentVolumeReclaimPolicy a Retain.

    2. Anote el valor de volumeHandle correspondiente al PV del clúster de Tanzu Kubernetes y elimine tanto este volumen como la PVC de dicho clúster.

    3. Vuelva a crear la PVC y el PV del clúster de Tanzu Kubernetes de forma estática con el parámetro volumeHandle y establezca el mismo tamaño de almacenamiento que tiene la PVC del clúster supervisor correspondiente.

  • Se produce un error al intentar crear una PVC desde un espacio de nombres de supervisor o un clúster de TKG si el aprovisionador csi.vsphere.vmware.com externo pierde su concesión para la elección de líder

    Si intenta crear una PVC desde un espacio de nombres de supervisor o un clúster de TKG mediante el comando kubectl, es posible que los intentos no tengan éxito. La PVC permanece en estado pendiente. Si describe la PVC, en el campo Eventos se mostrará la siguiente información con un diseño de tabla:

    • Tipo: Normal

    • Motivo: ExternalProvisioning

    • Antigüedad: 56s (x121 over 30m)

    • De: persistentvolume-controller

    • Mensaje: waiting for a volume to be created, either by external provisioner "csi.vsphere.vmware.com" or manually created by system administrator

    Solución alternativa:

    1. Compruebe que se estén ejecutando todos los contenedores del pod vsphere-csi-controller dentro del espacio de nombres vmware-system-csi.

      kubectl describe pod vsphere-csi-controller-pod-name -n vmware-system-csi

    2. Compruebe los registros del aprovisionador externo mediante el siguiente comando.

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

      La siguiente entrada indica que el contenedor del sidecar del aprovisionador externo perdió su elección de líder:

      I0817 14:02:59.582663 1 leaderelection.go:263] failed to renew lease vmware-system-csi/csi-vsphere-vmware-com: failed to tryAcquireOrRenew context deadline exceededF0817 14:02:59.685847 1 leader_election.go:169] stopped leading

    3. Elimine esta instancia de vsphere-csi-controller.

      kubectl delete pod vsphere-csi-controller-pod-name -n vmware-system-csi

    Kubernetes creará una nueva instancia del controlador CSI y se reinicializarán todos los sidecars.

  • Todas las operaciones de PVC, como crear, asociar, desasociar o eliminar un volumen, fallan mientras CSI no se pueda conectar a vCenter Server

    Además de los errores de operación, la información de estado del volumen y el CR de StoragePool no se pueden actualizar en el clúster supervisor. Los registros de CSI y Syncer muestran errores acerca de no poder conectarse a vCenter Server.

    CSI se conecta a vCenter Server como un usuario de solución específico. Wcpsvc rota la contraseña de este usuario de SSO una vez cada 24 horas y la nueva contraseña se transfiere a un secreto que el controlador CSI lee para conectarse a vCenter Server. Si la nueva contraseña no se puede enviar a Secreto, la contraseña obsoleta permanece en el clúster supervisor y el controlador CSI falla en sus operaciones.

    Este problema afecta a la plataforma de persistencia de datos de vSAN y a todas las operaciones de volumen de CSI.

    Solución alternativa:

    Por lo general, el servicio WCP proporciona la contraseña actualizada a CSI que se ejecuta en el clúster de Kubernetes. En ocasiones, la entrega de contraseñas no se produce debido a un problema, por ejemplo, un problema de conectividad o un error en una parte anterior del proceso de sincronización. El CSI sigue utilizando la contraseña anterior y, finalmente, bloquea la cuenta debido a demasiados errores de autenticación.

    Asegúrese de que el clúster de WCP esté en buen estado y en estado en ejecución. No se debe informar de ningún error para ese clúster en la página Administración de cargas de trabajo. Después de resolver los problemas que causan errores en la sincronización, fuerce una actualización de contraseña para desbloquear la cuenta bloqueada.

    Para forzar el restablecimiento de la contraseña:

    1. Detenga wcpsvc:

      vmon-cli -k wcp

    2. Edite la hora de la última rotación de contraseña a un valor pequeño, como por ejemplo 1, cambiando la tercera línea de /etc/vmware/wcp/.storageUser a 1.

    3. Inicie wcpsvc:

      vmon-cli -i wcp

    Wcpsvc restablece la contraseña, lo que desbloquea la cuenta y envía la nueva contraseña al clúster.

VMware Tanzu Kubernetes Grid Service for vSphere

  • Un clúster de Tanzu Kubernetes deja de responder en el estado "Actualizando" después de la actualización del clúster supervisor

    Cuando se actualiza un clúster supervisor, puede activar una actualización gradual de todos los clústeres de Tanzu Kubernetes para propagar cualquier nueva configuración. Durante este proceso, es posible que un clúster de TKC con el estado "En ejecución" deje de responder en la fase "Actualizando". Un clúster de Tanzu Kubernetes con el estado "En ejecución" solo indica la disponibilidad del plano de control y es posible que el plano de control y los nodos de trabajo requeridos no se hayan creado correctamente. Es posible que un clúster de Tanzu Kubernetes semejante no supere las comprobaciones de estado que se realizan durante la actualización gradual que se inicia tras la finalización de la actualización del clúster supervisor. Esto se traduce en que el clúster de Tanzu Kubernetes deje de responder en la fase "Actualizando" y se pueda confirmar si se observan los eventos en los recursos de KubeadmControlPlane asociados con el clúster de Tanzu Kubernetes. Los eventos emitidos por el recurso serán similares al que se muestra a continuación:

    Warning ControlPlaneUnhealthy 2m15s (x1026 over 5h42m) kubeadm-control-plane-controller Waiting for control plane to pass control plane health check to continue reconciliation: machine's (gc-ns-1597045889305/tkg-cluster-3-control-plane-4bz9r) node (tkg-cluster-3-control-plane-4bz9r) was not checked

    Solución alternativa: Ninguna.

  • El clúster de Tanzu Kubernetes invitado sigue teniendo acceso a la directiva de almacenamiento eliminada

    Cuando un administrador de VI elimina una clase de almacenamiento del espacio de nombres de vCenter Server, no se elimina el acceso a esa clase de almacenamiento para ningún clúster de Tanzu Kubernetes que ya la esté utilizando.

    Solución alternativa:

    1. Como administrador de VI, después de eliminar una clase de almacenamiento del espacio de nombres de vCenter Server, cree una nueva directiva de almacenamiento con el mismo nombre.

    2. Vuelva a agregar la directiva de almacenamiento existente, o la que acaba de volver a crear, en el espacio de nombres de supervisor. Las instancias de TanzuKubernetesCluster que utilizan esta clase de almacenamiento ahora deben ser completamente funcionales.

    3. Para cada recurso de TanzuKubernetesCluster que utilice la clase de almacenamiento que desea eliminar, cree una nueva instancia de TanzuKubernetesCluster con una clase de almacenamiento diferente y utilice Velero para migrar las cargas de trabajo al nuevo clúster.

    4. Cuando ninguna instancia de TanzuKubernetesCluster o PersistentVolume utiliza la clase de almacenamiento, se puede eliminar de forma segura.

  • El certificado SSL del registro de contenedor integrado no se copia en los nodos del clúster de Tanzu Kubernetes

    Cuando el registro de contenedor integrado está habilitado para ese clúster supervisor, el certificado SSL de Harbor no se incluye en ningún nodo del clúster de Tanzu Kubernetes creado en ese clúster supervisor y no es posible conectarse al registro desde esos nodos.

    Solución alternativa: Copie y pegue el certificado SSL del plano de control del clúster supervisor en los nodos de trabajo del clúster de Tanzu Kubernetes.

  • Las imágenes de máquina virtual no están disponibles en la biblioteca de contenido

    Cuando se configuran varias instancias de vCenter Server en los ajustes de Embedded Linked Mode, la interfaz de usuario permite al usuario seleccionar una biblioteca de contenido creada en una instancia de vCenter Server diferente. Si se selecciona dicha biblioteca, las imágenes de máquina virtual no estarán disponibles para los usuarios de desarrollo y operaciones con el fin de aprovisionar un clúster de Tanzu Kubernetes. En este caso, `kubectl get virtualmachineimages` no devuelve ningún resultado.

    Solución alternativa: Cuando asocie una biblioteca de contenido con el clúster supervisor para imágenes de máquina virtual del clúster de Tanzu Kubernetes, elija una biblioteca creada en la misma instancia de vCenter Server en la que reside el clúster supervisor. Opcionalmente, cree una biblioteca de contenido local que también admita el aprovisionamiento en entornos aislados de clústeres de Tanzu Kubernetes.

  • No se pueden aprovisionar nuevos clústeres de Tanzu Kubernetes ni escalar horizontalmente clústeres existentes, ya que el suscriptor de la biblioteca de contenido no se puede sincronizar con el publicador.

    Cuando se configura una biblioteca de contenido suscrita para archivos OVA de clúster de Tanzu Kubernetes, se genera un certificado SSL y se le solicita que confíe manualmente en el certificado confirmando la huella digital del certificado. Si se cambia el certificado SSL después de la configuración inicial de la biblioteca, se debe actualizar la huella digital para volver a confiar en el nuevo certificado.

    Edite la configuración de la biblioteca de contenido suscrita. Se iniciará un sondeo de la URL de suscripción aunque no se solicite ningún cambio en la biblioteca. El sondeo detectará que el certificado SSL no es de confianza y le pedirá que confíe en él.

  • Tanzu Kubernetes versión 1.16.8 es incompatible con vCenter Server 7.0 Update 1.

    La versión 1.16.8 de Tanzu Kubernetes es incompatible con vCenter Server 7.0 Update 1. Debe actualizar los clústeres de Tanzu Kubernetes a una versión posterior antes de realizar una actualización de los espacios de nombres de vSphere a U1.

    Antes de realizar una actualización de los espacios de nombres de vSphere a vCenter Server 7.0 Update 1, actualice a una versión posterior cada clúster de Tanzu Kubernetes que ejecute la versión 1.16.8. Consulte la Lista de versiones de Tanzu Kubernetes en la documentación para obtener más información.

  • Después de actualizar el plano de control de carga de trabajo a vCenter Server 7.0 Update 1, los nuevos tamaños de clase de máquina virtual no están disponibles.

    Descripción: Después de actualizar a vSphere 7.0.1 y, a continuación, realizar una actualización de los espacios de nombres de vSphere del clúster supervisor, para los clústeres de Tanzu Kubernetes, al ejecutar el comando "kubectl get virtualmachineclasses" no se enumeran los nuevos tamaños de clase de máquina virtual 2x-large, 4x-large y 8x-large.

    Solución alternativa: Ninguna. Los nuevos tamaños de clase de máquina virtual solo se pueden utilizar con una nueva instalación del plano de control de carga de trabajo.

  • La versión de Tanzu Kubernetes 1.17.11 vmware.1-tkg.1 agota el tiempo de espera para conectarse al servidor DNS del clúster cuando se utiliza la CNI de Calico.

    La versión de Tanzu Kubernetes 1.17.11+vmware.1-tkg.1 tiene un problema con el kernel de Photon OS que impide que la imagen funcione según lo previsto con la CNI de Calico.

    Solución alternativa: En la versión de Tanzu Kubernetes 1.17.11, la imagen identificada como "v1.17.11+vmware.1-tkg.2.ad3d374.516" soluciona el problema con Calico. Para ejecutar Kubernetes 1.17.11, utilice esta versión en lugar de "v1.17.11+vmware.1-tkg.1.15f1e18.489". Como alternativa, utilice una versión de Tanzu Kubernetes diferente, como la versión 1.18.5, 1.17.8 o 1.16.14.

  • Cuando las redes de vSphere with Tanzu se configuran con NSX-T Data Center, al actualizar un servicio de "ExternalTrafficPolicy: Local" a "ExternalTrafficPolicy: Cluster", la IP de este equilibrador de carga se representa como inaccesible en los objetos maestros de virtualización de servidores

    Cuando se crea inicialmente un servicio de Kubernetes de tipo LoadBalancer en clústeres de carga de trabajo con ExternalTrafficPolicy: Local y posteriormente se actualiza a ExternalTrafficPolicy: Cluster, se interrumpe el acceso a la IP de equilibrador de carga de este servicio en las máquinas virtuales del clúster supervisor.

    Solución alternativa: Elimine el servicio y vuelva a crearlo con ExternalTrafficPolicy: Cluster.

  • Uso elevado de CPU en los nodos del plano de control de clústeres de Tanzu Kubernetes

    Existe un problema conocido en el proyecto anterior de Kubernetes donde, en ocasiones, kube-controller-manager entra en un bucle, lo que provoca un uso elevado de CPU que puede afectar a la funcionalidad de los clústeres de Tanzu Kubernetes. Es posible que observe que el proceso kube-controller-manager está consumiendo una cantidad de CPU superior a la esperada y está generando registros repetidos que indican failed for updating Node.Spec.PodCIDRs.

    Solución alternativa: Elimine el pod kube-controller-manager que reside dentro del nodo del plano de control con este problema. El pod se volverá a crear y el problema no debería reaparecer.

  • No se pueden actualizar los clústeres de Tanzu Kubernetes creados con K8s 1.16 a 1.19

    El archivo de configuración de Kubelet se genera en el momento en que kubeadm init se ejecuta y luego se replica durante las actualizaciones del clúster. En el momento de la versión 1.16, kubeadm init genera un archivo de configuración que establece resolvConf en /etc/resolv.conf y que, a continuación, se sobrescribe mediante una marca de línea de comandos --resolv-conf que apunta a /run/systemd/resolve/resolv.conf. En las versiones 1.17 y 1.18, kubeadm sigue configurando Kubelet con el --resolv-conf correcto. A partir de la versión 1.19, kubeadm ya no configura la marca de línea de comandos y, en su lugar, depende del archivo de configuración de Kubelet. Debido al proceso de replicación durante las actualizaciones de clúster, un clúster de la versión 1.19 actualizado desde la 1.16 incluirá un archivo de configuración donde resolvConf apunta a /etc/resolv.conf en lugar de /run/systemd/resolve/resolv.conf.

    Solución alternativa: Antes de actualizar un clúster de Tanzu Kubernetes a la versión 1.19, vuelva a configurar el archivo de configuración de Kubelet para que apunte al resolv.conf correcto. Duplique manualmente el ConfigMap kubelet-config-1.18 como kubelet-config-1.19 en el espacio de nombres kube-system y luego modifique los nuevos datos de ConfigMap's para que resolvConf apunte a /run/systemd/resolve/resolv.conf.

  • Cuando las redes del clúster supervisor están configuradas con NSX-T, después de actualizar un servicio desde "ExternalTrafficPolicy: Local" a "ExternalTrafficPolicy: Cluster", se produce un error en las solicitudes realizadas en los nodos del plano de control del clúster supervisor a la IP del equilibrador de carga de este servicio

    Cuando se crea un servicio en un clúster de Tanzu Kubernetes con ExternalTrafficPolicy: Local y, posteriormente, se actualiza el servicio a ExternalTrafficPolicy: Cluster, kube-proxy crea una regla de tabla de IP de forma incorrecta en los nodos del plano de control del clúster supervisor para bloquear el tráfico destinado a la IP del equilibrador de carga del servicio. Por ejemplo, si este servicio tiene la IP de equilibrador de carga 192.182.40.4, se crea la siguiente regla de tabla de IP en cualquiera de los nodos del plano de control:

    -A KUBE-SERVICES -d 192.182.40.4/32 -p tcp -m comment --comment "antrea-17-171/antrea-17-171-c1-2bfcfe5d9a0cdea4de6eb has no endpoints" -m tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable

    Como resultado, se pierde el acceso a esa dirección IP.

    Solución alternativa: Elimine el servicio y vuelva a crearlo con ExternalTrafficPolicy: Cluster.

  • Después de habilitar la configuración de proxy HTTP y/o de confianza en la especificación TkgServiceConfiguration, todos los clústeres preexistentes sin la configuración proxy o de confianza heredarán la configuración global de proxy/confianza cuando se actualicen.

    Puede editar la especificación TkgServiceConfiguration para configurar el servicio TKG, incluida la especificación de los certificados de CNI, proxy HTTP y confianza predeterminados. Todos los cambios de configuración que realice en la especificación TkgServiceConfiguration se aplican globalmente a cualquier clúster de Tanzu Kuberentes aprovisionado o actualizado por ese servicio. No es posible utilizar configuraciones por clúster para evitar la configuración global.

    Por ejemplo, si edita la especificación TkgServiceConfiguration y habilita un proxy HTTP, todos los nuevos clústeres aprovisionados por ese clúster heredarán esa configuración de proxy. Además, todos los clústeres preexistentes sin un servidor proxy heredarán la configuración de proxy global cuando se modifique o se actualice el clúster. En el caso del proxy HTTP/S, que admite la configuración por clúster, puede actualizar la especificación del clúster con un servidor proxy diferente, pero no puede eliminar la configuración de proxy global. Si el proxy HTTP está establecido globalmente, debe usarlo o sobrescribirlo con un servidor proxy diferente.

    Solución alternativa: Debe comprender que la especificación TkgServiceConfiguration se aplica globalmente. Si no desea que todos los clústeres usen un proxy HTTP, no la habilite a nivel global, sino a nivel de clúster.

  • En implementaciones de clúster supervisor de gran tamaño con muchos clústeres de Tanzu Kubernetes y máquinas virtuales, se pueden producir errores en los pods vmop-controller-manager debido a la falta de memoria, lo que provoca que no se pueda administrar el ciclo de vida de los clústeres de Tanzu Kubernetes

    Dentro del clúster supervisor, el pod vmop-controller-manager es responsable de administrar el ciclo de vida de las máquinas virtuales que conforman los clústeres de Tanzu Kubernetes. Cuando hay un gran número de estas máquinas virtuales (>850 máquinas virtuales por clúster supervisor), el pod vmop-controller-manager puede entrar en CrashLoopBackoff OutOfMemory. Cuando esto ocurre, se interrumpe la administración del ciclo de vida de los clústeres de Tanzu Kubernetes hasta que el pod vmop-controller-manager reanuda las operaciones.

    Reduzca la cantidad total de nodos de trabajo del clúster de Tanzu Kubernetes administrados en un clúster supervisor mediante la eliminación de clústeres o la reducción vertical de clústeres.

  • Si se actualiza desde una versión anterior a la versión 6.5 de vSphere a la versión 7 de vSphere with Tanzu, puede producirse un error que indica que el tipo Photon OS no es compatible

    Si, después de actualizar correctamente un entorno de vSphere 6 a la versión 7 de vSphere with Tanzu, se intenta implementar un clúster de Tanzu Kubernetes, aparece un mensaje de error que indica que Photon OS no es compatible. Este es el mensaje exacto:

    failed to create or update VirtualMachine: admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType vmwarePhoton64Guest on image v1.19.7---vmware.1-tkg.1.fc82c41'

    Si se actualizó a la versión 7 de vSphere with Tanzu desde una versión de vSphere anterior a la 6.5 (por ejemplo, vSphere 6), asegúrese de que el nivel de compatibilidad de máquina virtual predeterminado esté establecido, como mínimo, en "ESXi 6.5 y versiones posteriores", para que Photon OS aparezca como sistema operativo invitado compatible. Para ello, seleccione el clúster de vSphere donde esté habilitada la administración de cargas de trabajo, haga clic con el botón secundario, elija Editar compatibilidad predeterminada de máquina virtual y seleccione "ESXi 6.5 y versiones posteriores".

  • Después de aprovisionar un clúster de Tanzu Kubernetes mediante una máquina virtual de tamaño pequeño y, a continuación, implementar una carga de trabajo en ese clúster, el nodo de trabajador entra en el estado NotReady y en un bucle continuo de intento de reaparecer el nodo.

    Descripción: En un nodo de trabajo pequeño o extra pequeño para un clúster, el proceso /bin/opm puede consumir una porción excesiva de la memoria de la máquina virtual, lo que provoca un error de falta de memoria para el nodo de trabajador.

    Solución alternativa: Evite utilizar la clase de máquina virtual pequeña o extra pequeña para los nodos de trabajo, incluso para el desarrollo efímero o los clústeres de prueba. Como práctica recomendada, la clase de máquina virtual mínima para un nodo de trabajo en cualquier entorno es media. Para obtener más información, consulte Clases de máquinas virtuales predeterminadas en la documentación.

  • La sincronización de las versiones de Tanzu Kubernetes desde una biblioteca de contenido suscrita genera el siguiente mensaje de error de solicitud HTTP: "cannot authenticate SSL certificate for host wp-content.vmware.com."

    Descripción: Cuando se configura una biblioteca de contenido suscrita para OVA de clúster de Tanzu Kubernetes, se genera un certificado SSL para wp-content.vmware.com. Se le pedirá que confíe manualmente en el certificado confirmando la huella digital del certificado. Si se cambia el certificado SSL después de la configuración inicial de la biblioteca, se debe actualizar la huella digital para volver a confiar en el nuevo certificado. El certificado SSL actual de la biblioteca de contenido caduca a finales de junio de 2021. Los clientes que se suscribieron a wp-content.vmware.com verán que se produjo un error en la sincronización de la biblioteca de contenido y necesitan actualizar la huella digital siguiendo los pasos descritos en la solución alternativa. Para obtener orientación adicional, consulte el artículo de la base de conocimientos de VMware asociado en https://kb.vmware.com/s/article/85268.

    Solución alternativa: Inicie sesión en vCenter Server con vSphere Client. Seleccione la biblioteca de contenido suscrita y haga clic en Editar configuración. Esta acción iniciará un sondeo de la URL de suscripción aunque no se solicite ningún cambio en la biblioteca. El sondeo detectará que el certificado SSL no es de confianza y le pedirá que confíe en él. En el menú desplegable Acciones que aparece, seleccione Continuar y se actualizará la huella digital. Ahora puede continuar con la sincronización del contenido de la biblioteca.

  • TKGS no admite la modificación simultánea de la clase de máquina virtual y el escalado vertical de nodos.

    Es posible que los clientes observen errores después de aplicar una actualización al clúster que implica una modificación de VMClass y un escalado vertical del nodo.

    Modifique la configuración de TKC para editar solo uno de los dos campos y volver a aplicar el cambio.

  • Síntoma: Se produjo una actualización gradual inesperada del clúster después de actualizar una etiqueta o una mancha en la especificación del clúster.

    Descripción: Cuando se utiliza la API v1alpha2 de TKGS, la modificación de spec.topology.nodePools[*].labels o spec.topology.nodePools[*].taints de un grupo de nodos activará una actualización gradual de ese grupo de nodos.

    Solución alternativa: Ninguna

  • Síntoma: Después de una actualización del clúster, las manchas y las etiquetas agregadas manualmente a un grupo de nodos ya no están presentes.

    Descripción: Mediante la API v1alpha2 de TKGS, durante una actualización del clúster, el sistema no conserva spec.topology.nodePools[*].taints y spec.topology.nodePools[*].labels, que se agregaron manualmente y estaban presentes antes de la actualización.

    Solución alternativa: Una vez completada la actualización, vuelva a agregar manualmente los campos de etiquetas y manchas.

  • Síntoma: El clúster de Tanzu Kubernetes se bloquea en una fase de creación, ya que una de las máquinas virtuales del plano de control no obtuvo una dirección IP.

    Descripción: El clúster de Tanzu Kubernetes se bloquea en una fase de creación, ya que una de las máquinas virtuales del plano de control no obtuvo una dirección IP.

    Solución alternativa: Utilice Tanzu Kubernetes 1.20.7 o una versión posterior para evitar este problema.

  • Síntoma: Durante la creación de un clúster de Tanzu Kubernetes, el proceso se bloquea en un estado de actualización con el motivo "WaitingForNetworkAddress".

    Descripción: Las máquinas virtuales del plano de control y los nodos de trabajo están encendidos, pero no tienen asignada una dirección IP. Esto puede deberse a que vmware-tools se haya quedado sin memoria y no se reinicie.

    Solución alternativa: El problema específico se solucionó en Tanzu Kubernetes 1.20.7 y versiones posteriores. Además, puede solucionar el problema si aumenta la memoria de la máquina virtual. La clase de máquina virtual best-effort-xsmall solo proporciona 2 G de memoria. Utilice una clase de máquina virtual con más memoria para implementar clústeres de Tanzu Kubernetes.

  • Síntoma: Los espacios de nombres de vSphere de autoservicio se bloquean en el estado "Eliminando".

    Descripción: Después de eliminar un espacio de nombres de vSphere, el proceso se bloquea en el estado "Eliminando" durante varias horas sin progreso.

    Solución alternativa: Utilice kubectl para comprobar si quedan objetos de Kubernetes que aún no se eliminaron del espacio de nombres. Si quedan objetos relacionados con kubeadm-control-plane, reinicie los pods capi-kubeadm-control-plane-controller-manager. Esta acción debería volver a poner en cola los objetos que deben eliminarse.

    NOTA: Esta es una operación avanzada. Póngase en contacto con el soporte de VMware antes de aplicar esta solución alternativa.

  • La API v1alpha2 de TKC no bloquea la creación de TKC con TKr incompatible

    A partir de la versión 7.0.3 MP2, TKr <1.18.x será incompatible, pero la API de TKC sigue permitiendo la creación de TKC con una versión anterior a la 1.18.x, no bloquea la creación de un objeto de TKC cuando se crea con una TKr incompatible. Estos TKC nunca se crearán.

    Elimine los TKC que no estén en estado de ejecución y se crearon con una TKr incompatible. Vuelva a crearlos con una versión compatible.

Plataforma de persistencia de datos de vSAN

  • Un complemento de interfaz de usuario de vDPP no se implementa en vSphere Client y un mensaje de error indica que se intentó descargar el complemento desde un clúster supervisor que ya no existe

    El problema puede producirse cuando se implementa un complemento de interfaz de usuario de vDPP en un clúster y después se elimina dicho clúster. Sin embargo, las entradas obsoletas relacionadas con este complemento de interfaz de usuario de vDPP permanecen en vCenter Extension Manager. Si posteriormente crea un clúster nuevo, se produce un error al intentar instalar la misma versión del complemento de interfaz de usuario de vDPP en este clúster, ya que vSphere Client utiliza las entradas obsoletas para descargar el complemento del antiguo clúster inexistente.

    Solución alternativa:

    1. Desplácese a vCenter Extension Manager mediante https://vc-ip/mob and y busque la extensión del complemento.

    2. Elimine todas las entradas ClientInfo y ServerInfo que contengan el nombre del antiguo clúster.

    3. En la matriz ClientInfo, seleccione ClientInfo con el mayor número de versión y cambie su tipo de vsphere-client-remote-backup a vsphere-client-remote.

  • Un pod de vSphere en un clúster supervisor permanece en estado pendiente sin la anotación vm-uuid

    En ocasiones, un pod puede permanecer en estado pendiente durante mucho tiempo. Esto suele ocurrir cuando se utiliza una plataforma de persistencia de datos de vSAN (vDPP) y puede deberse a un error interno o a acciones del usuario.

    Cuando se utiliza el comando kubectl para consultar la instancia del pod, la anotación vmware-system-vm-uuid/vmware-system-vm-moid falta en las anotaciones de metadatos.

    Solución alternativa: Utilice el comando kubectl delete pod pending_pod_name para eliminar el pod. Si el pod forma parte de un conjunto con estado, el pod se vuelve a crear automáticamente.

  • Una instancia de un servicio de vDPP no se puede implementar cuando las PVC locales del host de sus dos pods de réplica están enlazadas al mismo nodo de clúster

    En ocasiones, una instancia de un servicio de plataforma de persistencia de datos vSAN, como MinIO o Cloudian, puede tener un estado en que sus dos pods de réplica tienen sus PVC locales de host asignadas en el mismo nodo de clúster. Normalmente, ninguna de las dos réplicas de la misma instancia puede tener almacenamiento local de host en el mismo nodo de clúster. Si esto ocurre, uno de los pods de réplica puede permanecer en estado pendiente durante un tiempo indefinido, lo que provoca errores en la implementación de la instancia.

    Los síntomas que observa durante los errores incluyen todos los siguientes:

    • El estado de la instancia es amarillo.

    • Al menos un pod de la instancia permanece en estado pendiente durante más de 10 minutos.

    • El pod pendiente y uno de los pods de réplica en ejecución de la misma instancia tienen sus PVC locales de host asignadas en el mismo nodo del clúster.

    Los escenarios de error que pueden conducir a este problema son los siguientes:

    • Algunos nodos del clúster no tienen suficientes recursos de almacenamiento para la instancia.

    • El número de réplicas es mayor que el número de nodos del clúster. Esto puede deberse a que uno o varios nodos no están disponibles temporalmente.

    Solución alternativa:

    1. Asegúrese de que el clúster tenga suficientes recursos de almacenamiento y que el número de nodos del clúster sea mayor que el recuento de réplicas de la instancia.

    2. Elimine el pod pendiente y todas sus PVC locales de host.

    El operador del servicio debe reconstruir los datos del volumen en el nuevo nodo en el que se programa el pod. Esto puede tardar algún tiempo en completarse, según el tamaño del volumen y la cantidad de datos válidos que contenga.

  • Después de que un nodo ESXi salga del mantenimiento en el modo Garantizar accesibilidad, es posible que la mancha aplicada al nodo durante el mantenimiento permanezca en el nodo

    Este problema podría aparecer al utilizar la plataforma de persistencia de datos vSAN (vDPP) para crear instancias de servicios de partners. Después de que el nodo de ESXi salga del mantenimiento en el modo Garantizar accesibilidad, podrá seguir encontrando la mancha restante node.vmware.com/drain=planned-downtime:NoSchedule en el nodo.

    Por lo general, el problema se produce cuando se llevan a cabo estas acciones:

    1. Un servicio de partners está habilitado en el clúster supervisor y se crean instancias del servicio.

    2. Un nodo ESXi se pone en mantenimiento en modo Garantizar accesibilidad.

    3. El nodo entra correctamente en modo de mantenimiento en Garantizar accesibilidad.

    4. La mancha node.vmware.com/drain=planned-downtime:NoSchedule se aplica al nodo.

    5. El nodo sale del modo de mantenimiento.

    Después de que el nodo salga del modo de mantenimiento, utilice el siguiente comando para asegurarse de que no quede ninguna mancha en el nodo:

    kubectl describe node | grep Taints

    Solución alternativa:

    Si la mancha node.vmware.com/drain=planned-downtime:NoSchedule está presente en el host, elimine manualmente la mancha:

    kubectl taint nodes nodeNamekey=value:Effect-

    Nota: Asegúrese de utilizar un guion al final del comando.

    Siga este ejemplo:

    kubectl taint nodes wdc-10-123-123-1.eng.vmware.com node.vmware.com/drain=planned-downtime:NoSchedule-

  • Después de una recuperación de APD, los pods de servicio persistentes que se ejecutan en la plataforma de persistencia de datos de vSAN podrían permanecer en estado pendiente con errores de AttachVolume

    Después de ADP y de recuperar los hosts ESXi, un pod de la instancia de servicio de vDPP podría permanecer en estado pendiente. Si ejecuta el comando kubectl -n instance_namespace describe pod name_of_pod_in_pending, puede ver los errores de tipo AttachVolume.

    Si el pod permanece en estado pendiente durante más de 15 minutos, es poco probable que salga de ese estado.

    Solución alternativa: Elimine el pod pendiente mediante el siguiente comando: kubectl -n instance_namespace delete pod name_of_pod_in_pending. El pod se vuelve a crear y pasa al estado de ejecución.

Servicio de VM

  • <span style="color:#FF0000">NUEVO:</span> Los intentos de implementar un pod de vSphere y una máquina virtual de servicio de máquina virtual con el mismo nombre causan errores y un comportamiento impredecible

    Es posible que observe fallos y errores u otro comportamiento problemático. Puede experimentar estos problemas cuando tiene un pod de vSphere que se ejecuta en un espacio de nombres e intenta implementar una máquina virtual de servicio de máquina virtual con el mismo nombre en el mismo espacio de nombres o viceversa.

    Solución alternativa: No utilice los mismos nombres para los pods de vSphere y las máquinas virtuales en el mismo espacio de nombres.

  • Hay un conjunto limitado de imágenes de máquina virtual disponibles para su uso con Servicio de máquina virtual

    Si se intenta utilizar una imagen de máquina virtual no compatible con Servicio de máquina virtual, aparece el siguiente mensaje al crear la máquina virtual:

    Error from server (GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image): error when creating : admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image

    Solución alternativa: Utilice solo imágenes de máquina virtual de VMware Marketplace validadas para trabajar con Servicio de máquina virtual

  • No se pueden consumir imágenes de máquina virtual con nombres que no sean compatibles con DNS

    Cuando el nombre de una imagen de OVF de una biblioteca de contenido no es compatible con el nombre de subdominio del servicio de nombres de dominio (Domain Name Service, DNS), el servicio de máquina virtual no crea ningún elemento VirtualMachineImage a partir de la imagen de OVF. Como resultado, kubectl get vmimage no enumera las imágenes en un espacio de nombres y los desarrolladores no pueden consumir esta imagen.

    Solución alternativa: Utilice nombres compatibles con el nombre de subdominio DNS para las imágenes de OVF.

  • Las imágenes de OVF duplicadas no aparecen como imágenes de máquina virtual duplicadas

    Las imágenes de OVF que tienen el mismo nombre en bibliotecas de contenido diferentes no se muestran como imágenes de máquina virtual distintas

    Solución alternativa: Utilice nombres únicos para las imágenes de OVF en las distintas bibliotecas de contenido configuradas con el servicio de máquina virtual.

  • Las máquinas virtuales creadas desde el servicio de máquina virtual no permiten acceder a la consola web o remota

    Las máquinas virtuales creadas desde el servicio de máquina virtual no permiten acceder a la consola remota. Como resultado, los administradores no pueden iniciar sesión en ellas usando las opciones Iniciar la consola web e Iniciar consola remota de vSphere Web Client.

    Solución alternativa: Los administradores pueden acceder a la consola de máquina virtual iniciando sesión en el host ESXi donde se encuentra dicha máquina.

  • Las máquinas virtuales con vGPU y dispositivos de acceso directo administradas por Servicio de máquina virtual se apagan cuando el host ESXi entra en modo de mantenimiento

    Servicio de máquina virtual permite a los ingenieros de desarrollo y operaciones crear máquinas virtuales conectadas a vGPU o dispositivos de acceso directo. Normalmente, cuando un host ESXi entra en modo de mantenimiento, DRS genera una recomendación para las máquinas virtuales que se ejecutan en el host. Un administrador de vSphere puede entonces aceptar la recomendación para activar vMotion.

    Sin embargo, las máquinas virtuales con vGPU y dispositivos de acceso directo administrados por Servicio de máquina virtual se apagan automáticamente. Esto puede afectar temporalmente a las cargas de trabajo que se ejecutan en estas máquinas virtuales. Las máquinas virtuales se encienden automáticamente después de que el host sale del modo de mantenimiento.

    Solución alternativa: Ninguna.

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