Notas de la versión de VMware NSX Container Plugin 4.1.1

VMware NSX Container Plugin 4.1.1 | 17 de agosto de 2023 | Compilación 22071564 Compruebe si existen actualizaciones adicionales a las notas de la versión.

Novedades

• A partir de esta versión, solo se permitirán nuevas implementaciones de TAS con la Directiva de NSX. Para las bases existentes, la configuración de NCP no se cambiará tras las actualizaciones.

• Los recursos de NSX creados por TKGi para la red de implementación ahora se migran a Directiva durante la migración de MP a Directiva.

• NCP admite hasta 500 rutas OCP en un determinado servidor virtual del equilibrador de carga de NSX.

• Puede realizar una copia de seguridad y, posteriormente, restaurar NSX a un estado anterior. NCP garantiza que los recursos de un clúster de OpenShift y NSX estén en un estado coherente.

• OpenShift Operator puede simplificar la implementación de NCP mediante la automatización de determinadas configuraciones de opciones. También se mejoró la validación de las opciones que se introducen desde configmap.

Aviso de obsolescencia

La función que permite el acceso a través de NAT a los pods del controlador de entrada mediante la anotación "ncp/ingress_controller" ha quedado obsoleta y se eliminará en 2023. La forma recomendada de exponer los pods del controlador de entrada es utilizar servicios de tipo LoadBalancer.

El módulo de kernel nsx-ovs está obsoleto. Solo se admite el módulo kernel OVS ascendente, que es el comportamiento predeterminado. Se eliminó la opción de configmap "use_nsx_ovs_kernel_module" en la sección "nsx_node_agent" del configmap de nsx-node-agent.

Requisitos de compatibilidad

Producto	Versión
Mosaico de NCP/NSX para Tanzu Application Service (TAS)	4.1.1
NSX	3.2.2, 3.2.3, 4.0.1.1, 4.1.0, 4.1.1
Kubernetes	1.24, 1.25, 1.26
OpenShift 4	4.10, 4.11, 4.12
Sistema operativo de máquina virtual de host de Kubernetes	Ubuntu 20.04 Ubuntu 22.04 con kernel 5.15 (compatibles con el módulo de kernel nsx-ovs y el módulo de kernel OVS ascendente) Ubuntu 22.04 con kernel posterior a la versión 5.15 (solo se admite el módulo de kernel OVS ascendente) RHEL: 8.4, 8.5, 8.6 Consulte las notas a continuación.
Tanzu Application Service (TAS)	Ops Manager 2.10 + TAS 2.13 Ops Manager 3.0 + TAS 2.13 Ops Manager 2.10 + TAS 3.0 Ops Manager 3.0 + TAS 3.0 Ops Manager 2.10 + TAS 4.0 Ops Manager 3.0 + TAS 4.0
Tanzu Kubernetes Grid Integrated (TKGI)	1.17

Notas:

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.

Para una nueva implementación en TAS, solo se admite el modo Directiva.

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

• 4.1.0. 4.1.1 y todas las versiones 4.0.x.

Limitaciones

• La función de "directiva de línea base" para NCP crea un grupo dinámico que selecciona todos los miembros del clúster. NSX-T tiene un límite de 8000 miembros efectivos de un grupo dinámico (para obtener más información, consulte Valores máximos de configuración). Por lo tanto, esta función no debe habilitarse para los clústeres que se espera que crezcan más allá de los 8000 pods. Si se supera este límite, se pueden producir retrasos en la creación de recursos para los pods.

• Equilibrador de carga en modo transparente

  • Solo se admite el tráfico norte-sur para un clúster de Kubernetes. No se admite el tráfico interno en un clúster.

  • No se admite para los servicios asociados a un CRD LoadBalancer o cuando el ajuste de escala automático está habilitado. El ajuste de escala automático debe estar deshabilitado para que se pueda usar esta función.

  • Se recomienda utilizar esta función solo en clústeres recién implementados.

