VMware NSX Container Plugin 3.1 | 19 de noviembre de 2020 | Compilación 17170700 Compruebe regularmente las adiciones y actualizaciones a este documento. |
Contenido de las notas de la versión
Las notas de la versión contienen los siguientes temas:
Novedades
- Capacidad para especificar una IP de SNAT para una organización de Tanzu Application Service (TAS).
- Compatibilidad con la memoria caché de DNS local del nodo de Tanzu Kubernetes Grid Integrated (TKGI)
- Capacidad para agregar la etiqueta del clúster de Kubernetes en los registros del firewall distribuido para distinguir los registros del firewall procedentes de un clúster de Kubernetes en un entorno de varios tenants.
- Habilita el enrutador de nivel 1 por topología de espacio de nombres de supervisor para vSphere con Tanzu.
- Compatibilidad con la aplicación de licencias de NSX para funciones relacionadas con el contenedor.
Requisitos de compatibilidad
Producto | Versión |
---|---|
Mosaico de NCP/NSX-T para Tanzu Application Service (PCF) | 3.1 |
NSX-T | 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1 |
vSphere | 6.7, 7.0 |
Kubernetes | 1.18, 1.19 |
OpenShift 3 | 3.11 Nota: Quedará obsoleto en próximas versiones. |
OpenShift 4 | RHCOS 4.4, 4.5 |
Sistema operativo de máquina virtual de host de Kubernetes | Ubuntu 18.04, Ubuntu 20.04, CentOS 7.7, CentOS 7.8, CentOS 8.1, CentOS 8.2, RHEL 7.8, RHEL 8.1, RHEL 8.2 Nota: Para Ubuntu 20.04, RHEL/CentOS 7.8, 8.1, no se admite la instalación del módulo de kernel nsx-ovs. Solo es compatible con OVS ascendente. |
Sistema operativo de máquina virtual de host de OpenShift | RHEL 7.7, RHEL 7.8 |
Tanzu Application Service (Pivotal Cloud Foundry) | Ops Manager 2.7 + PAS 2.7 (LTS) Ops Manager 2.9 + PAS 2.9 Ops Manager 2.10 + PAS 2.10 |
Tanzu Kubernetes Grid Integrated (TKGI) | 1.10 |
Versiones desde las que se puede actualizar a esta versión:
- Todas las versiones NCP 3.0.x
Problemas resueltos
- Problema 2552918: No se pudo realizar la reversión para el firewall distribuido, por lo que se produce un error en la reversión del clúster
En raras ocasiones, el proceso de importación de Manager a Directiva debe realizar una reversión, que no se realiza correctamente para las reglas y las secciones de firewall distribuido. Esto hace que se produzca un error en la reversión del clúster, lo que deja recursos obsoletos en NSX Manager.
Solución alternativa: Utilice la función de copia de seguridad y restauración para restaurar NSX Manager a un estado correcto.
Problemas conocidos
- Problema 2131494: La entrada de Kubernetes de NGINX sigue funcionando después de cambiar la clase de entrada de NGINX a NSX
Cuando se crea una entrada de Kubernetes de NGINX, NGINX crea reglas de reenvío de tráfico. Si cambia la clase de entrada a cualquier otro valor, NGINX no elimina las reglas y las sigue aplicando, incluso si elimina la entrada de Kubernetes después de cambiar la clase. Esta es una limitación de NGINX.
Solución alternativa: Para eliminar las reglas creadas por NGINX, elimine la entrada de Kubernetes cuando el valor de clase sea NGINX. A continuación, vuelva a crear la entrada de Kubernetes.
- Para un servicio de Kubernetes de tipo ClusterIP, no se admite la afinidad de sesión basada en IP de cliente
NCP no es compatible con la afinidad de sesión basada en IP de cliente para un servicio de Kubernetes de tipo ClusterIP.
Solución alternativa: Ninguno
- Para un servicio de Kubernetes de tipo ClusterIP, no se admite la marca de modo horquilla
NCP no es compatible con la marca de modo horquilla para un servicio de Kubernetes de tipo ClusterIP.
Solución alternativa: Ninguno
- Problema 2192489: Después de deshabilitar 'BOSH DNS server’ en la configuración de director de PAS, el servidor DNS de Bosh (169.254.0.2) sigue apareciendo en el archivo resolve.conf del contenedor
En un entorno de PAS que ejecute PAS 2.2, después de deshabilitar 'BOSH DNS server’ en la configuración de director de PAS, el servidor DNS de Bosh (169.254.0.2) sigue apareciendo en el archivo resolve.conf del contenedor. Esto provoca que un comando de ping con un nombre de dominio completo tome mucho tiempo. Este problema no existe con PAS 2.1.
Solución alternativa: Ninguna. Este es un problema de PAS.
- Problema 2224218: Después de eliminar un servicio o una aplicación, son necesarios dos minutos para volver a liberar la IP de SNAT al grupo de direcciones IP
Si elimina un servicio o una aplicación, y vuelve a crearlos en menos de dos minutos, obtendrán una nueva IP de SNAT del grupo de direcciones IP.
Solución alternativa: Tras eliminar un servicio o una aplicación, espere dos minutos antes de volver a crearlos si desea volver a utilizar la misma dirección IP.
- Problema 2404302: Si hay varios perfiles de aplicaciones del equilibrador de carga para el mismo tipo de recurso (por ejemplo, HTTP) en NSX-T, NCP elegirá cualquiera de ellos para conectarse a los servidores virtuales.
Si hay varios perfiles de aplicaciones del equilibrador de carga de HTTP en NSX-T, NCP elegirá uno de ellos con la configuración de x_forwarded_for adecuada para asociarlo al servidor virtual HTTP y HTTPS. Si hay varios perfiles de aplicaciones de FastTCP y UDP en NSX-T, NCP elegirá cualquiera de ellos para conectarse a los servidores virtuales TCP y UDP, respectivamente. Es posible que los perfiles de aplicaciones del equilibrador de carga hayan sido creados por diferentes aplicaciones con diferentes configuraciones. Si NCP elige asociar uno de estos perfiles de aplicaciones del equilibrador de carga a los servidores virtuales creados por NCP, podría romper el flujo de trabajo de otras aplicaciones.
Solución alternativa: Ninguno
- Problema 2397621: Error de instalación de OpenShift 3
La instalación de OpenShift 3 espera que el estado de un nodo esté listo y esto es posible después de la instalación del complemento CNI. En esta versión, no hay ningún archivo del complemento CNI independiente, lo que provoca un error en la instalación de OpenShift.
Solución alternativa: Cree el directorio /etc/cni/net.d en cada nodo antes de iniciar la instalación.
- Problema 2413383: Se produce un error al actualizar OpenShift 3 porque no todos los nodos están listos
De forma predeterminada, el pod de arranque de NCP no está programado en el nodo principal. Como resultado, el estado del nodo principal siempre está en estado No listo.
Solución alternativa: Asigne el nodo principal con la función "compute" para permitir que los DaemonSets nsx-ncp-bootstrap y nsx-node-agent creen pods. El estado del nodo cambiará a "Listo" una vez que nsx-ncp-bootstrap instale NSX-CNI.
- Problema 2451442: después de reiniciar NCP varias veces y de volver a crear un espacio de nombres, es posible que NCP no pueda asignar direcciones IP a los pods.
Si elimina y vuelve a crear repetidamente el mismo espacio de nombres al reiniciar NCP, puede que NCP no pueda asignar direcciones IP a los pod en ese espacio de nombres.
Solución alternativa: elimine todos los recursos de NSX obsoletos (enrutadores lógicos, conmutadores lógicos y puertos lógicos) asociados al espacio de nombres y vuelva a crearlos.
- Problema 2460219: el redireccionamiento de HTTP no funciona si no hay un grupo de servidores predeterminado.
Si el servidor virtual HTTP no se enlaza con un grupo de servidores, se producen errores en el redireccionamiento de HTTP. Este problema ya existe en NSX-T 2.5.0 y versiones anteriores.
Solución alternativa: cree un grupo de servidores predeterminado o actualice a NSX-T 2.5.1.
- Problema 2518111: NCP no pueden eliminar recursos de NSX-T que se actualizaron desde NSX-T
NCP crea recursos de NSX-T en función de las configuraciones que especifique. Si realiza actualizaciones a esos recursos de NSX-T a través de NSX Manager o de la API de NSX-T, es posible que NCP no pueda eliminar esos recursos y volver a crearlos cuando sea necesario.
Solución alternativa: No actualice los recursos de NSX-T creados por NCP a través de NSX Manager o de la API de NSX-T.
- Problema 2524778: NSX Manager muestra NCP como inactivo o en mal estado después de que se elimine el nodo principal de NCP
Después de eliminar un nodo principal de NCP (por ejemplo, después de que se realice correctamente el cambio a un nodo de copia de seguridad, el estado de NCP sigue apareciendo como inactivo cuando debería aparecer como activo).
Solución alternativa: Utilice la API de Manager DELETE /api/v1/systemhealth/container-cluster/<id-clúster>/ncp/status para borrar el estado obsoleto de forma manual.
- Problema 2517201: No se puede crear un pod en un host ESXi
Después de eliminar un host ESXi de un clúster de vSphere y volver a agregarlo al clúster, se produce un error al crear un pod en el host.
Solución alternativa: Reinicie NCP.
- Problema 2416376: NCP no puede procesar un ASG (grupo de seguridad de aplicaciones) de PAS vinculado a más de 128 espacios
Debido a un límite en el firewall distribuido de NSX-T, NCP no puede procesar un ASG de PAS vinculado a más de 128 espacios.
Solución alternativa: Cree varios ASG y vincule cada uno de ellos a un máximo de 128 espacios.
- Problema 2534726: Si se produce un error al actualizar a NCP 3.0.1 a través del mosaico NSX-T, el uso de la línea de comandos BOSH para rehacer la actualización provocará problemas de rendimiento
Cuando se actualiza a NCP 3.0.1 a través del mosaico NSX-T en OpsMgr, el proceso de actualización marcará los perfiles de conmutación de HA en NSX Manager utilizados por NCP como inactivos. Los perfiles de conmutación se eliminarán cuando se reinicie NCP. Si se produce un error en la actualización y se utiliza un comando de BOSH, como “bosh deploy -d <id-implementación> -n <implementación>.yml” para rehacer la actualización, no se eliminarán los perfiles de conmutación de HA. NCP seguirá ejecutándose, pero el rendimiento se degradará.
Solución alternativa: Actualice siempre NCP a través de OpsMgr y no de la línea de comandos de BOSH.
- Problema 2537221: Después de actualizar NSX-T a la versión 3.0, el estado de redes de los objetos relacionados con contenedores en la interfaz de usuario de NSX Manager se muestra como Desconocido
En la interfaz de usuario de NSX Manager, la pestaña Inventario > Contenedores muestra los objetos relacionados con el contenedor y su estado. En un entorno de PKS, después de actualizar NSX-T a la versión 3.0, el estado de redes de los objetos relacionados con el contenedor se muestra como Desconocido. El problema se debe a que PKS no detecta el cambio de versión de NSX-T. Este problema no se produce si NCP se está ejecutando como pod y el sondeo de ejecución está activo.
Solución alternativa: Después de la actualización de NSX-T, reinicie las instancias de NCP gradualmente (no más de 10 al mismo tiempo) para no sobrecargar NSX Manager.
- Problema 2550474: En un entorno de OpenShift, el cambio de una ruta HTTPS a HTTP puede hacer que la ruta HTTP no funcione según lo esperado
Si se edita una ruta HTTPS y se eliminan los datos relacionados con TLS para convertirla en una ruta HTTP, es posible que la ruta HTTP no funcione según lo esperado.
Solución alternativa: Elimine la ruta HTTPS y cree una nueva ruta HTTP.
- Problema 2552573: En un entorno de OpenShift 4.3, se puede producir un error en la instalación del clúster si DHCP está configurado con la interfaz de usuario de Directiva
En un entorno de OpenShift 4.3, la instalación del clúster requiere que haya un servidor DHCP disponible para proporcionar información de DNS y direcciones IP. Si utiliza el servidor DHCP configurado en NSX-T mediante la interfaz de usuario de Directiva, es posible que se produzca un error en la instalación del clúster.
Solución alternativa: Configure un servidor DHCP mediante la interfaz de usuario de Manager, elimine el clúster que no pudo instalar y vuelva a crear el clúster.
- Problema 2552564: En un entorno de OpenShift 4.3, el reenviador de DNS podría dejar de funcionar si se encuentra una dirección superpuesta
En un entorno de OpenShift 4.3, la instalación del clúster requiere que se configure un servidor DNS. Si utiliza NSX-T para configurar un reenviador de DNS y existe una superposición de direcciones IP con el servicio DNS, el reenviador de DNS dejará de funcionar y se producirá un error al instalar el clúster.
Solución alternativa: Configure un servicio DNS externo, elimine el clúster que no pudo instalar y vuelva a crear el clúster.
- Problema 2483242: El tráfico IPv6 de los contenedores está bloqueado por NSX-T SpoofGuard
La dirección local de vínculo IPv6 no se encuentra en la lista blanca automática con SpoofGuard habilitado.
Solución alternativa: Deshabilite SpoofGuard estableciendo nsx_v3.enable_spoofguard = False en la configuración de NCP.
- Problema 2552609: datos de X-Forwarded-For (XFF) y X-Forwarded-Port incorrectos
Si configura XFF con INSERT o REPLACE para las reglas de entrada de HTTPS (Kubernetes) o las rutas HTTPS (OpenShift), es posible que aparezcan valores de X-Forwarded-For y X-Forwarded-Port incorrectos en encabezados XFF.
Solución alternativa: Ninguna.
- Problema 2555336: El tráfico del pod no funciona porque hay puertos lógicos duplicados creados en modo Manager
Es más probable que este problema se produzca cuando hay muchos pods en varios clústeres. Cuando se crea un Pod, no funciona el tráfico al pod. NSX-T muestra varios puertos lógicos creados para el mismo contenedor. En el registro de NCP, solo se puede encontrar el identificador de uno de los puertos lógicos.
Solución alternativa: Elimine el pod y vuelva a crearlo. Los puertos obsoletos de NSX-T se eliminarán cuando se reinicie NCP.
- Problema 2554357: El ajuste de escala automático del equilibrador de carga no funciona para IPv6
En un entorno IPv6, un servicio de Kubernetes de tipo equilibrador de carga no estará activo cuando se alcance la escala del equilibrador de carga existente.
Solución alternativa: Establezca nsx_v3.lb_segment_subnet = FE80::/10 en /var/vcap/jobs/ncp/config/ncp.ini para implementaciones de PKS y en nsx-ncp-configmap para otros. A continuación, reinicie NCP.
- Problema 2597423: Al importar objetos de Manager a Directiva, una reversión hará que se pierdan las etiquetas de algunos recursos
Al importar objetos de Manager a Directiva, si es necesaria una reversión, no se restaurarán las etiquetas de los siguientes objetos:
- Perfiles de Spoofguard (parte de los recursos compartidos y de clúster)
- BgpneighbourConfig (parte de los recursos compartidos)
- BgpRoutingConfig (parte de los recursos compartidos)
- StaticRoute BfdPeer (parte de los recursos compartidos)
Solución alternativa: Para los recursos que forman parte de los recursos compartidos, restaure manualmente las etiquetas. Utilice la función de copia de seguridad y restauración para restaurar recursos que formen parte de los recursos del clúster.
- Problema 2579968: Cuando se realizan cambios en los servicios de Kubernetes de tipo LoadBalancer con una frecuencia alta, algunos servidores virtuales y grupos de servidores no se eliminan según lo esperado
Cuando se realizan cambios en los servicios de Kubernetes de tipo LoadBalancer con una frecuencia alta, es posible que algunos servidores virtuales y los grupos de servidores permanezcan en el entorno de NSX-T cuando deberían eliminarse.
Solución alternativa: Reinicie NCP. De forma alternativa, elimine manualmente los servidores virtuales obsoletos y sus recursos asociados. Un servidor virtual está obsoleto si ningún servicio de Kubernetes de tipo equilibrador de carga tiene el identificador del servidor virtual en la etiqueta external_id.
- Problema 2536383: Después de actualizar NSX-T a la versión 3.0 o una posterior, la interfaz de usuario de NSX-T no muestra correctamente la información relacionada con NCP
Después de actualizar NSX-T a la versión 3.0 o una posterior, la pestaña Inventario > Contenedores de la interfaz de usuario de NSX-T muestra el estado de red de los objetos relacionados con el contenedor como Desconocido. Además, los clústeres de NCP no aparecen en la pestaña Sistema > Tejido > Nodos > Clústeres de NCP. Por lo general, este problema se ve en un entorno de PKS.
Solución alternativa: Después de la actualización de NSX-T, reinicie las instancias de NCP gradualmente (no más de 10 al mismo tiempo).
- Problema 2622099: Se produce un error al inicializar el servicio de Kubernetes de tipo LoadBalancer con el código de error NCP00113 y el mensaje de error "Otro usuario ha modificado el objeto. Vuelva a intentarlo."
En una implementación de un solo nivel con API de directiva, si utiliza una puerta de enlace de nivel 1 existente como la puerta de enlace de nivel superior y el tamaño de asignación de grupo de la puerta de enlace es ROUTING, es posible que un servicio de Kubernetes de tipo LoadBalancer no pueda inicializarse mostrando el código de error NCP00113 y el mensaje "Otro usuario ha modificado el objeto. Vuelva a intentarlo."
Solución alternativa: Si aparece este problema, espere 5 minutos. A continuación, reinicie NCP. El problema se resolverá.
- Problema 2633679: NCP Operator no es compatible con los nodos de OpenShift asociados a un segmento de nivel 1 creado con la API /policy/api/v1/infra/tier-1s/<id-nivel1>/segments/<id-segmento>
NCP Operator no es compatible con los nodos de OpenShift asociados a un segmento de nivel 1 creado con la API /policy/api/v1/infra/tier-1s/<id-nivel1>/segments/<id-segmento>.
Solución alternativa: Use la API /policy/api/v1/infra/segments/<id-segmento> para crear el segmento.
- NCP no puede iniciarse si la opción de "registro en archivo" está habilitada durante la instalación de Kubernetes
Este problema se produce cuando uid:gid=1000:1000 en el host de contenedor no tiene permiso para la carpeta de registros.
Solución alternativa: Realice una de las siguientes acciones:
- Cambie el modo de la carpeta de registros a 777 en los hosts de contenedor.
- Conceda el permiso "rwx" de la carpeta de registros a uid:gid=1000:1000 en los hosts del contenedor.
- Deshabilite la función de "registro en archivo".
- Problema 2653214: Se produjo un error al buscar el puerto de segmento de un nodo después de cambiar la dirección IP del nodo
Después de cambiar la dirección IP del nodo, si actualiza NCP o si se reinicia el pod de NCP Operator, al comprobar el estado de NCP Operator con el comando "oc describe co nsx-ncp", se mostrará el mensaje de error "Se produjo un error al buscar el puerto del segmento para el nodo..."
Solución alternativa: Ninguna. No se puede agregar una dirección IP estática en una interfaz de nodo que también tenga configuración de DHCP.
- Problema 2664457: Al utilizar DHCP en OpenShift, es posible que se pierda temporalmente la conectividad cuando nsx-node-agent se inicia o se reinicia
nsx-ovs activa el perfil de conexión de DHCP en ovs_bridge, que podría seguir fallando en NetworkManager. Como resultado, no hay ninguna IP (conectividad) presente en la máquina virtual en ovs_uplink_port ni o en ovs_bridge.
Solución alternativa: Reinicie la máquina virtual o simplemente espere hasta que la asignación de direcciones IP de DHCP se realice correctamente.
- Problema 2671647: Los flujos de OVS se pierden al reiniciar el trabajo de monit para los daemons de OVS ovsdb-server y ovs-vswitchd
Los flujos de OVS creados por nsx-node-agent se pierden si se reinicia el trabajo monit para los daemons openvswitch con el comando "monit restart <nombre-proceso>"
Solución alternativa: Reinicie nsx-node-agent una vez que los daemons de openvswitch vuelvan al estado "En ejecución" mediante el comando "monit restart nsx-node-agent"
- Problema 2672677: En un entorno de OpenShift 4 muy estresado, un nodo puede dejar de responder
En un entorno de OpenShift 4 con un alto nivel de densidad de pods por nodo y una alta frecuencia de eliminación y creación de pods, un nodo de RHCOS puede pasar al estado "No está listo". Los pods que se ejecutan en el nodo afectado, a excepción de los miembros de daemonset, se expulsarán y se volverán a crear en otros nodos del entorno.
Solución alternativa: Reinicie el nodo afectado.
- Problema 2653241: No se admite la actualización de los certificados de un secreto en Kubernetes
Si actualiza los certificados en un secreto, los nuevos certificados no se actualizarán en NSX-T. Este problema existe en los modos Manager y Directiva.
Solución alternativa: Elimine el secreto y cree uno nuevo con los certificados actualizados.
- Problema 2674503: nsx-ncp-bootstrap no admite la instalación de módulos kernel de NSX OVS en CentOS 7.8, 8.1, 8.2 o RHEL 7.8, 8.1, 8.2
El contenedor nsx-ncp-bootstrap no admite la instalación de módulos de kernel de OVS de NSX en CentOS 7.8, 8.1, 8.2 o RHEL 7.8, 8.1, 8.2.
Solución alternativa: Establezca
use_nsx_ovs_kernel_modnel
enFalse
en ConfigMap del agente de nodo de NSX y utilice el módulo de kernel OVS ascendente de Linux. - Problema 3033821: Después de la migración de Manager a Directiva, las reglas de firewall distribuido no se aplican correctamente
Después de una migración de Manager a Directiva, las reglas de firewall distribuido (DFW) relacionadas con directivas de red recién creadas tendrán mayor prioridad que las reglas de DFW migradas.
Solución alternativa: Utilice la API de Directiva para cambiar la secuencia de reglas de DFW según sea necesario.