VMware NSX Container Plugin 3.1.2   |   15 de abril de 2021   |   Compilación 17855682 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
• Requisitos de compatibilidad
• Problemas resueltos
• Problemas conocidos

Novedades

NSX Container Plugin (NCP) 3.1.2 tiene la siguiente función nueva:

• Para la persistencia del equilibrador de carga de capa 7, se admite la especificación del nombre de la cookie

Aviso de obsolescencia

La anotación "ncp/whitelist-source-range" quedará obsoleta en NCP 3.3. A partir de NCP 3.1.1, se usará la anotación "ncp/allowed-source-range" en su lugar.

Requisitos de compatibilidad

Producto	Versión
Mosaico de NCP/NSX-T para Tanzu Application Service (TAS)	3.1.2
NSX-T	3.0.3, 3.1.0, 3.1.1, 3.1.2, 3.1.3
vSphere	6.7, 7.0
Kubernetes	1.18, 1.19 y 1.20
OpenShift 3	3.11 Nota: OpenShift 3.x quedará obsoleto en próximas versiones.
OpenShift 4	RHCOS 4.6, 4.7
Sistema operativo de máquina virtual de host de Kubernetes	Ubuntu 18.04, Ubuntu 20.04 CentOS 7.8, CentOS 7.9, CentOS 8.3 RHEL 7.8, RHEL 7.9, RHEL 8.1 y RHEL 8.3 Consulte las notas a continuación.
Sistema operativo de máquina virtual de host de OpenShift 3	RHEL 7.7, RHEL 7.8 (Nota: RHEL dejará de admitir Vanilla Kubernetes en próximas versiones.)
Tanzu Application Service	Ops Manager 2.7 + TAS 2.7 (LTS) Ops Manager 2.9 + TAS 2.9 Ops Manager 2.10 + TAS 2.10 Ops Manager 2.10 + TAS 2.11
Tanzu Kubernetes Grid Integrated (TKGI)	1.11

Notas:

La instalación del módulo nsx-ovs kernel en CentOS/RHEL requiere una versión de kernel específica. Las versiones compatibles del kernel RHEL son 1127 y 1160, independientemente de la versión de RHEL. Tenga en cuenta que la versión predeterminada del kernel es 1127 para RHEL 7.8 y 1160 para RHEL 7.9. Si está utilizando una versión de kernel diferente, puede omitir la instalación del módulo de kernel nsx-ovs configurando "use_nsx_ovs_kernel_modnel" como "False" en la sección "nsx_node_agent" del mapa de configuración de nsx-node-agent.

A partir de NCP 3.1.2, ya no se distribuirá la imagen de RHEL. Para todas las integraciones admitidas, utilice Red Hat Universal Base Image (UBI). Para obtener más información consulte https://www.redhat.com/es/blog/introducing-red-hat-universal-base-image.

Versiones desde las que se puede actualizar a esta versión:

• Todas las versiones anteriores a la 3.1.x y todas las versiones NCP 3.0.x

 

Problemas resueltos

• Problema 2707883: nsx-ncp-operator no crea un recurso de Kubernetes relacionado con NCP si el recurso se eliminó cuando nsx-ncp-operator no se estaba ejecutando

  Por ejemplo, si se elimina DaemonSet de nsx-node-agent o nsx-ncp-bootstrap cuando nsx-ncp-operator no se está ejecutando, no se volverá a crear cuando nsx-ncp-operator se esté ejecutando de nuevo.

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 TAS, 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 TAS 2.2, después de deshabilitar 'BOSH DNS server’ en la configuración de director de TAS, 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 TAS 2.1.

  Solución alternativa: Ninguna. Este es un problema de TAS.

• 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 TAS 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 TAS 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 TKGI, 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 TKGI 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 TKGI 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 TKGI.

  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 crea y activa cinco perfiles de conexión temporales para configurar ovs_bridge, pero su activación puede seguir fallando temporalmente 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 espere a que NetworkManager pueda activar correctamente todos los perfiles.

• 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 2706551: Se produce un error en la instalación automatizada de pila completa de OpenShift (conocida como IPI) porque los nodos no están listos durante la instalación

  El pod cuya conexión se ha mantenido agrega el VIP de Kubernetes al ovs_bridge en los nodos maestros antes de que el servidor de la API de Kubernetes empiece a ejecutarse en ellos. Como resultado, fallan todas las solicitudes enviadas al servidor de la API de Kubernetes y no se puede completar la instalación.

  Solución alternativa: Ninguno

• Problema 2697547: No se admite HostPort en los nodos de RHEL/CentOS/RHCOS

  Puede especificar hostPorts en Kubernetes nativo y TKGI en nodos de Ubuntu configurando 'enable_hostport_snat' como True en ConfigMap de nsx-node-agent. Sin embargo, en los nodos de RHEL/CentOS/RHCOS no se admite hostPort y se omite el parámetro 'enable_hostport_snat'.

  Solución alternativa: Ninguno

