VMware NSX Container Plugin 3.2.0.1   |   11 de noviembre de 2021   |   Compilación 18876345

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

NSX Container Plugin (NCP) 3.2.0.1 tiene las siguientes nuevas funciones:
Nota: Las nuevas funciones se admiten únicamente en el modo Directiva a menos que se mencione la compatibilidad con el modo Manager.
  • Compatibilidad con el uso del mismo certificado comodín en la entrada de Kubernetes para varios clústeres de Kubernetes (varias instancias de NCP).
  • Compatibilidad con la instalación de OpenShift con NCP mediante el método IPI (infraestructura aprovisionada del instalador), además del método UPI (infraestructura aprovisionada de usuario).
  • Nueva opción de configuración “baseline_policy_type: allow_namespace_strict”. Con esta opción establecida, la directiva predeterminada es descartar cualquier comunicación entre espacios de nombres y servicios externos, a menos que lo permitan específicamente la directiva de red de Kubernetes o las directivas de administración manuales de NSX-T.
  • Compatibilidad con el nuevo campo endPort para las directivas de red de Kubernetes.
  • Capacidad para especificar subredes para un espacio de nombres de Kubernetes. (Si se especifican subredes IPv6, no se admite el prefijo de subred de 64 bits).
  • Asignación de IP persistente de StatefulSet basada en la subred del espacio de nombres.
  • Capacidad de crear afinidad de sesión basada en IP de cliente para un servicio de Kubernetes de tipo ClusterIP. Esta función también está disponible en el modo Manager.
  • TAS en modo Directiva.

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.2
NSX-T 3.1.2, 3.1.3
vSphere 6.7, 7.0
Kubernetes 1.19, 1.20, 1.21, 1.22
OpenShift 4 RHCOS 4.6, 4.7, 4.8
Sistema operativo de máquina virtual de host de Kubernetes Ubuntu 18.04, 20.04
CentOS 7.8, 7.9, 8.2
RHEL 8.2, 8.4
Consulte las notas a continuación.
Tanzu Application Service Ops Manager 2.7 + TAS 2.7 (LTS) (Fecha de fin de soporte: 30 de abril de 2022)
Ops Manager 2.10 + TAS 2.10 (Fecha de fin de soporte: 31 de marzo de 2022)
Ops Manager 2.10 + TAS 2.11
Ops Manager 2.10 + TAS 2.12 (Fecha de fin de soporte: 31 de marzo de 2023)
Tanzu Kubernetes Grid Integrated (TKGI) 1,13

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 CentOS/RHEL son 1127, 1160, 193, 240 y 305, independientemente de la versión de CentOS/RHEL. Tenga en cuenta que la versión predeterminada del kernel es 1127 para RHEL 7.8, 1160 para RHEL 7.9, 193 para RHEL 8.2, 240 para RHEL 8.3 y 305 para RHEL 8.4. Si está ejecutando una versión de kernel diferente, puede (1) Modificar su versión del kernel a una que sea compatible. Al modificar su versión del kernel y, a continuación, reiniciar la máquina virtual, asegúrese de que la IP y las rutas estáticas se mantengan en la interfaz de vínculo superior (especificada por ovs_uplink_port) para garantizar que no se pierda la conectividad con el servidor de la API de Kubernetes. O bien, (2) 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.

Para ejecutar el módulo de kernel nsx-ovs en RHEL 8.2 (versión de kernel 193), debe deshabilitar la opción "Arranque seguro UEFI" de "Opciones de arranque" en los ajustes de la máquina virtual en vCenter Server.

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 3.1.x

 

Problemas resueltos

  • 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

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

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

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

  • 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 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 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 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 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 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 2860091: Se produce un error en el tráfico de DNS si baseline_policy_type está establecido en allow_namespace

    En un entorno de OpenShift o Kubernetes, si baseline_policy_type está establecido en allow_namespace, bloqueará los pods (hostNetwork: False) en otros espacios de nombres desde el acceso al servicio DNS.

    Solución alternativa: Agregue una directiva de red de regla para permitir el tráfico desde otros pods hacia los pods de DNS.

  • Problema 2841030: Con Kubernetes 1.22, el estado de nsx-node-agent siempre es "AppArmor"

    Con Kubernetes 1.22, cuando el estado de los pods nsx-node-agent están listos, su estado no se actualiza de "AppArmor" a "En ejecución". Esto no afecta a la funcionalidad de NCP o nsx-node-agent.

    Solución alternativa: Reinicie los pods nsx-node-agent.

  • 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 2867361: Las alarmas de nsx-node-agent e hyperbus no se eliminan después de la limpieza de NCP

    Si aparecen alarmas de nsx-node-agent e hyperbus por algún motivo (como la detención de todos los agentes de nodo de NSX), y se detiene NCP y se ejecuta el script de limpieza, las alarmas no desaparecerán después de la limpieza.

    Solución alternativa: Ninguno

  • Problema 2869247: En el sistema operativo de host Ubuntu 18.04, el contenedor nsx-ovs se sigue reiniciando

    El contenedor nsx-ovs se sigue reiniciando porque el sondeo de ejecución sigue fallando. /var/log/nsx-ujo/openvswitch/ovs-vswitchd.log contiene un registro que indica que se sigue reiniciando. Por ejemplo:

    2021-10-28T17:38:49.364Z|00004|backtrace(monitor)|WARN|Backtrace using libunwind not supported. 