• Migración de Manager a Directiva

  • No es posible migrar un clúster de Kubernetes si se produjo un error en una migración anterior y el clúster se revirtió. Esta limitación solo se produce con NSX 4.0.0.1 o versiones anteriores.

• Existe el riesgo de degradación significativa del rendimiento en el cálculo de miembros del grupo real, con impacto en el tráfico de red, al implementar directivas de red que usan criterios de varios selectores en las reglas de entrada/salida. Para solucionar esta limitación, existe una nueva opción de configuración, enable_mixed_expression_groups, que afecta a las directivas de red de Kubernetes que usan varios selectores en el modo Directiva. Los clústeres en el modo Manager no se ven afectados. El valor predeterminado de esta opción es False. Recomendamos los siguientes valores en el clúster:

  • TKGi

    • Clústeres nuevos, modo Directiva: False

    • Clústeres existentes (basados en Directiva): True

    • Después de la migración de Manager a Directiva: True

  • OC: establezca en True para garantizar el cumplimiento de la directiva de red de Kubernetes

  • DIY Kubernetes

    • Nuevos clústeres (basados en Directiva): False

    • Clústeres existentes (basados en Directiva): True

    • Después de la migración de Manager a Directiva: True

  Esta limitación se aplica cuando enable_mixed_expression_groups se establece en True. Esto afecta a las instalaciones que usan NCP 3.2.0 y versiones posteriores, así como NSX-T 3.2.0 y versiones posteriores. No hay ninguna limitación en el número de espacios de nombres a los que afecta la directiva de red. Si esta opción se establece en True y se reinicia NCP, NCP volverá a sincronizar todas las directivas de red para implementar este comportamiento.

  Cuando enable_mixed_expression_groups se establece en False, las directivas de red que usan criterios de varios selectores en las reglas de entrada/salida se realizan con grupos de NSX dinámicos que no se ven afectados por ninguna degradación del rendimiento en el cálculo de los miembros reales. Sin embargo, las reglas solo se pueden aplicar en un máximo de 5 espacios de nombres, según los otros criterios definidos en la directiva de red. Si la directiva de red afecta a más de 5 espacios de nombres en algún momento específico, se anotará con "ncp/error: NETWORK_POLICY_VALIDATION_FAILED" y no se aplicará en NSX. Tenga en cuenta que esto puede ocurrir cuando se crea un nuevo espacio de nombres que cumple las condiciones de varios selectores o cuando se actualiza un espacio de nombres existente. Si esta opción se establece en False y se reinicia NCP, NCP volverá a sincronizar todas las directivas de red para implementar este comportamiento.

Problemas resueltos

• Problema 3049209: Después de la migración de Manager a Directiva, al eliminar clústeres no se elimina el recurso mp_default_LR_xxx_user_rules

  Al eliminar clústeres después una migración de Manager a Directiva, es posible que no se eliminen algunos recursos "GatewayPolicy" llamados mp_default_LR_xxxx_user_rules.

  Solución alternativa: Elimine los recursos manualmente.

• Problema 3113985: Al migrar una topología de nivel 1 única, no se migran todas las rutas estáticas

  En una topología de nivel 1 única con varios recursos personalizados de tipo loadbalancers.vmware.com, no se migran algunas rutas estáticas creadas por NCP en el modo Manager para los equilibradores de carga.

  Solución alternativa: Después de eliminar el recurso personalizado de tipo loadbalancers.vmware.com de Kubernetes, elimine manualmente la ruta estática con la API de Manager. La ruta estática tendrá el UID del recurso personalizado en sus etiquetas con el ámbito "ncp/crd_lb_uid".

• Problema 3055618: Cuando se crean varios pods Windows en un nodo de forma simultánea; algunos pods no tienen un adaptador de red

  Al aplicar un archivo YAML para crear varios pods Windows en el mismo nodo, algunos pods no tienen un adaptador de red.

  Solución alternativa: Reinicie los pods.

