Notas de la versión de NSX Container Plugin 3.0.0

VMware NSX Container Plugin 3.0.0 | 7 de abril de 2020 | Compilación 15841604

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.0.0 solo va dirigido a los clientes de vSphere with Kubernetes. Espere a NSX Container Plugin 3.0.1 para las demás distribuciones de Kubernetes, RedHat y Pivotal.

NSX Container Plugin 3.0.0 incluye las siguientes novedades:

Soporte para relajar el límite de escala en el servicio del equilibrador de carga. Para la API de directivas, compatibilidad con el límite de miembros de grupo por servicio del equilibrador de carga para los servicios de equilibrador de carga de Kubernetes.
Compatibilidad con la lista blanca de IP de origen para los servicios de equilibrador de carga de Kubernetes y entrada para la API de directiva.

Requisitos de compatibilidad

Producto	Versión
NSX-T	3.0.0
vSphere with Kubernetes	7.0

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

Todas las versiones NCP 2.5.x

Problemas resueltos

Problema 2370137: Los contenedores nsx-ovs y nsx-node-agent no se pueden ejecutar porque los archivos de la base de datos de OVS no están en /etc/openvswitch
Cuando se inician los contenedores nsx-ovs y nsx-node-agent, estos buscan los archivos de la base de datos de OVS en /etc/openvswitch. Si hay vínculos simbólicos en el directorio que se vinculan con los archivos OVS reales (como conf.db), los contenedores nsx-ovs y nsx-node-agent no se ejecutarán.
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.

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 2330811: Al crear servicios de Kubernetes de tipo equilibrador de carga mientras NCP está inactivo, es posible que no se creen los servicios cuando se reinicie NCP
Cuando se agotan los recursos de NSX-T para los servicios de Kubernetes de tipo equilibrador de carga, puede crear nuevos servicios después de eliminar algunos de los servicios existentes. Sin embargo, si elimina y crea los servicios mientras NCP está inactivo, NCP no podrá crear los nuevos servicios.

Solución alternativa: Cuando se agoten los recursos de NSX-T para los servicios de Kubernetes de tipo equilibrador de carga, no realice las operaciones de eliminación y creación mientras NCP está inactivo.
Problema 2397438: Después de reiniciar, NCP informa de un error de MultipleObjects
Antes de reiniciar, NCP no pudo crear secciones de firewall distribuido debido a un error de ServerOverload. NCP agotó el número máximo de reintentos. Sin embargo, se siguieron creando las secciones del firewall. Cuando se reinició NCP, recibió secciones de firewall duplicadas y se notifica el error MultipleObjects.

Solución alternativa: Elimine manualmente las secciones obsoletas y duplicadas del firewall distribuido y, a continuación, reinicie NCP.
Problema 2397684: NCP encontró la zona de transporte correcta, pero luego se produjo el error "La zona de transporte predeterminada no está configurada"
Cuando se crean espacios de nombres de Kubernetes con NCP basado en la API de directivas, la creación de los segmentos de infrarrojos puede fallar debido a la presencia de varias zonas de transporte superpuestas en NSX-T. Este problema se produce si ninguna de las zonas de transporte superpuestas está marcada como predeterminada.

Solución alternativa: Actualice la zona de transporte superpuesta, configurada en NCP ConfigMap, y establezca el valor "True" en el campo "is_default".
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
La instalación de OpenShift 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 2408100: En un clúster de Kubernetes de gran tamaño con varias instancias de NCP en el modo activo-en espera o con el sondeo de ejecución habilitado, el NCP se reinicia con frecuencia
En un clúster de Kubernetes de gran tamaño (alrededor de 25 000 pods, 2500 espacios de nombres y 2500 directivas de red), si varias instancias de NCP se ejecutan en modo activo-en espera o si el sondeo de ejecución está habilitado, es posible que los procesos de NCP se eliminen y se reinicien con frecuencia debido a un conflicto en la adquisición de bloqueo o a un error del sondeo de ejecución.

Solución alternativa: Realice los pasos siguientes:
1. Establezca el valor 1 en replicas de la implementación de NCP o aumente la opción de configuración ha.master_timeout en ncp.ini de 18, el valor predeterminado, a 30.
2. Aumente los argumentos del sondeo de ejecución de la siguiente forma:
```
  containers:
    - name: nsx-ncp
      livenessProbe:
        exec:
          command:
            - /bin/sh
            - -c
            - timeout 20 check_pod_liveness nsx-ncp
        initialDelaySeconds: 20
        timeoutSeconds: 20
        periodSeconds: 20
        failureThreshold: 5
```
Problema 2412421: Docker no puede reiniciar un contenedor
Si se actualiza (1) ConfigMap, (2) el contenedor utiliza subPath para montar ConfigMap y (3) se reinicia el contenedor, Docker no puede iniciar el contenedor.

Solución alternativa: Elimine el Pod para que el DaemonSet vuelva a crear el Pod.
Problema 2413383: Se produce un error al actualizar OpenShift 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 2410909: Después de reiniciar, NCP puede tardar mucho en inicializar su memoria caché en un entorno a gran escala (especialmente si hay muchas directivas de red), y puede tardar aproximadamente media hora en aparecer y procesar nuevos pods y recursos.
Después de reiniciar, NCP puede tardar mucho tiempo en aparecer. El procesamiento de recursos como pods, espacios de nombres y directivas de red puede tardar más tiempo del habitual, en función de la cantidad de recursos involucrados.

Solución alternativa: Ninguno
Problema 2447127: al actualizar NCP 2.4.1 a las versiones 2.5.0 o 2.5.1, NCP puede tardar un tiempo adicional en estar activo y en ejecución.
Al actualizar NCP 2.4.1 a la versión 2.5.x, NSX-T 2.4.1 puede responder de forma lenta cuando NCP llame a la API de perfil de conmutación para la elección del elemento principal. Este problema provoca que NCP pueda tardar algunos minutos adicionales en estar activo y en ejecución.

Solución alternativa: Ninguna.
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 2518312: El contenedor de arranque de NCP no puede instalar el módulo de kernel nsx-ovs en Ubuntu 18.04.4, kernel 4.15.0-88
El contenedor de arranque de NCP (nsx-ncp-bootstrap) no puede instalar el módulo de kernel nsx-ovs en Ubuntu 18.04.4, kernel 4.15.0-88.

No instale NSX-OVS en este kernel estableciendo use_nsx_ovs_kernel_module = False en nsx-node-agent-config. En su lugar, utilice el módulo kernel de OVS ascendente (Ubuntu incluye de forma predeterminada un módulo kernel de OVS) en el host. Si no hay ningún módulo kernel de OVS en el host, instale manualmente el módulo kernel de OVS y establezca use_nsx_ovs_kernel_module = False en nsx-node-agent-config, o cambie la versión del kernel a 4.15.0-76 para poder instalar NSX-OVS.
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 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.