• Problema 2707174: Un pod que se elimina y se vuelve a crear con el mismo nombre y nombre de espacio no tiene conectividad de red

  Si se elimina un pod y se vuelve a crear con el mismo nombre y espacio de nombre cuando NCP no se está ejecutando y se está ejecutando nsx-ncp-agents, es posible que el pod obtenga configuraciones de red erróneas y no pueda acceder a la red.

  Solución alternativa: Elimine el pod y vuelva a crearlo cuando se esté ejecutando NCP.

• Problema 2713782: Las llamadas de NSX API fallan con el error "SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC"

  Ocasionalmente, durante el inicio de NCP, puede que este se reinicie o que no inicialice los servicios del equilibrador de carga debido a la presencia de un servidor de equilibrio de carga duplicado o un enrutador lógico de nivel 1 para el equilibrador de carga. Además, mientras NCP se está ejecutando, es posible que se notifique que un endpoint de NSX está fuera de servicio durante un breve período de tiempo (menos de 1 segundo). Si el equilibrador de carga no se inicializa, el registro de NCP mostrará el mensaje "No se pudieron inicializar los servicios de equilibrador de carga". 

  Este comportamiento solo se produce cuando NCP realiza el equilibrio de carga del lado del cliente entre varias instancias de NSX Manager. No se produce si se configura un único endpoint de API en ncp.ini.

  Solución alternativa: Aumente el valor del parámetro nsx_v3.conn_idle_timeout. Tenga en cuenta que esto puede aumentar el tiempo de espera para que los endpoints se detecten como disponibles después de una desconexión temporal cuando se utiliza el equilibrio de carga del lado del cliente.

• Problema 2745904: La función "Usar IPSet para ejecutar ASG de forma predeterminada" no permite reemplazar ni eliminar un bloque de IP de contenedor existente

  Si habilita "Usar IPSet para ejecutar ASG de forma predeterminada" en un mosaico de NCP, NCP creará un grupo NSGroup específico para todos los bloques de IP de contenedor configurados por "Bloques de IP de redes de contenedores" en el mismo mosaico de NCP. Ese grupo NSGroup se utilizará en las reglas de firewall creadas para ejecutar ASG de forma global con el fin de permitir el tráfico de todos los contenedores. Si, posteriormente, elimina o reemplaza un bloque de IP de contenedor existente, este se eliminará o reemplazará en el grupo NSGroup. Todos los contenedores existentes del bloque de IP original dejarán de estar asociados a los ASG globales en ejecución. Es posible que su tráfico ya no funcione.

  Solución alternativa: Agregue solo nuevos bloques de IP a "Bloques de IP de redes de contenedores".

• Problema 2744480: El autoacceso mediante servicio de Kubernetes no es compatible con KVM

  Si un pod de Kubernetes intenta acceder a sí mismo a través de un servicio de Kubernetes en el que el pod es un endpoint, los paquetes de respuesta se descartarán en el host de KVM.

  Solución alternativa: Ninguno

• Problema 2744361: La máquina virtual de carga de trabajo de OpenShift configurada con una dirección IP estática puede perder la conectividad cuando se interrumpe el pod de nsx-node-agent

  Ocasionalmente, una máquina virtual de carga de trabajo en OpenShift configurada con una dirección IP estática pierde la conectividad cuando se interrumpe el pod de nsx-node-agent.

  Solución alternativa: Reinicie la máquina virtual.

• Problema 2746362: nsx-kube-proxy no puede recibir eventos del servicio de Kubernetes de apiserver de Kubernetes

  Ocasionalmente, en un clúster de OpenShift, nsx-kube-proxy no puede recibir ningún evento del servicio de Kubernetes de apiserver de Kubernetes. El comando "nsxcli -c get kube-proxy-watchers" da como resultado "Estado de subproceso de monitor: activo", pero el "Número de eventos procesados" es 0, lo que significa que nsx-kube-proxy no recibió ningún evento de apiserver.

  Solución alternativa: Reinicie el pod nsx-kube-proxy.

• Problema 2745907: Los comandos "monit" devuelven información de estado incorrecta sobre nsx-node-agent

  En una máquina virtual diego_cell, cuando monit reinicia nsx-node-agent, si se necesitan más de 30 segundos para que nsx-node-agent se inicie por completo, monit mostrará el estado de nsx-node-agent "Error de ejecución" y no lo actualizará su estado a "en ejecución" aunque nsx-node-agent esté completamente activo más tarde.

  Solución alternativa: Ninguna.

• Problema 2735244: bloqueo de nsx-node-agent y nsx-kube-proxy debido a un error de sondeo de ejecución

  nsx-node-agent y nsx-kube-proxy utilizan sudo para ejecutar algunos comandos. Si hay muchas entradas en /etc/resolv.conf acerca del servidor DNS y de los dominios de búsqueda, sudo puede tardar mucho en resolver los nombres de host. Esto hará que nsx-node-agent y nsx-kube-proxy se bloqueen con el comando sudo durante mucho tiempo y se producirá un error en el sondeo de ejecución.

  Solución alternativa: Lleve a cabo una de las siguientes acciones:

  • Agregue entradas de nombre de host a /etc/hosts. Por ejemplo, si el nombre de host es 'host1', agregue la entrada '127.0.0.1   host1'.
  • Asigne un valor mayor al tiempo de espera del sondeo de ejecución de nsx-node-agent. Ejecute el comando 'kubectl edit ds nsx-node-agent -n nsx-system' para actualizar el valor de tiempo de espera en los contenedores de nsx-node-agent y nsx-kube-proxy.