• Problema 3088138: Después de configurar log_file en el configmap nsx-node-agent-config, los pods de nsx-node-agent no se inician

  Si establece la opción log_file en el configmap nsx-node-agent-config y reinicia los pods de nsx-ncp-bootstrap antes de los pods de nsx-node-agent, los pods de nsx-node-agent no podrán iniciarse y tendrán el estado CrashLoopBackOff.

  Solución alternativa: Reinicie los pods de nsx-node-agent antes de reiniciar los pods de nsx-ncp-bootstrap después de configurar la opción log_file en el configmap nsx-node-agent-config.

• Problema 3091318: Se produce un error en la creación del pod después de actualizar la subred estática de un espacio de nombres cuando NCP está inactivo

  Si crea un espacio de nombres con ncp/subnets establecido, por ejemplo, a 172.70.0.0/29, y aún no se ha creado ningún pod en el espacio de nombres, y detiene NCP y actualiza ncp/subnets a, por ejemplo, 172.71.0.0/29, después de reiniciar NCP, al crear un pod en el espacio de nombres, este se puede quedar atascado en el estado "ContainerCreating".

  Solución alternativa: Vuelva a crear el pod.

• Problema 3110833: Los pods en el nodo de trabajo de Windows de TKGI no se pueden iniciar; su estado es "ContainerCreating"

  No se inician todos los nodos del nodo de trabajo de Windows. El registro nsx-node-agent en el nodo muestra continuamente el mensaje "No se pudo procesar la solicitud de configuración de cif con el error [...]. Reinicie el servicio de agente del nodo para recuperarse".

  Solución alternativa: Reinicie el servicio nsx-node-agent en el nodo.

Problemas conocidos

• Problema 3306543: Después de eliminar un pod, si se crea un nuevo pod con el mismo nombre, su configuración de red será incorrecta

  En raras ocasiones, si se elimina un pod y, a continuación, se crea uno nuevo con el mismo nombre, el nuevo pod tendrá la configuración de red del pod anterior. La configuración de red del nuevo pod será incorrecta.

  Solución alternativa: Elimine el nuevo pod, reinicie nsx-node-agent y, a continuación, vuelva a crear el pod.

• Problema 3239352: En un entorno de TAS, cuando no se puede asignar una tarea, es posible también fallen los reintentos

  En un entorno de TAS de NCP, cuando no se puede asignar una tarea, el subastador rechaza la tarea y el BBS reintenta la tarea el número de veces especificado en el ajuste task.max_retries. Cuando se alcanza el valor de task.max_retries, el BBS cambia el estado de la tarea de PENDIENTE a COMPLETADA, marcándola como fallida y explicando en FailureReason que el clúster no tiene capacidad para la tarea.

  Durante el reintento, es posible que la tarea se programe en una nueva celda que notifique a NCP un evento task_changed. Como NCP no gestiona el evento task_changed, no se puede asignar a la tarea un nuevo puerto en la nueva celda. La tarea no se puede ejecutar correctamente.

  Solución alternativa: Deshabilite el reintento y establezca el valor 0 en task.max_retries.

• Problema 3252571: La migración de Manager a Directiva nunca se completa si NSX Manager deja de estar disponible

  Si NSX Manager deja de estar disponible durante la migración de Manager a Directiva, es posible que la migración nunca se complete. Un indicador es que los registros no tendrán actualizaciones sobre la migración.

  Solución alternativa: Vuelva a establecer la conexión con NSX Manager y reinicie la migración.

• Problema 3248662: El nodo de trabajo no puede acceder a un servicio. El flujo de OVS para el servicio no se crea en el nodo.

  El registro nsx-kube-proxy muestra el mensaje de error "greenlet.error: no se puede cambiar a un subproceso diferente".

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