2021-10-28T17:38:49.364Z|00005|daemon_unix(monitor)|WARN|2 crashes: pid 282 died, killed (Aborted), core dumped, waiting until 10 seconds since last restart 
2021-10-28T17:38:57.364Z|00006|daemon_unix(monitor)|ERR|2 crashes: pid 282 died, killed (Aborted), core dumped, restarting

    Este problema se debe a una incompatibilidad entre los paquetes de espacio de usuario de OVS ascendente instalados en el contenedor nsx-ovs y el módulo kernel de OVS en el host.

    Solución alternativa: Actualice el sistema operativo host a Ubuntu 20.0 o realice los siguientes pasos para utilizar los módulos de kernel OVS proporcionados por NSX:

    1. Establezca use_nsx_ovs_kernel_module en True en el mapa de configuración de nsx-node-agent.
    2. Quite la marca de comentario de los montajes de volumen en daemonSet nsx-ncp-bootstrap (busque "Quitar la marca de comentario de estos montajes si se instala NSX módulo kernel de OVS" y "Quite la marca de comentario de estos volúmenes si instala el módulo kernel NSX-OVS") en el archivo ncp-ubuntu*.yaml.
    3. Vuelva a aplicar el archivo ncp-ubuntu*.yaml y reinicie los pods nsx-node-agent.
  • Problema 2867871: Se produce un error en el acceso al servicio clusterIP desde los pods a los que hace referencia el servicio si el nombre del nodo de Kubernetes de los pods es diferente del nombre de host

    Actualmente, NCP admite el acceso automático del pod al servicio clusterIP solo cuando el nombre del nodo de Kubernetes es el mismo que el nombre del host. Esto se debe a que nsx-kube-proxy agrega un flujo de acceso propio solo si el nombre de host es el mismo que el nombre del nodo.

    Solución alternativa: Ninguno

  • Problema 2868572: Open vSwitch (OVS) debe deshabilitarse en la máquina virtual del host antes de ejecutar NCP

    Para implementar NCP en una máquina virtual host, primero debe detener los procesos relacionados con OVS y eliminar algunos archivos en el host mediante los siguientes comandos:

    1. sudo systemctl disable openvswitch-switch.service
    2. sudo systemctl stop openvswitch-switch.service
    3. rm -rf /var/run/openvswitch

    Si ya implementó NCP en una máquina virtual host y OVS no se está ejecutando correctamente, realice los siguientes pasos para recuperarse:

    1. Realice los 3 pasos anteriores.
    2. Elimine los pods nsx-node-agent en los nodos que tienen el problema para reiniciar los pods del agente del nodo con el comando "kubectl delete pod $agent-pod -n nsx-system".

    Solución alternativa: Consulte arriba.

  • 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 2882699: En un entorno IPv6, al establecer baseline_policy_type en allow_namespace_strict, se produce un error de comunicación

    En un entorno IPv6, con baseline_policy_type establecido en allow_namespace_strict, los pods no pueden acceder a los nodos de Kubernetes.

    Solución alternativa: Agregue una regla de firewall distribuido con mayor prioridad que la regla de línea base para permitir el tráfico desde los pods hasta los nodos de Kubernetes.

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

  • Problema 3042916: se produce un error en nsx-kube-proxy después del inicio y se muestra el error "invalid or unknown port for in_port"

    En raras ocasiones, se produce un error en nsx-kube-proxy poco después del inicio porque el vínculo superior de OVS (ofport) está vacío en ese momento. El registro muestra el mensaje de error "RuntimeError: Fatal error executing xxx: (): invalid or unknown port for in_port".

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

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

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