• Problema 2744557: No se admiten patrones de expresiones regulares complejos que contengan tanto un grupo de captura () como {0} para relacionar rutas de entrada.

  Por ejemplo, si el patrón de expresión regular es: /foo/bar/(abc){0,1}, no coincidirá con /foo/bar/.

  Solución alternativa: No utilice el grupo de captura () y {0} al crear una regla de expresión regular de entrada. Utilice el patrón regular EQUALS para que coincida con /foo/bar/.

• Problema 2751080: Después de actualizar un host de KVM, los hosts de contenedor no pueden ejecutar pods de Kubernetes

  Tras actualizar un host de KVM, los hosts de contenedor implementados en el host actualizado no podrán ejecutar pods de Kubernetes. Los pods permanecerán en el estado de creación del contenedor. Si se implementa NCP Operator, el estado del nodo puede ser NotReady y la condición del nodo networkUnavailable será True. Este problema solo se observa en RHEL, no en Ubuntu.

  Solución alternativa: Reinicie nsx-opsagent en el hipervisor de KVM.

• Problema 2736412: El parámetro members_per_small_lbs se omite si max_allowed_virtual_servers está establecido

  Si se establecen tanto max_allowed_virtual_servers como members_per_small_lbs, puede que los servidores virtuales no se asocien a un equilibrador de carga disponible porque solo se tiene en cuenta max_allowed_virtual_servers.

  Solución alternativa: Relaje las restricciones de escala en lugar de habilitar la escala automática.

• Problema 2740552: Al eliminar un pod estático mediante api-server, nsx-node-agent no elimina el puerto de puente OVS del pod y la red del pod estático que Kubernetes vuelve a crear automáticamente no está disponible

  Kubernetes no permite eliminar un pod estático mediante api-server. Kubernetes crea un pod reflejado de pod estático para que api-server pueda buscar el pod estático. Al eliminar el pod mediante api-server, solo se eliminará el pod reflejado y NCP recibirá y controlará la solicitud de eliminación para eliminar todos los recursos de NSX asignados para el pod. Sin embargo, el pod estático sigue existiendo y nsx-node-agent no recibirá la solicitud de eliminación de CNI para eliminar el puerto de puente OVS del pod estático. 

  Solución alternativa: Quite el pod estático eliminando el archivo de manifiesto en lugar de eliminar el pod estático mediante api-server.

• Problema 2795268: La conexión entre nsx-node-agent e HyperBus se desplaza y el pod de Kubernetes se atasca en el estado de creación

  En un entorno a gran escala, nsx-node-agent podría fallar al conectarse a APIserver de Kubernetes para obtener información sobre los pods. Debido a la gran cantidad de información que se transfiere, los mensajes keepalive no pueden enviarse a HyperBus, e HyperBus cerrará la conexión.

  Solución alternativa: Reinicie nsx-node-agent. Asegúrese de que APIserver de Kubernetes está disponible y que el certificado para conectarse a APIserver es correcto.

• Problema 2795482: El pod en ejecución se bloquea en el estado ContainerCreating después de reiniciar el nodo/hipervisor o cualquier otra operación

  Si se cumple la marca wait_for_security_policy_sync, un pod puede pasar al estado ContainerCreating después de estar en estado de ejecución durante más de una hora debido a un reinicio forzado del nodo de trabajo, un reinicio del hipervisor o alguna otra razón. El pod estará siempre en estado de creación.

  Solución alternativa: Elimine el pod y vuelva a crearlo.

• Problema 2871314: Después de actualizar TKGI de la versión 1.10.x a la 1.11.x (anterior a la versión 1.11.6), se eliminarán los certificados de entrada del equilibrador de carga de NSX.

  A partir de NCP 3.1.1, se realiza un seguimiento de los certificados con un número de revisión. Esto provoca un problema al actualizar TKGI 1.10.x a TKGI 1.11.x (anterior a la versión 1.11.6), lo que provoca que los certificados de entrada del equilibrador de carga de NSX se eliminen y no se vuelvan a importar.

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

  1. Reinicie NCP. O,
  2. Elimine el secreto en el entorno de Kubernetes y vuelva a crear el mismo secreto. O,
  3. Actualice a TKGI 1.11.6 o versiones posteriores.
• Problema 2871321: Después de actualizar TKGI de la versión 1.10.x a la 1.11.x (antes a la 1.11.6), si el equilibrador de carga CRD utiliza la persistencia de cookie de capa 7, perderá la dirección IP.

  Este problema se debe a una nueva función de NCP 3.1.1 que admite la actualización del nombre de cookie en el equilibrador de carga de NSX.

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

  1. Utilice la persistencia de IP de origen en lugar de la persistencia de cookie.
  2. Actualice a TKGI 1.11.6 o una versión posterior.
• 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.