• Problema 3241693: Las rutas de capa 7 tardan más de 10 minutos en comenzar a funcionar cuando el número de rutas creadas supera determinados límites

  En un entorno de OpenShift, puede implementar más de 1000 rutas estableciendo las marcas "relax_scale_validation" en True y "l4_lb_auto_scaling" en False en el ConfigMap. Sin embargo, las rutas tardan más de 10 minutos en comenzar a funcionar cuando el número de rutas creadas supera el límite. Los límites son 500 rutas HTTPS y 2000 rutas HTTP.

  Solución alternativa: No supere los límites del número de rutas. Si crea 500 rutas HTTPS más 2000 HTTP, debe implementar las rutas mediante una máquina virtual de Edge de gran tamaño.

• Problema 3158230: El contenedor nsx-ncp-bootstrap no se inicializa mientras se cargan los perfiles de AppArmor en Ubuntu 20.04

  El contenedor nsx-ncp-bootstrap del DaemonSet nsx-ncp-bootstrap no se puede inicializar porque hay diferentes versiones de paquete de AppArmor en el sistema operativo del host y la imagen del contenedor. Los registros del contenedor muestran mensajes como "No se pudo cargar policy-features desde '/etc/apparmor.d/abi/2.13': no existe dicho archivo o directorio".

  Solución alternativa: Actualice AppArmor a la versión 2.13.3-7ubuntu5.2 o a la versión más reciente disponible en las actualizaciones focales del sistema operativo del host.

• Problema 3179549: No se permite el cambio del modo NAT para un espacio de nombres existente

  Para un espacio de nombres con pods existentes, si cambia el modo NAT de SNAT a NO_SNAT, los pods seguirán utilizando las direcciones IP asignadas desde los bloques de IP especificados en container_ip_blocks. Si la subred de segmentos en el espacio de nombres sigue teniendo direcciones IP disponibles, los pods recién creados seguirán usando las direcciones IP de la subred de segmentos existente. Para un segmento recién creado, la subred se asignará desde no_snat_ip_block. Sin embargo, en el espacio de nombres, se eliminará la regla SNAT.

  Solución alternativa: Ninguna.

• Problema 3218243: La directiva de seguridad en NSX creada para la directiva de red de Kubernetes que usa criterios de selección múltiple se elimina después de actualizar NCP a la versión 4.1.1 o cuando el usuario crea o actualiza el espacio de nombres

  Compruebe que la opción "enable_mixed_expression_groups" esté establecida en False en NCP (el valor predeterminado es False). Si este es el caso, la directiva de red está provocando la creación de más de 5 criterios de grupo en NSX, lo que no está permitido.

  Solución alternativa: Establezca enable_mixed_expression_groups en True en la asignación de configuración de NCP y reinicie NCP. Tenga en cuenta que existe el riesgo de una degradación significativa del rendimiento en el cálculo de miembros de grupos, lo que, en este caso, afectará al tráfico de red.

• Problema 3235394: La configuración de la directiva de línea base con el espacio de nombres no funciona en una configuración de TKGI

  En un entorno de TGKI, si establece baseline_policy_type en allow_namespace o allow_namespace_strict, NCP creará una directiva de línea base explícita para permitir que solo los pods dentro del mismo espacio de nombres se comuniquen entre sí y denieguen la entrada de otros espacios de nombres. Esta directiva de línea base también bloqueará un espacio de nombres del sistema, como kube-system, para que no pueda acceder a pods en diferentes espacios de nombres.

  Solución alternativa: Ninguna. NCP no admite esta función en una configuración de TKGI.

• Problema 3179960: La instancia de la aplicación queda inaccesible después de vMotion y tiene la misma dirección IP que otra instancia de aplicación

  Cuando se produce una operación de vMotion masiva (por ejemplo, durante la actualización de los hosts de NSX), los hosts entran en modo de mantenimiento uno por uno y las Diego Cells se migran entre los hosts. Después de vMotion, es posible que falten algunos puertos de segmentos, que no se pueda acceder a algunas instancias de aplicación y que dos instancias de aplicación tengan la misma dirección IP. Es más probable que este problema se produzca con TAS 2.13.18.

  Solución alternativa: Vuelva a crear las instancias de la aplicación afectadas por este problema.

• Problema 3108579: Se produce un error al eliminar el CRD de LB y volver a crearlo inmediatamente con el mismo secreto

  En el modo Manager, si elimina la entrada en un CRD de LB, elimina el CRD de LB y vuelve a crear inmediatamente la entrada y el CRD de LB con el mismo certificado, es posible que se muestre el error "Se intentó importar un certificado ya importado". Esto se debe a un problema de temporización porque la eliminación de CRD de LB debe esperar a que se complete la eliminación de la entrada.

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

  - Ejecute el siguiente comando para esperar a que se complete la eliminación de la entrada y, a continuación, elimine el CRD de LB.

  • kubectl exec -ti <nombre del pod> -nnsx-system -- nsxcli -c get ingress-caches|grep ‘name: <nombre de la entrada>'

  - Espere al menos 2 minutos antes de volver a crear la entrada y el CRD de LB.

• Problema 3161931: el pod nsx-ncp-bootstrap no se puede ejecutar en las máquinas virtuales de hosts Ubuntu 18.04 y Ubuntu 20.04

  El contenedor nsx-ncp-bootstrap del pod nsx-ncp-bootstrap no puede volver a cargar "AppArmor" y muestra los siguientes mensajes de registro: "No se pudo cargar policy-features desde '/etc/apparmor.d/abi/2.13': no existe dicho archivo o directorio." El problema se debe a que hay versiones diferentes del paquete "AppArmor" instaladas en la imagen utilizada para ejecutar el pod nsx-ncp-bootstrap y el sistema operativo del host. Este problema no existe en las máquinas virtuales de host Ubuntu 22.04.

  Solución alternativa: Ubuntu 18.04 no es compatible con NCP 4.1.1. En Ubuntu 20.04, actualice "AppArmor" a la versión mínima 2.13.3-7ubuntu5.2. El paquete está disponible a través de focal-updates.

• Problema 3221191: Se produce un error al crear el grupo de dominios cuando el clúster tiene más de 4000 pods

  Si la opción de NCP k8s.baseline_policy_type está establecida en allow_cluster, allow_namespace o allow_namespace_strict, y el clúster tiene más de 4000 pods, no se podrá crear el grupo de dominios (con un nombre como dg-k8sclustername), que contiene todas las direcciones IP de los pods. Esto se debe a una limitación de NSX.

  Solución alternativa: No configure la opción k8s.baseline_policy_type o asegúrese de que haya menos de 4000 pods en el clúster.

• Problema 3043496: NCP deja de ejecutarse si se produce un error en la migración de Manager a Directiva

  NCP proporciona el trabajo migrate-mp2p para migrar recursos de NSX utilizados por NCP y TKGI. Si se produce un error en la migración, todos los recursos migrados se revierten, pero NCP no se reinicia en el modo Manager.

  Solución alternativa:

  1. Asegúrese de que todos los recursos se reviertan. Para ello, compruebe los registros del trabajo migrate-mp2p. Los registros deben terminar con la línea "Todos los recursos de MP importados a Directiva se revirtieron por completo".

  2. Si se revirtieron todos los recursos, ejecute ssh en cada nodo maestro y ejecute el comando "sudo /var/vcap/bosh/bin/monit start ncp".

• 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.

• Problema 2999131: No se puede acceder a los servicios clusterIP desde los pods

  En un entorno de TKGi a gran escala, no se puede acceder a los servicios de ClusterIP desde los pods. Otros problemas relacionados son los siguientes: (1) nsx-kube-proxy deja de generar los registros de nsx-kube-proxy; y (2) los flujos de OVS no se crean en el nodo.

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

• Problema 2984240: El operador "NotIn" en matchExpressions no funciona en namespaceSelector para la regla de una directiva de red

  Al especificar una regla para una directiva de red, si especifica namespaceSelector, matchExpressions y el operador "NotIn", la regla no funcionará. El registro de NCP muestra el mensaje de error "No se admite el operador NotIn en los selectores de NS".

  Solución alternativa: Vuelva a escribir matchExpressions para evitar usar el operador "NotIn".

• 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.

• 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 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 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 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.

• 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 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 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 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 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 2824129: Un nodo tiene el estado network-unavailable con el valor true durante más de 3 minutos después de un reinicio

  Si utiliza NCP Operator para administrar el ciclo de vida de NCP, cuando un daemonset de nsx-node-agent se recupera de un estado que no está en ejecución, su nodo tendrá el estado network-unavailable con el valor true hasta que se haya estado ejecutando durante 3 minutos. Este es el comportamiento esperado.

  Solución alternativa: Espere al menos 3 minutos después de que se reinicie nsx-node-agent.

• Problema 2832480: Para un servicio de Kubernetes de tipo ClusterIP, sessionAffinityConfig.clientIP.timeoutSeconds no puede superar 65535

  Para un servicio de Kubernetes de tipo ClusterIP, si establece sessionAffinityConfig.clientIP.timeoutSeconds en un valor mayor que 65535, el valor real será 65535.

  Solución alternativa: Ninguno

• Problema: 2940772: Se produce un error al migrar recursos de NCP de Manager a Directiva con NSX-T 3.2.0

  La migración de recursos de NCP de Manager a Directiva es compatible con NSX-T 3.1.3 y NSX-T 3.2.1, pero no con NSX-T 3.2.0.

  Solución alternativa: Ninguno

• Problema 2934195: Algunos tipos de grupos de NSX no son compatibles con las reglas de firewall distribuido

  No se admiten grupos de NSX de tipo "Solo direcciones IP" para las reglas de firewall distribuido (DFW). Tampoco se admite un grupo de NSX de tipo "Genérico" con direcciones IP agregadas manualmente como miembros.

  Solución alternativa: Ninguno

• Problema 2939886: Se produce un error al migrar objetos del modo Manager al modo Directiva

  Se produce un error al migrar objetos del modo Manager al modo Directiva si, en la especificación de directiva de red, la salida y la entrada tienen el mismo selector.

  Solución alternativa: Ninguno

• Problema 3066449: Las subredes de espacio de nombres no siempre se asignan desde el primer bloque de direcciones IP disponible cuando use_ip_blocks_in_order se establece en True

  Al crear varios espacios de nombres con use_ip_blocks_in_order establecido en True, a veces no se asigna la subred del primer espacio de nombres desde el primer bloque de direcciones IP disponible. Por ejemplo, supongamos que container_ip_blocks es '172.52.0.0/28,172.53.0.0/28', y la longitud del prefijo de subred es 29, y la subred 172.52.0.0/29 ya está asignada. Si crea 2 espacios de nombres, ns-1 y ns-2, la asignación de subredes podría ser (1) ns-1: 172.52.0.8/29, ns-2: 172.53.0.0/29, o (2) ns-1: 172.53.0.0/29, ns-2: 172.52.0.8/29.

  El parámetro use_ip_blocks_in_order solo garantiza que se utilicen diferentes bloques de IP en el orden en que aparecen en el parámetro container_ip_blocks. Si se crean varios espacios de nombres al mismo tiempo, cualquier espacio de nombres puede solicitar una subred a través de una llamada API antes que otro espacio de nombres. Por tanto, no hay garantía de que a un espacio de nombres específico se le asigne una subred de un bloque de direcciones IP específico.

  Solución alternativa: Cree los espacios de nombres por separado, es decir, cree el primer espacio de nombres, asegúrese de que su subred esté asignada y, a continuación, cree el siguiente espacio de nombres.