NSX Container Plug-in 3.0, 3.0.1 VMware NSX-T Data Center 3...Nota Al configurar NAT, el número total de direcciones IP traducidas no puede ser superior a 1000. n Implementa directivas

Guía de instalación y administración de NSX Container Plug-in para Kubernetes y Cloud Foundry

NSX Container Plug-in 3.0, 3.0.1, 3.0.2

VMware NSX-T Data Center 3.0

Puede encontrar la documentación técnica más actualizada en el sitio web de VMware:

https://docs.vmware.com/es/

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

VMware Spain, S.L.Calle Rafael Boti 262.ª plantaMadrid 28023Tel.: +34 914125000www.vmware.com/es

Copyright ©

2017-2020 VMware, Inc. Todos los derechos reservados. Información sobre el copyright y la

marca comercial.


VMware, Inc. 2

https://docs.vmware.com/es/

http://pubs.vmware.com/copyright-trademark.html

http://pubs.vmware.com/copyright-trademark.html

Contenido

Guía de instalación y administración de NSX Container Plug-in para Kubernetes y Cloud Foundry 5

1 Descripción general de NSX Container Plug-in 6Requisitos de compatibilidad 7

Descripción general de la instalación 7

2 Configurar recursos de NSX-T 9Configurar recursos de NSX-T en el modo Directiva 9

Configurar recursos de NSX-T en modo Manager 12

Configurar SNAT 15

3 Instalación de NCP en un entorno de Kubernetes 22Descargar archivos de instalación 22

Preparar nodos de Kubernetes 23

Crear secretos: Kubernetes 25

Configurar las redes de NSX-T Data Center para los nodos de Kubernetes 26

Editar el archivo YAML de NCP 27

ConfigMap nsx-ncp-config 32

ConfigMap nsx-node-agent-config 43

Aplicar el archivo YAML de NCP 47

Montar un archivo de certificado en el pod de NCP 47

Configurar IPv6 48

Configurar syslog 49

Crear un contenedor sidecar para syslog 49

Crear una réplica de DaemonSet para Syslog 51

Ejemplo: Configuración de la rotación de registros y la ejecución de Syslog en un contenedor sidecar 53

Consideraciones de seguridad 60

Configuración de recursos de red 61

Limpiar los nodos de Kubernetes 63

4 Instalación de NCP en un entorno de Pivotal Cloud Foundry 65Instalación de NCP en un entorno de Pivotal Cloud Foundry 65

Cómo gestionar las etiquetas personalizadas en PAS 67

5 Equilibrio de carga 69Configuración del equilibrio de carga 69

VMware, Inc. 3

Cómo configurar la persistencia del equilibrador de carga de Capa 4 y Capa 7 70

Ingress 71

LoadBalancer CRDs to Handle Ingress Scaling 80

Servicio de tipo LoadBalancer 83

Equilibrador de carga y directiva de red 85

Script de ejemplo para generar un certificado firmado por CA 86

Controladores de entrada de terceros 86

6 Actualizar NCP 89Actualización de NCP en un entorno de Kubernetes 89

Actualización de NCP en un entorno de Pivotal Cloud Foundry 91

7 Importar objetos de Manager a Directiva 92Flujo de trabajo de importar objetos de Manager a Directiva 92

Importar recursos compartidos 93

Importación de un clúster de Kubernetes 95

Información sobre el proceso de importación 95

Error y recuperación 97

Recursos personalizados 98

Limitaciones y soluciones alternativas 100

Orden de especificación de recursos 100

Ejemplo config.yaml 102

Ejemplo user-spec.yaml 103

8 Administrar NSX Container Plug-in 108Visualización de la información de errores almacenada en objetos NSXError de recursos de

Kubernetes 108

Limpieza del entorno de NSX-T 110

Cambiar el nombre de un clúster en ejecución 112

Comandos de la CLI 112

Códigos de error 130


VMware, Inc. 4


En esta guía se describe cómo instalar y administrar NSX Container Plug-in (NCP) para proporcionar integración entre NSX-T Data Center y Kubernetes, así como entre NSX-T Data Center y Pivotal Cloud Foundry (PCF).

Público objetivo

Esta guía está destinada a administradores de red y de sistemas. Se supone que está familiarizado con la instalación y administración de NSX-T Data Center, Kubernetes y Pivotal Cloud Foundry.

Glosario de publicaciones técnicas de VMware

Publicaciones técnicas de VMware proporciona un glosario de términos que podrían resultarle desconocidos. Si desea ver las definiciones de los términos que se utilizan en la documentación técnica de VMware, acceda a la página http://www.vmware.com/support/pubs.

VMware, Inc. 5

http://www.vmware.com/support/pubs

Descripción general de NSX Container Plug-in 1NSX Container Plug-in (NCP) integra NSX-T Data Center y orquestadores de contenedores, como Kubernetes, así como NSX-T Data Center y productos de PaaS (plataforma como servicio) basados en contenedores, como OpenShift y Pivotal Cloud Foundry. En esta guía se describe cómo configurar NCP con Kubernetes y Pivotal Cloud Foundry.

El componente principal de NCP se ejecuta en un contenedor y se comunica con NSX Manager y con el plano de control de Kubernetes. NCP supervisa los cambios de los contenedores y otros recursos, y administra los recursos de redes, como los puertos lógicos, los conmutadores, los enrutadores y los grupos de seguridad de los contenedores realizando llamadas a NSX API.

El complemento CNI de NSX se ejecuta en cada nodo de Kubernetes. Supervisa los eventos del ciclo de vida de los contenedores, conecta una interfaz de contenedor al vSwitch invitado y programa este vSwitch para que etiquete y reenvíe el tráfico entre las interfaces de contenedor y la VNIC.

NCP ofrece las siguientes funcionalidades:

n Crea de manera automática una topología lógica de NSX-T Data Center para un clúster de Kubernetes y crea una red lógica independiente para cada espacio de nombres de Kubernetes.

n Conecta pods de Kubernetes a la red lógica y asigna direcciones IP y MAC.

n Admite la traducción de direcciones de red (Network Address Translation, NAT) y asigna una dirección IP de SNAT independiente para cada espacio de nombres de Kubernetes.

Nota Al configurar NAT, el número total de direcciones IP traducidas no puede ser superior a 1000.

n Implementa directivas de red de Kubernetes con el firewall distribuido de NSX-T Data Center.

n Compatibilidad con las directivas de red de entrada y salida.

n Compatibilidad con el selector IPBlock en las directivas de red.

n Compatibilidad con matchLabels y matchExpression al especificar selectores de etiquetas para directivas de redes.

n Compatibilidad con la selección de pods en otro espacio de nombres.

VMware, Inc. 6

n Implementa el servicio de Kubernetes de tipo ClusterIP y el servicio de tipo LoadBalancer.

n Implementa la entrada de Kubernetes con el equilibrador de carga de capa 7 de NSX-T.

n Compatibilidad con las entradas de HTTP y de HTTPS con terminación de Edge de TLS.

n Compatibilidad con la configuración de back-end predeterminada de entrada.

n Compatibilidad con el redireccionamiento de HTTPS, la reescritura de rutas y la coincidencia de patrones de ruta.

n Crea etiquetas en el puerto de conmutador lógico de NSX-T Data Center para el espacio de nombres, el nombre de pod y las etiquetas de un pod, y permite al administrador definir directivas y grupos de seguridad de NSX-T con base en etiquetas.

En esta versión, NCP solo admite un clúster de Kubernetes. Puede tener varios clústeres de Kubernetes, cada uno con una instancia NCP particular, con la misma implementación de NSX-T Data Center.

Este capítulo incluye los siguientes temas:

n Requisitos de compatibilidad

n Descripción general de la instalación

Requisitos de compatibilidad

Para conocer los requisitos de compatibilidad, consulte las notas de la versión.

Notas de la versión de NCP 3.0.0: https://docs.vmware.com/es/VMware-NSX-T-Data-Center/3.0/rn/NSX-Container-Plugin-30-Release-Notes.html

Notas de la versión de NCP 3.0.1: https://docs.vmware.com/es/VMware-NSX-T-Data-Center/3.0/rn/NSX-Container-Plugin-301-Release-Notes.html

Descripción general de la instalación

En un entorno con Kubernetes, la instalación y configuración de NCP suele incluir los siguientes pasos. Para realizar los pasos correctamente, debe estar familiarizado con la instalación y administración de NSX-T Data Center y Kubernetes.

1 Instale NSX-T Data Center.

2 Crear una zona de transporte superpuesta.

3 Crear un conmutador lógico superpuesto y conectar los nodos de Kubernetes al conmutador.

4 Crear un enrutador lógico de nivel 0.

5 Crear bloques de IP para los pods de Kubernetes.

6 Crear grupos de IP para la traducción de direcciones de red de origen (Source Network Address Translation, SNAT).

7 Instalar el complemento CNI (interfaz de red de los contenedores) de NSX en cada nodo.


VMware, Inc. 7

https://docs.vmware.com/es/VMware-NSX-T-Data-Center/3.0/rn/NSX-Container-Plugin-30-Release-Notes.html




8 Instalar OVS (Open vSwitch) en cada nodo.

9 Configurar las redes de NSX-T para los nodos de Kubernetes.

10 Instalar el agente del nodo de NSX como DaemonSet.

11 Instalar NCP como ReplicationController.

12 Montar certificados de seguridad en el pod de NCP.


VMware, Inc. 8

Configurar recursos de NSX-T 2Antes de instalar NCP, debe configurar algunos recursos de NSX-T.

Nota: Cuando se instala NSX-T, la licencia predeterminada no permite la creación ni la actualización de los objetos necesarios para poder utilizar NCP. Para obtener más información, consulte https://docs.vmware.com/es/VMware-NSX-T-Data-Center/3.0/administration/GUID-8E665EAC-A44D-4FB3-B661-E00C467B2ED5.html.

La interfaz de usuario web de NSX Manager incluye dos métodos para configurar recursos de red: el modo Directiva y el modo Manager. Para obtener más información, consulte https://docs.vmware.com/es/VMware-NSX-T-Data-Center/3.0/administration/GUID-BB26CDC8-2A90-4C7E-9331-643D13FEEC4A.html.

Debe utilizar uno de los dos métodos para configurar las redes de NSX-T para NCP, pero no ambos. Debe configurar la opción policy_nsxapi en el archivo YAML de NCP con el valor True si utiliza el modo Directiva, o con el valor False si utiliza el modo Manager.

En las siguientes secciones, se asume que está familiarizado con la instalación y administración de NSX-T Data Center. Puede consultar más información en la Guía de instalación de NSX-T Data Center y la Guía de administración de NSX-T Data Center.


n Configurar recursos de NSX-T en el modo Directiva

n Configurar recursos de NSX-T en modo Manager

n Configurar SNAT

Configurar recursos de NSX-T en el modo Directiva

Existen dos formas para configurar ciertos recursos de red de NCP. En esta sección se describe cómo configurar los recursos en el modo Directiva.

VMware, Inc. 9

https://docs.vmware.com/es/VMware-NSX-T-Data-Center/3.0/administration/GUID-8E665EAC-A44D-4FB3-B661-E00C467B2ED5.html

https://docs.vmware.com/es/VMware-NSX-T-Data-Center/3.0/administration/GUID-8E665EAC-A44D-4FB3-B661-E00C467B2ED5.html

https://docs.vmware.com/es/VMware-NSX-T-Data-Center/3.0/administration/GUID-BB26CDC8-2A90-4C7E-9331-643D13FEEC4A.html



En el archivo de configuración de NCP ncp.ini, debe especificar los recursos de NSX-T usando sus identificadores de recursos. Por lo general, el nombre y el identificador de un recurso son iguales. Para estar completamente seguro, en la interfaz de usuario web de NSX Manager, haga clic en el icono de 3 puntos que muestra las opciones de un recurso y seleccione Copiar ruta de acceso en el portapapeles. Pegue la ruta en una aplicación, como el Bloc de notas. La última parte de la ruta de acceso es el identificador de recurso.

Puertas de enlace y segmento

1 Cree un segmento para los nodos de Kubernetes, por ejemplo, Segment1.

2 Cree una puerta de enlace de nivel 0, por ejemplo, T0GW1. Configure la opción top_tier_router en la sección [nsx_v3] de ncp.ini con el identificador de la puerta de enlace si no tiene ninguna topología de nivel 1 compartida. Consulte a continuación información sobre la configuración de una topología de nivel 1 compartida. Establezca el modo de alta disponibilidad en activo-en espera si tiene previsto configurar reglas NAT en esta puerta de enlace. De lo contrario, establézcalo en activo-activo. Habilite la redistribución de rutas. Configure también esta puerta de enlace para acceder a la red externa.

3 Cree una puerta de enlace de nivel 1, por ejemplo, T1GW1. Conecte esta puerta de enlace a la puerta de enlace de nivel 0.

4 Configure el anuncio de enrutador para T1GW1. Como mínimo, deben estar habilitadas las rutas NAT y conectadas por NSX.

5 Conecte T1GW1 a Segment1. Asegúrese de que la dirección IP del puerto de la puerta de enlace no entre en conflicto con las direcciones IP de los nodos de Kubernetes.

6 Para cada máquina virtual del nodo, asegúrese de que el vNIC del tráfico de los contenedores esté conectado al conmutador lógico que se crea automáticamente. Puede encontrarlo en la pestaña Redes con el mismo nombre que el segmento (Segment1).

NCP debe conocer el identificador de la VIF de la vNIC. Vaya a Redes > Segmentos para ver los puertos del segmento 1 creados automáticamente. Estos puertos no se pueden editar, excepto por la propiedad de su etiqueta. Estos puertos deben tener las etiquetas que se indican a continuación. En una etiqueta, especifique el nombre del nodo. En la otra etiqueta, especifique el nombre del clúster. Para especificar el ámbito, utilice los valores adecuados que se indican a continuación.

Etiqueta Ámbito

Nombre del nodo ncp/node_name

Nombre del clúster ncp/cluster

Estas etiquetas se propagan automáticamente a los puertos de los conmutadores lógicos correspondientes. Si el nombre del nodo cambia, deberá actualizar la etiqueta. Para recuperar el nombre del nodo, puede ejecutar el siguiente comando:

kubectl get nodes


VMware, Inc. 10

Si desea ampliar el clúster de Kubernetes mientras se está ejecutando NCP, por ejemplo, agregando más nodos al clúster, deberá agregar las etiquetas a los puertos de conmutador correspondientes antes de ejecutar "kubeadm join". Si olvida añadir las etiquetas antes de ejecutar "kubeadm join", los nuevos nodos no tendrán conectividad. En este caso, debe agregar las etiquetas y reiniciar NCP para resolver el problema.

Para identificar el puerto del conmutador de una máquina virtual de nodo, puede hacer la siguiente llamada API:

/api/v1/fabric/virtual-machines

En la respuesta, busque la máquina virtual del nodo y recupere el valor del atributo "external_id". O bien, puede hacer la siguiente llamada API:

/api/v1/search -G --data-urlencode "query=(resource_type:VirtualMachine AND

display_name:<node_vm_name>)"

Una vez que tenga el identificador externo, puede utilizarlo para recuperar la VIF de la máquina virtual con la siguiente API. Tenga en cuenta que las VIF no se rellenan hasta que se inicia la máquina virtual.

/api/v1/search -G --data-urlencode \

"query=(resource_type:VirtualNetworkInterface AND external_id:<node_vm_ext_id> AND \

_exists_:lport_attachment_id)"

El atributo lport_attachment_id es el identificador de la VIF de la máquina virtual del nodo. A continuación, puede encontrar el puerto lógico para esta VIF y agregar las etiquetas necesarias.

Bloques de IP para los pods de Kubernetes

Vaya Redes > Administración de direcciones IP > Grupos de direcciones IP > Bloques de direcciones IP para crear uno o varios bloques de IP. Especifique el bloque de IP en formato CIDR Configure la opción container_ip_blocks en la sección [nsx_v3] de ncp.ini para los UUID de los bloques de IP. Si desea que NCP cree automáticamente bloques de IP, puede establecer la opción container_ip_blocks con una lista de direcciones separadas por comas en formato CIDR. Tenga en cuenta que no puede establecer container_ip_blocks para los UUID y también para las direcciones CIDR.

De forma predeterminada, los proyectos comparten bloques de IP especificados en container_ip_blocks. Puede crear bloques de IP específicamente para espacios de nombres no SNAT (en Kubernetes) o clústeres (en PCF) si configura la opción no_snat_ip_blocks en la sección [nsx_v3] de ncp.ini.

Si crea bloques de IP que no sean SNAT mientras NCP se ejecuta, debe reiniciar NCP. De lo contrario, NCP seguirá usando los bloques de IP compartidos hasta que se agoten.

Cuando cree un bloque de IP, el prefijo no debe tener una longitud superior al valor de la opción subnet_prefix en el archivo de configuración de NCP ncp.ini. El valor predeterminado es 24.


VMware, Inc. 11

Grupos de direcciones IP externas

El grupo de direcciones IP externas se usa para asignar las direcciones IP que se usarán para traducir las IP de los pods mediante reglas SNAT y para exponer los controladores de entrada y los servicios de tipo LoadBalancer a través de reglas SNAT/DNAT, igual que las IP flotantes de OpenStack. Estas direcciones IP también se denominan "IP externas".

Vaya Redes > Administración de direcciones IP > Grupos de direcciones IP para crear un grupo de direcciones IP. Configure la opción external_ip_pools en la sección [nsx_v3] de ncp.ini para los UUID de los grupos de direcciones IP. Si desea que NCP cree automáticamente grupos de IP, puede establecer la opción external_ip_pools con una lista de direcciones separadas por comas en formato CIDR IP o rangos de IP. Tenga en cuenta que no puede establecer external_ip_pools para los UUID y también para las direcciones CIDR.

Varios clústeres de Kubernetes usan el mismo grupo de IP externas. Cada instancia de NCP usa un subgrupo de este grupo para el clúster de Kubernetes que administra. De forma predeterminada, se usará el mismo prefijo de subred para subredes de pods. Para usar un tamaño de subred diferente, actualice la opción external_subnet_prefix en la sección [nsx_v3] de ncp.ini.

Puede utilizar otro grupo de direcciones IP cambiando el archivo de configuración y reiniciando NCP.

Topología de nivel 1 compartida

Para habilitar una topología de nivel 1 compartida, realice las siguientes configuraciones:

n Establezca la opción top_tier_router para el identificador de una puerta de enlace de nivel 1. Conecte la puerta de enlace de nivel 1 a una puerta de enlace de nivel 0 para las conexiones externas.

n Si se habilita SNAT para el tráfico del pod, modifique el vínculo superior del segmento para los nodos de Kubernetes a la misma puerta de enlace de nivel 0 o nivel 1 que se estableció en top_tier_router.

n Establezca la opción single_tier_topology en el valor True. El valor predeterminado es False.

n Si desea que NCP configure automáticamente el enrutador de nivel superior como una puerta de enlace de nivel 1, anule la opción top_tier_router y establezca la opción tier0_gateway. NCP creará una puerta de enlace de nivel 1 y la vinculará a la puerta de enlace de nivel 0 especificada en la opción tier0_gateway.

Configurar recursos de NSX-T en modo Manager

Existen dos formas para configurar ciertos recursos de red de NCP. En esta sección se describe cómo configurar los recursos en el modo Manager.


VMware, Inc. 12

En el archivo de configuración de NCP ncp.ini, puede especificar los recursos de NSX-T usando sus UUID o nombres.

Enrutadores lógicos y conmutadores lógicos

1 Cree un conmutador lógico para los nodos de Kubernetes, por ejemplo, LS1.

2 Cree un enrutador lógico de nivel 0, por ejemplo, T0LR1. Configure la opción tier0_router en la sección [nsx_v3] de ncp.ini con el identificador del enrutador lógico si no tiene ninguna topología de nivel 1 compartida. Consulte a continuación información sobre la configuración de una topología de nivel 1 compartida. Establezca el modo de alta disponibilidad en activo-en espera si tiene previsto configurar reglas NAT en este enrutador lógico. De lo contrario, establézcalo en activo-activo. Habilite la redistribución de rutas. Configure también este enrutador para acceder a la red externa.

3 Cree un enrutador lógico de nivel 1, por ejemplo, T1LR1. Conecte este enrutador lógico al enrutador lógico de nivel 0.

4 Configure el anuncio de enrutador para T1LR1. Como mínimo, deben estar habilitadas las rutas NAT y conectadas por NSX.

5 Conecte T1LR1 a LS1. Asegúrese de que la dirección IP del puerto del enrutador lógico no entre en conflicto con las direcciones IP de los nodos de Kubernetes.

6 Para cada máquina virtual del nodo, asegúrese de que el vNIC del tráfico de los contenedores esté conectado al conmutador lógico que se crea automáticamente. Puede encontrarlo en la pestaña Redes con el mismo nombre que el conmutador lógico (LS1).

NCP debe conocer el identificador de la VIF de la vNIC. Los puertos de conmutadores lógicos deben tener las dos siguientes etiquetas: En una etiqueta, especifique el nombre del nodo. En la otra etiqueta, especifique el nombre del clúster. Para especificar el ámbito, utilice los valores adecuados que se indican a continuación.

Etiqueta Ámbito



Si el nombre del nodo cambia, deberá actualizar la etiqueta. Para recuperar el nombre del nodo, puede ejecutar el siguiente comando:

kubectl get nodes

Si desea ampliar el clúster de Kubernetes mientras se está ejecutando NCP, por ejemplo, agregando más nodos al clúster, deberá agregar las etiquetas a los puertos de conmutador correspondientes antes de ejecutar "kubeadm join". Si olvida añadir las etiquetas antes de ejecutar "kubeadm join", los nuevos nodos no tendrán conectividad. En este caso, debe agregar las etiquetas y reiniciar NCP para resolver el problema.


VMware, Inc. 13

Para identificar el puerto del conmutador de una máquina virtual de nodo, puede hacer la siguiente llamada API:

/api/v1/fabric/virtual-machines

En la respuesta, busque la máquina virtual del nodo y recupere el valor del atributo "external_id". O bien, puede hacer la siguiente llamada API:

/api/v1/search -G --data-urlencode "query=(resource_type:VirtualMachine AND

display_name:<node_vm_name>)"

Una vez que tenga el identificador externo, puede utilizarlo para recuperar la VIF de la máquina virtual con la siguiente API. Tenga en cuenta que las VIF no se rellenan hasta que se inicia la máquina virtual.

/api/v1/search -G --data-urlencode \

"query=(resource_type:VirtualNetworkInterface AND external_id:<node_vm_ext_id> AND \

_exists_:lport_attachment_id)"

El atributo lport_attachment_id es el identificador de la VIF de la máquina virtual del nodo. A continuación, puede encontrar el puerto lógico para esta VIF y agregar las etiquetas necesarias.

Bloques de IP para los pods de Kubernetes

Vaya Redes > Grupos de direcciones IP para crear uno o varios bloques de IP. Especifique el bloque de IP en formato CIDR Configure la opción container_ip_blocks en la sección [nsx_v3] de ncp.ini para los UUID de los bloques de IP.

De forma predeterminada, los proyectos comparten bloques de IP especificados en container_ip_blocks. Puede crear bloques de IP específicamente para espacios de nombres no SNAT (en Kubernetes) o clústeres (en PCF) si configura la opción no_snat_ip_blocks en la sección [nsx_v3] de ncp.ini.

Si crea bloques de IP que no sean SNAT mientras NCP se ejecuta, debe reiniciar NCP. De lo contrario, NCP seguirá usando los bloques de IP compartidos hasta que se agoten.

Cuando cree un bloque de IP, el prefijo no debe tener una longitud superior al valor de la opción subnet_prefix en el archivo de configuración de NCP ncp.ini. El valor predeterminado es 24.

NCP asignará subredes adicionales para un espacio de nombres si se ha agotado la subred asignada originalmente.

Grupos de direcciones IP externas

El grupo de direcciones IP externas se usa para asignar las direcciones IP que se usarán para traducir las IP de los pods mediante reglas SNAT y para exponer los controladores de entrada y los servicios de tipo LoadBalancer a través de reglas SNAT/DNAT, igual que las IP flotantes de OpenStack. Estas direcciones IP también se denominan "IP externas".


VMware, Inc. 14

Vaya Redes > Grupos de direcciones IP > Grupos de direcciones IP para crear un grupo de direcciones IP. Configure la opción external_ip_pools en la sección [nsx_v3] de ncp.ini para los UUID de los grupos de direcciones IP.

Varios clústeres de Kubernetes usan el mismo grupo de IP externas. Cada instancia de NCP usa un subgrupo de este grupo para el clúster de Kubernetes que administra. De forma predeterminada, se usará el mismo prefijo de subred para subredes de pods. Para usar un tamaño de subred diferente, actualice la opción external_subnet_prefix en la sección [nsx_v3] de ncp.ini.

Puede utilizar otro grupo de direcciones IP cambiando el archivo de configuración y reiniciando NCP.

Topología de nivel 1 compartida

Para habilitar una topología de nivel 1 compartida, realice las siguientes configuraciones:

n Establezca la opción top_tier_router con el identificador de un enrutador lógico de nivel 0 o de nivel 1. Si se trata de un enrutador lógico de nivel 1, deberá conectarlo a un enrutador lógico de nivel 0 para conexiones externas. Esta opción reemplaza la opción tier0_router.

n Si está habilitado SNAT para tráfico de pod, desconecte T1LR1 de LS1 (el conmutador lógico de los nodos de Kubernetes) y conecte el enrutador de nivel 0 o 1 establecido en top_tier_router a LS1.

n Establezca la opción single_tier_topology en el valor True. El valor predeterminado es False.

(Opcional) (Solo para Kubernetes) Secciones de marcador de firewall

Para que el administrador pueda crear reglas de firewall que no interfieran con las secciones de firewall creadas por NCP en función de las directivas de red, acceda a Seguridad > Firewall distribuido > General y cree dos secciones de firewall.

Especifique secciones de firewall del marcador configurando las opciones bottom_firewall_section_marker y top_firewall_section_marker en la sección [nsx_v3] de ncp.ini.

La sección del firewall inferior debe estar bajo la sección del firewall superior. Con estas secciones del firewall, todas las secciones del firewall creadas por NCP para el aislamiento se crearán sobre la sección del firewall inferior, y todas las secciones del firewall creadas por NCP para la directiva se crearán bajo la sección del firewall superior. Si no se crean estas secciones de marcador, todas las reglas de aislamiento se crearán en la parte inferior, y todas las secciones de la directiva se crearán en la parte superior. No puede haber varias secciones del firewall de marcador con el mismo valor en cada clúster, ya que se producirá un error.

Configurar SNAT


VMware, Inc. 15

Restringir un grupo de direcciones IP de SNAT a espacios de nombres de Kubernetes u organizaciones de PCF específicos

Puede especificar el espacio de nombres de Kubernetes o la organización de PCF a los que es posible asignar direcciones IP del grupo de direcciones IP de SNAT agregando las siguientes etiquetas al grupo de direcciones IP.

n Para un espacio de nombres de Kubernetes: scope: ncp/owner, tag: ns:<namespace_UUID>

n Para una organización de PCF: en el ámbitoscope: ncp/owner, tag: org:<org_UUID>.

Puede obtener el UUID del espacio de nombres o de la organización mediante uno de los siguientes comandos:

kubectl get ns -o yaml

cf org <org_name> --guid

Tenga en cuenta lo siguiente:

n Cada etiqueta debe especificar un UUID. Puede crear varias etiquetas para el mismo grupo.

n Si se cambian las etiquetas después de que se asignen direcciones IP a algunos espacios de nombres u organizaciones en función de las etiquetas anteriores, no se recuperarán dichas direcciones IP hasta que se cambien los ajustes de SNAT de los servicios de Kubernetes o las aplicaciones de PCF, o bien se reinicie NCP.

n Las etiquetas de propietario del espacio de nombres y de la organización de PCF son opcionales. Sin estas etiquetas, se pueden asignar direcciones IP del grupo de direcciones IP de SNAT a cualquier espacio de nombres u organización de PCF.

Configurar un grupo de direcciones IP de SNAT para un servicio

Puede configurar un grupo de direcciones IP de SNAT para un servicio agregando una anotación al servicio. Por ejemplo,

apiVersion: v1

kind: Service

metadata:

name: svc-example

annotations:

ncp/snat_pool: <external IP pool ID or name>

selector:

app: example

...

El grupo de direcciones IP especificado por ncp/snat_pool debe tener la etiqueta scope: ncp/owner, tag: cluster:<cluster_name>.


VMware, Inc. 16

NCP configurará la regla SNAT para este servicio. La IP de origen de la regla es el conjunto de pods de back-end. La IP de destino es la IP SNAT asignada desde el grupo de IP externo especificado. Si se produce un error cuando NCP configura la regla SNAT, se agregará la nota ncp/error.snat:<error> al servicio. Los posibles errores son:

n IP_POOL_NOT_FOUND: el grupo de IP de SNAT no se encuentra en NSX Manager.

n IP_POOL_EXHAUSTED: el grupo de IP de SNAT se agotó.

n IP_POOL_NOT_UNIQUE: el grupo que ncp/snat_pool especifica hace referencia a varios grupos en NSX Manager.

n SNAT_POOL_ACCESS_DENY: la etiqueta de propietario del grupo no coincide con el espacio de nombres del servicio que envía la solicitud de asignación.

n SNAT_RULE_OVERLAPPED: se crea una nueva regla SNAT, pero el pod del servicio SNAT también pertenece a otro servicio SNAT (es decir, hay varias reglas SNAT para el mismo pod).

n POOL_ACCESS_DENIED: el grupo de direcciones IP que ncp/snat_pool especifica no tiene la etiqueta scope: ncp/owner, tag: cluster:<cluster_name> o la etiqueta de propietario del grupo no coincide con el espacio de nombres del servicio que envía la solicitud de asignación.


n El grupo especificado por ncp/snat_pool ya debe existir en NSX-T Data Center antes de configurar el servicio.

n En NSX-T Data Center, la prioridad de la regla SNAT para el servicio es mayor que la del proyecto.

n Si se configura un pod con varias reglas SNAT, solo funcionará una.

n Puede utilizar otro grupo de direcciones IP cambiando la anotación y reiniciando NCP.

Configurar un grupo de direcciones IP de SNAT para un espacio de nombres

Puede configurar un grupo de direcciones IP de SNAT para un espacio de nombres agregando una anotación al espacio de nombres. Por ejemplo,

apiVersion: v1

kind: Namespace

metadata:

name: ns-sample

annotations:

ncp/snat_pool: <external IP pool ID or name>

...


VMware, Inc. 17

NCP configurará la regla SNAT para este espacio de nombres. La IP de origen de la regla es el conjunto de pods de back-end. La IP de destino es la IP SNAT asignada desde el grupo de IP externo especificado. Si se produce un error cuando NCP configura la regla SNAT, se agregará la nota ncp/error.snat:<error> al espacio de nombres. Los posibles errores son:

n IP_POOL_NOT_FOUND: el grupo de IP de SNAT no se encuentra en NSX Manager.


n IP_POOL_NOT_UNIQUE: el grupo que ncp/snat_pool especifica hace referencia a varios grupos en NSX Manager.

n POOL_ACCESS_DENIED: el grupo de direcciones IP que ncp/snat_pool especifica no tiene la etiqueta scope: ncp/owner, tag: cluster:<cluster_name> o la etiqueta de propietario del grupo no coincide con el espacio de nombres que envía la solicitud de asignación.


n Solo puede especificar un grupo de direcciones IP de SNAT en la anotación.

n No es necesario que el grupo de direcciones IP de SNAT esté configurado en ncp.ini.

n El grupo de direcciones IP especificado por ncp/snat_pool debe tener la etiqueta scope: ncp/owner, tag: cluster:<cluster_name>.

n El grupo de direcciones IP que ncp/snat_pool especifica también puede tener una etiqueta de espacio de nombres scope: ncp/owner, tag: ns:<namespace_UUID>.

n Si falta la anotación ncp/snat_pool, el espacio de nombres utilizará el grupo de direcciones IP de SNAT para el clúster.

n Puede utilizar otro grupo de direcciones IP cambiando la anotación y reiniciando NCP.

Configurar una dirección IP de SNAT para un servicio

Puede configurar una dirección IP de SNAT para un servicio agregando una anotación al servicio. Por ejemplo,

apiVersion: v1

kind: Service

metadata:

name: svc-example

annotations:

ncp/static_snat_ip: "1.2.3.4"

...


VMware, Inc. 18

Si también se especifica la anotación ncp/snat_pool, la dirección IP de SNAT debe estar en el grupo de direcciones SNAT especificado. De lo contrario, deberá estar en el grupo de direcciones IP externas especificado en ncp.ini. Si no hay errores, NCP creará o actualizará la regla SNAT mediante la dirección IP de SNAT anotada para este servicio. El estado de la configuración de la regla SNAT se anotará con ncp/snat_ip_status en el servicio. Los valores posibles son:

n IP_ALLOCATED_SUCCESSFULLY

n IP_ALREADY_ALLOCATED: la dirección IP ya está asignada.

n IP_NOT_IN_POOL: la dirección IP no se encuentra en el grupo de direcciones IP de SNAT.


n SNAT_PROCESS_FAILED: se produjo un error desconocido.

Configurar una dirección IP de SNAT para un espacio de nombres

Puede configurar una dirección IP de SNAT para un espacio de nombres agregando una anotación al espacio de nombres. Por ejemplo,

apiVersion: v1

kind: Namespace

metadata:

name: svc-example

annotations:

ncp/static_snat_ip: "1.2.3.4"

...

Si también se especifica la anotación ncp/snat_pool, la dirección IP de SNAT debe estar en el grupo de direcciones SNAT especificado. De lo contrario, deberá estar en el grupo de direcciones IP externas especificado en ncp.ini. Si no hay errores, NCP creará o actualizará la regla SNAT mediante la dirección IP de SNAT anotada para este espacio de nombres. El estado de la configuración de la regla SNAT se anotará con ncp/snat_ip_status en el espacio de nombres. Los valores posibles son:

n IP_ALLOCATED_SUCCESSFULLY

n IP_ALREADY_ALLOCATED: la dirección IP ya está asignada.

n IP_NOT_IN_POOL: la dirección IP no se encuentra en el grupo de direcciones IP de SNAT.

n IP_NOT_REALIZED: se produjo un error en NSX-T.


n SNAT_PROCESS_FAILED: se produjo un error desconocido.


VMware, Inc. 19

Configurar un grupo de SNAT para una aplicación PAS

NCP configura la IP de SNAT de una organización de PAS (Pivotal Application Service) de forma predeterminada. Puede configurar una IP de SNAT para una aplicación mediante la creación de una aplicación con un archivo manifest.xml que contiene la información del grupo de direcciones IP de SNAT. Por ejemplo,

applications:

- name: frontend

memory: 32M

disk_quota: 32M

buildpack: go_buildpack

env:

GOPACKAGENAME: example-apps/cats-and-dogs/frontend

NCP_SNAT_POOL: <external IP pool ID or name>

...

NCP configurará la regla SNAT de esta aplicación. La IP de origen de la regla es el conjunto de direcciones IP de las instancias, mientras que la IP de destino es la IP de SNAT que se asigna a partir de un grupo de direcciones IP externo. Tenga en cuenta lo siguiente:

n El grupo que especifica NCP_SNAT_POOL ya debe existir en NSX-T Data Center antes de insertar la aplicación.

n La prioridad de la regla SNAT de una aplicación es mayor que la de una organización.

n Una aplicación puede configurarse con solo una IP de SNAT.

n Puede utilizar otro grupo de direcciones IP cambiando la configuración y reiniciando NCP.

Configurar SNAT para la versión 3 de PCF

Con la versión 3 de PCF, puede configurar SNAT de dos formas:

n Configure NCP_SNAT_POOL en manifest.yml al crear la aplicación.

Por ejemplo, la aplicación se denomina bread y el archivo manifest.yml tiene la siguiente información:

applications:

- name: bread

stack: cflinuxfs2

random-route: true

env:

NCP_SNAT_POOL: AppSnatExternalIppool

processes:

- type: web

disk_quota: 1024M

instances: 2

memory: 512M

health-check-type: port

- type: worker

disk_quota: 1024M


VMware, Inc. 20

health-check-type: process

instances: 2

memory: 256M

timeout: 15

Ejecute los siguientes comandos:

cf v3-push bread

cf v3-apply-manifest -f manifest.yml

cf v3-apps

cf v3-restart bread

n Configure NCP_SNAT_POOL mediante el comando cf v3-set-env.

Ejecute los siguientes comandos (se asume que la aplicación se denomina app3):

cf v3-set-env app3 NCP_SNAT_POOL AppSnatExternalIppool

(optional) cf v3-stage app3 -package-guid <package-guid> (You can get package-guid with "cf v3-

packages app3".)

cf v3-restart app3


VMware, Inc. 21

Instalación de NCP en un entorno de Kubernetes 3Para instalar NSX Container Plug-in (NCP), es necesario instalar componentes en los nodos principal y de trabajo. La mayoría de los pasos están automatizados.


n Descargar archivos de instalación

n Preparar nodos de Kubernetes

n Crear secretos: Kubernetes

n Configurar las redes de NSX-T Data Center para los nodos de Kubernetes

n Editar el archivo YAML de NCP

n ConfigMap nsx-ncp-config

n ConfigMap nsx-node-agent-config

n Aplicar el archivo YAML de NCP

n Montar un archivo de certificado en el pod de NCP

n Configurar IPv6

n Configurar syslog

n Consideraciones de seguridad

n Configuración de recursos de red

n Limpiar los nodos de Kubernetes

Descargar archivos de instalación

Para instalar NCP, descargue el archivo YAML de NCP y la imagen del docker para su entorno.

Para un clúster de Kubernetes con nodos Ubuntu, descargue ncp-ubuntu.yaml y la imagen nsx-ncp-ubuntu. Para un clúster Kubernetes con nodos RHEL, descargue ncp-rhel.yaml y la imagen nsx-ncp-rhel.

Ejecute el siguiente comando para cargar la imagen del docker:

VMware, Inc. 22

docker load -i nsx-ncp-ubuntu-<version>.<build_no>.tar

o

docker load -i nsx-ncp-rhel-<version>.<build_no>.tar

Ejecute el siguiente comando para comprobar el nombre de la imagen cargada:

docker images ls | grep ncp

Preparar nodos de Kubernetes

La mayoría de los pasos para preparar los nodos de Kubernetes se automatizan con dos contenedores, nsx-ovs y nsx-ncp-bootstrap, que se ejecutan en los DaemonSets sx-node-agent y nsx-ncp-bootstrap, respectivamente.

Antes de instalar NCP, asegúrese de que los nodos de Kubernetes tengan instalado Python y se pueda acceder a ellos a través de la interfaz de línea de comandos. Puede utilizar el administrador del paquete de Linux para instalarlo. Por ejemplo, en Ubuntu, puede ejecutar el comando apt install python.

En Ubuntu, al instalar el complemento CNI de NSX-T, se copiará el archivo de perfil de AppArmor ncp-apparmor en /etc/apparmor.d y se cargará. Antes de la instalación, el servicio de AppArmor debe estar en ejecución y el directorio /etc/apparmor.d debe existir. De lo contrario, se producirá un error en la instalación. Puede comprobar si el módulo de AppArmor está habilitado con el siguiente comando:

sudo cat /sys/module/apparmor/parameters/enabled

Puede comprobar si el servicio de AppArmor se inició con el siguiente comando:

sudo /etc/init.d/apparmor status

El archivo de perfil ncp-apparmor proporciona un perfil de AppArmor para el agente de nodo NSX llamado node-agent-apparmor, que se diferencia del perfil docker-default en los siguientes aspectos:

n Se elimina la regla deny mount.

n Se agrega la regla mount.

n Se agregan algunas opciones de network, capability, file y umount.

Puede reemplazar el perfil node-agent-apparmor con otro perfil. Si lo hace, debe cambiar el nombre del perfil node-agent-apparmor en el archivo YAML de NCP.


VMware, Inc. 23

El contenedor de arranque de NCP de NSX automatiza la instalación y la actualización de NSX CNI en el host. En versiones anteriores, NSX CNI se instalaba a través de un paquete deb/rpm. En esta versión, los archivos simplemente se copian en el host. El contenedor de arranque quitará los componentes de NSX CNI instalados anteriormente de la base de datos del administrador de paquetes. Se eliminarán los siguientes directorios y archivos:

n /etc/cni/net.d

n /etc/apparmor.d/ncp-apparmor

n /opt/cni/bin/nsx

El contenedor de arranque comprueba el archivo 10-nsx.conf y busca el número de versión de CNI en la etiqueta nsxBuildVersion. Si esta versión es anterior a la del contenedor de arranque, se copiarán los siguientes archivos en el host:

n /opt/cni/bin/nsx

n /etc/cni/net.d/99-loopback.conf

n /etc/cni/net.d/10-nsx.conf

n /etc/apparmor.d/ncp-apparmor

Si los archivos /opt/cni/bin/loopback y /etc/cni/net.d/99-loopback.conf existen, no se sobrescribirán. Si el tipo de sistema operativo es Ubuntu, el archivo ncp-apparmor también se copiará en el host.

El contenedor de arranque moverá la dirección IP y las rutas de br-int a node-if. También se detendrá OVS si se está ejecutando en el host, ya que OVS se ejecutará dentro del contenedor nsx-ovs. El contenedor nsx-ovs creará la instancia de br-int si no existe, agregará la interfaz de red (node-if) que está conectada a través del conmutador lógico del nodo a br-int y se asegurará de que los vínculos br-int y node-if estén activos. Moverá la dirección IP y las rutas de node-if a br-int.

Nota Si se elimina el DaemonSet nsx-node-agent, OVS no podrá ejecutarse en el host (ni en el contenedor ni en el PID del host).

Actualice la configuración de red para que la dirección IP y las rutas sean persistentes. Por ejemplo, para Ubuntu, edite /etc/network/interfaces (utilice los valores reales del entorno donde corresponda) para que la dirección IP y las rutas sean persistentes:

auto eth1

iface eth1 inet static

address 172.16.1.4/24

#persistent static routes

up route add -net 172.16.1.3/24 gw 172.16.1.1 dev eth1

A continuación, ejecute el comando ifdown eth1; ifup eth1.


VMware, Inc. 24

Para RHEL, cree y edite /etc/sysconfig/network-scripts/ifcfg-<node-if> (utilice los valores reales del entorno donde corresponda) para que la dirección IP sea persistente:

HWADDR=00:0C:29:B7:DC:6F

TYPE=Ethernet

PROXY_METHOD=none

BROWSER_ONLY=no

BOOTPROTO=none

IPADDR=172.10.0.2

PREFIX=24

DEFROUTE=yes

IPV4_FAILURE_FATAL=no

IPV4_DNS_PRIORITY=100

IPV6INIT=no

NAME=eth1

UUID=39317e23-909b-45fc-9951-849ece53cb83

DEVICE=eth1

ONBOOT=yes

A continuación, ejecute el comando systemctl restart network.service.

Para obtener más información sobre cómo configurar rutas persistentes para RHEL, consulte https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_files.

Nota Las rutas de direcciones IP y estáticas deben persistir en la interfaz de enlace ascendente (especificada por ovs_uplink_port) para garantizar que no se pierda la conectividad con el servidor de la API de Kubernetes después de reiniciar la máquina virtual.

Si es necesario, puede deshacer los cambios que realice el contenedor de arranque. Para obtener más información, consulte Limpiar los nodos de Kubernetes.

Crear secretos: Kubernetes

Puede crear secretos para almacenar la clave y el certificado del equilibrador de carga o del cliente de NSX.

La forma más sencilla de crear un secreto es con el comando kubectl:

kubectl create ns nsx-system

kubectl create secret tls ${CERT_NAME} --key ${KEY_FILE} --cert ${CERT_FILE} -n nsx-system

También puede crear secretos con el archivo YAML de NCP quitando la marca de comentario de las secciones Secreto de ejemplo del archivo y rellenando los valores codificados con base64 del certificado y la clave. Utilice los siguientes comandos para obtener la cadena codificada con base64 del archivo de clave o del certificado:

cat cert_file.crt | base64 -w 0

cat key_file.crt | base64 -w 0


VMware, Inc. 25

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_files

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_files

Configurar las redes de NSX-T Data Center para los nodos de Kubernetes

En esta sección se describe cómo configurar las redes de NSX-T Data Center para los nodos principales o de trabajo de Kubernetes.

Cada nodo debe tener al menos dos interfaces de red. La primera es una interfaz de administración que puede que esté o no en el tejido de NSX-T Data Center. Las otras interfaces proporcionan redes para los pods, se encuentran en el tejido de NSX-T Data Center y están conectadas a un conmutador lógico, que se conoce como el conmutador lógico del nodo. Las direcciones IP del pod y de administración se deben poder enrutar para que la comprobación de estado de Kubernetes funcione. En cuanto a la comunicación entre la interfaz de administración y los pods, NCP crea automáticamente una regla DFW para permitir la comprobación de estado y otro tráfico de administración. Puede ver la información de esta regla en la GUI de NSX Manager. Esta regla no se debe cambiar ni eliminar.

En cada máquina virtual del nodo, asegúrese de que la vNIC que se designó como red del contenedor esté asociada al conmutador lógico del nodo.

NSX Container Plug-in (NCP) debe conocer el ID de VIF de la vNIC usada como tráfico del contenedor en cada nodo. El puerto de conmutador lógico debe tener las dos siguientes etiquetas: En una etiqueta, especifique el nombre del nodo. En la otra etiqueta, especifique el nombre del clúster. Para especificar el ámbito, utilice los valores adecuados que se indican a continuación.

Etiqueta Ámbito



Puede identificar el puerto de conmutador lógico para una máquina virtual del nodo si accede a Inventario > Máquinas virtuales desde la GUI de NSX Manager.

Si el nombre del nodo de Kubernetes cambia, debe actualizar la etiqueta ncp/node_name y reiniciar NCP. Puede usar el siguiente comando para obtener los nombres del nodo:

kubectl get nodes

Si agrega un nodo a un clúster mientras NCP se está ejecutando, debe agregar las etiquetas al puerto de conmutador lógico antes de ejecutar el comando kubeadm join. De lo contrario, el nuevo nodo no tendrá conectividad a la red. Si faltan etiquetas o no son correctas, puede seguir estos pasos para resolver el problema:

n Aplique las etiquetas correctas al puerto de conmutador lógico.

n Reinicie NCP.


VMware, Inc. 26

Editar el archivo YAML de NCP

El archivo YAML de NCP contiene información para configurar, instalar y ejecutar todos los componentes de NCP.

El archivo YAML de NCP contiene la siguiente información:

n Definiciones de RBAC.

n Varias CRD (CustomResourceDefinitions).

n ConfigMap con ncp.ini dedicado a NCP. Algunas opciones de configuración recomendadas ya están configuradas.

n Implementación de NCP.

n ConfigMap con ncp.ini dedicado a nsx-node-agent. Algunas opciones de configuración recomendadas ya están configuradas.

n DaemonSet nsx-node-agent, incluidos nsx-node-agent, nsx-kube-proxy y nsx-ovs.

n DaemonSet nsx-ncp-bootstrap

Los módulos de kernel OpenvSwitch y CNI de NSX se instalan automáticamente mediante initContainers nsx-ncp-bootstrap. Los demonios de espacio de usuario OpenvSwitch se ejecutan en el contenedor de nsx-ovs en cada nodo.

Actualizar las especificaciones de implementación de NCP

Busque el ConfigMap con el nombre nsx-ncp-config. Para obtener la lista completa de las opciones de ConfigMap, consulte ConfigMap nsx-ncp-config. Algunas opciones ya están configuradas con los valores recomendados. Puede personalizar todas las opciones de su entorno. Por ejemplo,

n Nivel de registro y directorio de registro.

n IP de servidor de API de Kubernetes, ruta de certificado y ruta de acceso de token de cliente. De forma predeterminada, se utiliza el servidor de API ClusterIP de la variable de entorno, y el certificado y el token se montan automáticamente desde ServiceAccount. Por lo general, no es necesario realizar ningún cambio.

n Nombre del clúster de Kubernetes.

n IP y credenciales de NSX Manager.

n Opciones de recursos de NSX, como overlay_tz, top_tier_router, container_ip_blocks, external_ip_blocks, etc.


VMware, Inc. 27

De forma predeterminada, se usan la VIP y el puerto del servicio de Kubernetes, el token ServiceAccount y ca_file para el acceso a la API de Kubernetes. No se requiere ningún cambio aquí, pero se deben rellenar algunas opciones de NSX API de ncp.ini.

n Especifique la opción nsx_api_managers. Puede ser una lista separada por comas de especificaciones de URO o direcciones IP de NSX Manager que cumplan con RFC3896. Por ejemplo,

nsx_api_managers = 192.168.1.181, 192.168.1.182, 192.168.1.183

n Especifique las opciones nsx_api_user y nsx_api_password con el nombre de usuario y la contraseña, respectivamente, si configura NCP para que se conecte a NSX-T mediante la autenticación básica. Este método de autenticación no se recomienda porque es menos seguro. Estas opciones se ignoran si NCP está configurado para autenticarse con certificados de cliente. Estas opciones no aparecen en el archivo YAML de NCP. Debe agregarlos manualmente.

n Especifique las opciones nsx_api_cert_file y nsx_api_private_key_file para la autenticación con NSX-T. La opción nsx_api_cert_file es la ruta completa a un archivo de certificado cliente en formato PEM. El contenido de este archivo debe ser similar al siguiente:

-----BEGIN CERTIFICATE-----

<certificate_data_base64_encoded>

-----END CERTIFICATE-----

La opción nsx_api_private_key_file es la ruta completa a un archivo de clave privada cliente en formato PEM. El contenido de este archivo debe ser similar al siguiente:

-----BEGIN PRIVATE KEY-----

<private_key_data_base64_encoded>

-----END PRIVATE KEY-----

Mediante el uso de la autenticación de certificados de cliente, NCP puede utilizar su identidad principal para crear objetos de NSX-T. Esto significa que solo una identidad con el mismo nombre podrá modificar o eliminar los objetos. Evita que los objetos de NSX-T creados por NCP se modifiquen o se eliminen por error. Tenga en cuenta que un administrador puede modificar o eliminar cualquier objeto. Si el objeto se crea con el nombre de una identidad principal, aparecerá una advertencia que lo indique.

n (Opcional) Especifique la opción ca_file. El valor debe ser un archivo de paquete de CA que se usa para verificar el certificado del servidor de NSX Manager. Si no se establece, se usarán las CA raíz del sistema. Si especifica una dirección IP para nsx_api_managers, especifique un


VMware, Inc. 28

archivo de CA. Si especifica tres direcciones IP para nsx_api_managers, puede especificar uno o tres archivos de CA. Si especifica un archivo de CA, se utilizará para los tres administradores. Si especifica tres archivos de CA, cada uno se utilizará para la dirección IP correspondiente en nsx_api_managers. Por ejemplo,

nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183

ca_file = ca_file_for_all_mgrs

or

nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183

ca_file = ca_file_for_mgr1,ca_file_for_mgr2,ca_file_for_mgr3

n (Opcional) Especifique la opción insecure. Si se establece en el valor True, no se verificará el certificado del servidor de NSX Manager. El valor predeterminado es False.

Si desea utilizar un secreto Kubernetes para almacenar el certificado de NSX Client y el certificado predeterminado del equilibrador de carga, primero debe crear secretos mediante un comando kubectl y, a continuación, actualizar la especificación de implementación:

n Agregue volúmenes secretos a la especificación de pod de NCP o quite la marca de comentario de los volúmenes secretos de ejemplo.

n Agregue montajes de volúmenes a la especificación de contenedor de NCP o quite la marca de comentario de los montajes de volumen de ejemplo.

n Actualice ncp.ini en ConfigMap para establecer la ruta del archivo de certificado que apunta al archivo en el volumen montado.

Si no tiene una topología de nivel 1 compartida, debe establecer la opción edge_cluster en el identificador del clúster de Edge para que NCP cree una puerta de enlace o un enrutador de nivel 1 para el servicio de equilibrador de carga. Para encontrar el identificador de clúster de Edge, vaya a Sistema > Tejido > Nodos, seleccione la pestaña Clústeres de Edge y haga clic en el nombre del clúster de Edge.

HA (alta disponibilidad) está habilitada de forma predeterminada. En un entorno de producción, se recomienda no deshabilitar HA.

Nota: De forma predeterminada, kube-scheduler no programará pods en el nodo principal. En el archivo YAML de NCP, se agrega una tolerancia para permitir que el pod de NCP se ejecute en el nodo principal.

Configurar SNAT

De forma predeterminada, NCP configura SNAT para cada proyecto. No se configurará SNAT para los espacios de nombres con la siguiente anotación:

ncp/no_snat: True


VMware, Inc. 29

Si no desea que SNAT sea un espacio de nombres en el clúster, configure la siguiente opción en ncp.ini:

[coe]

enable_snat = False

Nota: No se puede actualizar una anotación SNAT de espacio de nombres existente. Si realiza una acción de este tipo, la topología del espacio de nombres entrará en un estado incoherente porque es posible que quede una regla SNAT obsoleta. Para solucionar un estado incoherente, debe volver a crear el espacio de nombres.

(Solo en modo Directiva) Si SNAT está configurado para un clúster, BGP está habilitado en el enrutador de nivel 0 y Connected Interfaces & Segments está seleccionado en Advertised tier-1 subnets cuando se configura la redistribución de rutas en el enrutador de nivel 0, se puede utilizar la siguiente opción para controlar la redistribución de rutas:

[nsx_v3]

configure_t0_redistribution = True

Si configure_t0_redistribution se configura como True, NCP agregará una entrada de mapa de rutas deny en la regla de redistribución para evitar que el enrutador de nivel 0 anuncie las subredes internas del clúster a los vecinos BGP. Se utiliza principalmente para clústeres de vSphere with Kubernetes. Si no crea un mapa de rutas para la regla de redistribución, NCP creará un mapa de rutas utilizando su identidad principal y lo aplicará a la regla. Si desea modificar este mapa de rutas, deberá reemplazarlo con un nuevo mapa de rutas, copiar las entradas del mapa de rutas creado por NCP y agregar nuevas entradas. Debe administrar cualquier posible conflicto entre las nuevas entradas y las entradas creadas por NCP. Si solo se anula la asignación de un mapa de rutas creado por NCP sin crear uno nuevo para la regla de redistribución, NCP volverá a aplicar el mapa de rutas existente a la regla de redistribución cuando se reinicie NCP.

Actualizar las especificaciones del DaemonSet nsx-node-agent

Busque el ConfigMap con el nombre nsx-node-agent-config. Para obtener la lista completa de las opciones de ConfigMap, consulte ConfigMap nsx-node-agent-config. Algunas opciones ya están configuradas con los valores recomendados. Puede personalizar todas las opciones de su entorno. Por ejemplo,

n Nivel de registro y directorio de registro.

n IP de servidor de API de Kubernetes, ruta de certificado y ruta de acceso de token de cliente. De forma predeterminada, se utiliza el servidor de API ClusterIP de la variable de entorno, y el certificado y el token se montan automáticamente desde ServiceAccount. Por lo general, no es necesario realizar ningún cambio.

n Puerto de vínculo superior de OpenvSwitch. Por ejemplo: ovs_uplink_port=eth1


VMware, Inc. 30

El DaemonSet nsx-ncp-bootstrap instala los módulos de kernel de CNI y OVS en el nodo. A continuación, se cierran los demonios de OVS en el nodo, para que el contenedor nsx-ovs posterior pueda ejecutar demonios de OVS dentro de un contenedor del docker. Si CNI no está instalado, todos los nodos de Kubernetes tienen el estado "No listo". Se tolera en el DaemonSet de arranque para permitir que se ejecute en nodos con el estado "No listo". Después de instalar el complemento CNI, los nodos deben tener el estado "Listo".

Si no utiliza el módulo kernel de NSX OVS, debe actualizar el parámetro de volumen host-original-ovs-db con la ruta correcta en la que se haya configurado la base de datos de OpenvSwitch durante la compilación del módulo kernel de OVS. Por ejemplo, si especifica --sysconfdir=/var/lib, establezca host-original-ovs-db como /var/lib/openvswitch.

Si utiliza el módulo kernel de NSX OVS, debe establecer use_nsx_ovs_kernel_module = True y quitar la marca de comentario de las líneas sobre los volúmenes que se van a montar:

# Uncomment these mounts if installing NSX-OVS kernel module

# # mount host lib modules to install OVS kernel module if needed

# - name: host-modules

# mountPath: /lib/modules

# # mount openvswitch database

# - name: host-config-openvswitch

# mountPath: /etc/openvswitch

# - name: dir-tmp-usr-ovs-kmod-backup

# # we move the usr kmod files to this dir temporarily before

# # installing new OVS kmod and/or backing up existing OVS kmod backup

# mountPath: /tmp/nsx_usr_ovs_kmod_backup

# # mount linux headers for compiling OVS kmod

# - name: host-usr-src

# mountPath: /usr/src

...

# Uncomment these volumes if installing NSX-OVS kernel module

# - name: host-modules

# hostPath:

# path: /lib/modules

# - name: host-config-openvswitch

# hostPath:

# path: /etc/openvswitch

# - name: dir-tmp-usr-ovs-kmod-backup

# hostPath:

# path: /tmp/nsx_usr_ovs_kmod_backup

# - name: host-usr-src

# hostPath:

# path: /usr/src

El agente del nodo de NSX es un DaemonSet en el que cada pod ejecuta 3 contenedores:

n nsx-node-agent administra las interfaces de red de contenedor. Interactúa con el complemento CNI y el servidor de la API de Kubernetes.


VMware, Inc. 31

n nsx-kube-proxy implementa la abstracción del servicio de Kubernetes traduciendo las direcciones IP del clúster a las IP de pods. Implementa la misma funcionalidad que el de la secuencia ascendente kube-proxy, pero no es mutuamente exclusiva.

n nsx-ovs ejecuta los demonios del espacio de usuario de OpenvSwitch. También creará automáticamente el puente de OVS y moverá la dirección IP y las rutas de datos de node-if a br-int. Debe agregar ovs_uplink_port=ethX en ncp.ini para que pueda usar ethX como el vínculo superior de puente de OVS.

Si los nodos de trabajado usan Ubuntu, ncp-ubuntu.yaml asume que el módulo de kernel AppArmor está habilitado; de lo contrario, Kubelet no ejecutará el DaemonSet nsx-node-agent, ya que está configurado con la opción AppArmor. Para Ubuntu y SUSE, está habilitado de forma predeterminada. Para comprobar si el módulo está habilitado, compruebe el archivo /sys/module/apparmor/parameters/enabled.

Si AppArmor se deshabilita de forma intencionada, se deberán aplicar los siguientes cambios al archivo YAML:

n Elimine la opción AppArmor:

annotations:

# The following line needs to be removed

container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-apparmor

n Habilite el modo privilegiado para los contenedores nsx-node-agent y nsx-kube-proxy

securityContext:

# The following line needs to be appended

privileged: true

Nota: Si se ejecuta kubelet en un contenedor que usa la imagen hyperkube, kubelet siempre notifica que AppArmor está deshabilitado, independientemente del estado real. Se deben realizar los mismos cambios anteriores y aplicarlos al archivo YAML.

Actualizar el nombre del espacio de nombres

En el archivo YAML, todos los objetos con espacio de nombres, como ServiceAccount, ConfigMap, Deployment, se crean en el espacio de nombres nsx-system. Si utiliza un espacio de nombres diferente, reemplace todas las instancias de nsx-system.

ConfigMap nsx-ncp-config

El archivo YAML de NCP incluye el ConfigMap nsx-ncp-config. Puede actualizar las opciones del entorno. A continuación se muestra nsx-ncp-config ConfigMap de ncp-ubuntu-policy.yaml para NCP 3.0.2.

# ConfigMap for ncp.ini

apiVersion: v1

kind: ConfigMap

metadata:


VMware, Inc. 32

name: nsx-ncp-config

namespace: nsx-system

labels:

version: v1

data:

ncp.ini: |

[vc]

# IpAddress or Hostname of VC

#vc_endpoint = <None>

# The SSO domain associated with the deployment

#sso_domain = vsphere.local

# VC API server HTTPS port.

#https_port = 443

[coe]

# Container orchestrator adaptor to plug in.

#adaptor = kubernetes

# Specify cluster for adaptor.

#cluster = k8scluster

# Log level for NCP operations

# Choices: NOTSET DEBUG INFO WARNING ERROR CRITICAL

#loglevel = <None>

# Log level for NSX API client operations


#nsxlib_loglevel = <None>

# Enable SNAT for all projects in this cluster. Modification of topologies

# for existing Namespaces is not supported if this option is reset.

#enable_snat = True

# Option to enable profiling

#profiling = False

# The interval of reporting performance metrics (0 means disabled)

#metrics_interval = 0

# Name of log file for outputting metrics only (if not defined, use default

# logging facility)

#metrics_log_file = <None>

# The type of container host node

# Choices: HOSTVM BAREMETAL CLOUD WCP_WORKER

#node_type = HOSTVM

# The time in seconds for NCP/nsx_node_agent to recover the connection to

# NSX manager/container orchestrator adaptor/Hyperbus before exiting. If

# the value is 0, NCP/nsx_node_agent won't exit automatically when the


VMware, Inc. 33

# connection check fails

#connect_retry_timeout = 0

# Enable system health status report for SHA

#enable_sha = True

[DEFAULT]

# If set to true, the logging level will be set to DEBUG instead of the

# default INFO level.

#debug = False

# If set to true, log output to standard error.

#use_stderr = True

# If set to true, use syslog for logging.

#use_syslog = False

# The base directory used for relative log_file paths.

#log_dir = <None>

# Name of log file to send logging output to.

#log_file = <None>

# max MB for each compressed file. Defaults to 100 MB.

#log_rotation_file_max_mb = 100

# Total number of compressed backup files to store. Defaults to 5.

#log_rotation_backup_count = 5

[nsx_v3]

# Set NSX API adaptor to NSX Policy API adaptor. If unset, NSX adaptor will

# be set to the NSX Manager based adaptor. If unset or False, the NSX

# resource ID in other options can be resource name or UUID

#policy_nsxapi = False

# Path to NSX client certificate file. If specified, the nsx_api_user and

# nsx_api_password options will be ignored. Must be specified along with

# nsx_api_private_key_file option

#nsx_api_cert_file = <None>

# Path to NSX client private key file. If specified, the nsx_api_user and

# nsx_api_password options will be ignored. Must be specified along with

# nsx_api_cert_file option

#nsx_api_private_key_file = <None>

# IP address of one or more NSX managers separated by commas. The IP

# address should be of the form:

# [<scheme>://]<ip_adress>[:<port>]

# If scheme is not provided https is used. If port is not provided port 80

# is used for http and port 443 for https.

#nsx_api_managers = []


VMware, Inc. 34

# If True, skip fatal errors when no endpoint in the NSX management cluster

# is available to serve a request, and retry the request instead

#cluster_unavailable_retry = False

# Maximum number of times to retry API requests upon stale revision errors.

#retries = 10

# Specify one or a list of CA bundle files to use in verifying the NSX

# Manager server certificate. This option is ignored if "insecure" is set

# to True. If "insecure" is set to False and "ca_file" is unset, the

# "thumbprint" will be used. If "thumbprint" is unset, the system root CAs

# will be used to verify the server certificate.

#ca_file = []

# Specify one or a list of thumbprint strings to use in verifying the NSX

# Manager server certificate. This option is ignored if "insecure" is set

# to True or "ca_file" is defined.

#thumbprint = []

# If true, the NSX Manager server certificate is not verified. If false the

# CA bundle specified via "ca_file" will be used or if unset the

# "thumbprint" will be used. If "thumbprint" is unset, the default system

# root CAs will be used.

#insecure = False

# The time in seconds before terminating a HTTP connection to a NSX manager.

#http_timeout = 10

# The time in seconds before terminating a HTTP read response from a NSX

# manager.

#http_read_timeout = 180

# Maximum number of times to retry a HTTP connection.

#http_retries = 3

# Maximum concurrent connections to all NSX managers. If multiple NSX

# managers are configured, connections will be spread evenly across all

# managers, rounded down to the nearest integer. Each NSX manager will have

# at least 1 connection. This value should be a multiple of

# [nsx_v3]nsx_api_managers length.

#concurrent_connections = 10

# The amount of time in seconds to wait before ensuring connectivity to the

# NSX manager if no manager connection has been used.

#conn_idle_timeout = 10

# Number of times a HTTP redirect should be followed.

#redirects = 2

# Subnet prefix of IP block.

#subnet_prefix = 24

# Subnet prefix for v6 IP blocks

#v6_subnet_prefix = 64


VMware, Inc. 35

# Indicates whether distributed firewall DENY rules are logged.

#log_dropped_traffic = False

# Indicates whether distributed firewall rules are logged. Option 'ALL'

# will enable logging for all DFW rules (both DENY and ALLOW), and option

# 'DENY' will enable logging only for DENY rules. Remove this config if no

# logging is desired

# Choices: ALL DENY <None>

#log_firewall_traffic = <None>

# Option to use native load balancer or not

#use_native_loadbalancer = True

# Option to auto scale layer 4 load balancer or not. If set to True, NCP

# will create additional LB when necessary upon K8s Service of type LB

# creation/update.

#l4_lb_auto_scaling = True

# Option to use native load balancer or not when ingress class annotation

# is missing. Only effective if use_native_loadbalancer is set to true

#default_ingress_class_nsx = True

# Path to the default certificate file for HTTPS load balancing. Must be

# specified along with lb_priv_key_path option

#lb_default_cert_path = <None>

# Path to the private key file for default certificate for HTTPS load

# balancing. Must be specified along with lb_default_cert_path option

#lb_priv_key_path = <None>

# Option to set load balancing algorithm in load balancer pool object.

# Choices: ROUND_ROBIN LEAST_CONNECTION IP_HASH WEIGHTED_ROUND_ROBIN

#pool_algorithm = ROUND_ROBIN

# Option to set load balancer service size. MEDIUM Edge VM (4 vCPU, 8GB)

# only supports SMALL LB. LARGE Edge VM (8 vCPU, 16GB) only supports MEDIUM

# and SMALL LB. Bare Metal Edge (IvyBridge, 2 socket, 128GB) supports

# LARGE, MEDIUM and SMALL LB

# Choices: SMALL MEDIUM LARGE

#service_size = SMALL

# Option to set load balancer persistence option. If cookie is selected,

# cookie persistence will be offered.If source_ip is selected, source IP

# persistence will be offered for ingress traffic through L7 load balancer

# Choices: <None> cookie source_ip

#l7_persistence = <None>

# An integer for LoadBalancer side timeout value in seconds on layer 7

# persistence profile, if the profile exists.

#l7_persistence_timeout = 10800

# Option to set load balancer persistence option. If source_ip is selected,

# source IP persistence will be offered for ingress traffic through L4 load

# balancer


VMware, Inc. 36

# Choices: <None> source_ip

#l4_persistence = <None>

# Option to set distributed load balancer source ip persistence option,

# only available when use_native_dlb = True

# Choices: <None> source_ip

#dlb_l4_persistence = <None>

# Resource ID of the container ip blocks that will be used for creating

# subnets. If name, it must be unique. If policy_nsxapi is enabled, it also

# support automatically creating the IP blocks. The definition is a comma

# separated list: CIDR,CIDR,... Mixing different formats (e.g. UUID,CIDR)

# is not supported.

#container_ip_blocks = []

# Resource ID of the container ip blocks that will be used for creating

# subnets for no-SNAT projects. If specified, no-SNAT projects will use

# these ip blocks ONLY. Otherwise they will use container_ip_blocks

#no_snat_ip_blocks = []

# Resource ID of the external ip pools that will be used for allocating IP

# addresses which will be used for translating container IPs via SNAT

# rules. If policy_nsxapi is enabled, it also support automatically

# creating the ip pools. The definition is a comma separated list:

# CIDR,IP_1-IP_2,... Mixing different formats (e.g. UUID, CIDR&IP_Range) is

# not supported.

#external_ip_pools = []

# Resource ID of the top-tier router for the container cluster network,

# which could be either tier0 or tier1. If policy_nsxapi is enabled, should

# be ID of a tier0/tier1 gateway.

#top_tier_router = <None>

# Option to use single-tier router for the container cluster network

#single_tier_topology = False

# Resource ID of the external ip pools that will be used only for

# allocating IP addresses for Ingress controller and LB service. If

# policy_nsxapi is enabled, it also supports automatically creating the ip

# pools. The definition is a comma separated list: CIDR,IP_1-IP_2,...

# Mixing different formats (e.g. UUID, CIDR&IP_Range) is not supported.

#external_ip_pools_lb = []

# Resource ID of the NSX overlay transport zone that will be used for

# creating logical switches for container networking. It must refer to an

# already existing resource on NSX and every transport node where VMs

# hosting containers are deployed must be enabled on this transport zone

#overlay_tz = <None>

# Name of the enforcement point used to look up overlay transport zones and

# edge cluster paths, e.g. vmc-enforcementpoint, default, etc.

#enforcement_point = <None>

# Resource ID of the lb service that can be attached by virtual servers

#lb_service = <None>


VMware, Inc. 37

# Resource ID of the IPSet containing the IPs of all the virtual servers

#lb_vs_ip_set = <None>

# Enable X_forward_for for ingress. Available values are INSERT or REPLACE.

# When this config is set, if x_forwarded_for is missing, LB will add

# x_forwarded_for in the request header with value client ip. When

# x_forwarded_for is present and its set to REPLACE, LB will replace

# x_forwarded_for in the header to client_ip. When x_forwarded_for is

# present and its set to INSERT, LB will append client_ip to

# x_forwarded_for in the header. If not wanting to use x_forwarded_for,

# remove this config

# Choices: <None> INSERT REPLACE

#x_forwarded_for = <None>

# Resource ID of the firewall section that will be used to create firewall

# sections below this mark section

#top_firewall_section_marker = <None>

# Resource ID of the firewall section that will be used to create firewall

# sections above this mark section

#bottom_firewall_section_marker = <None>

# Replication mode of container logical switch, set SOURCE for cloud as it

# only supports head replication mode

# Choices: MTEP SOURCE

#ls_replication_mode = MTEP

# The resource which NCP will search tag 'node_name' on, to get parent VIF

# or transport node uuid for container LSP API context field. For HOSTVM

# mode, it will search tag on LSP. For BM mode, it will search tag on LSP

# then search TN. For CLOUD mode, it will search tag on VM. For WCP_WORKER

# mode, it will search TN by hostname.

# Choices: tag_on_lsp tag_on_tn tag_on_vm hostname_on_tn

#search_node_tag_on = tag_on_lsp

# Determines which kind of information to be used as VIF app_id. Defaults

# to pod_resource_key. In WCP mode, pod_uid is used.

# Choices: pod_resource_key pod_uid

#vif_app_id_type = pod_resource_key

# If this value is not empty, NCP will append it to nameserver list

#dns_servers = []

# Set this to True to enable NCP to report errors through NSXError CRD.

#enable_nsx_err_crd = False

# Maximum number of virtual servers allowed to create in cluster for

# LoadBalancer type of services.

#max_allowed_virtual_servers = 9223372036854775807

# Edge cluster ID needed when creating Tier1 router for loadbalancer

# service. Information could be retrieved from Tier0 router


VMware, Inc. 38

#edge_cluster = <None>

# Inventory feature switch

#enable_inventory = True

# For internal container network CIDR, NCP adds redistribution deny rule to

# stop T0 router advertise subnets to external network outside of T0

# router. If BGP or route redistribution is disabled, or

# T1_CONNECTED/TIER1_SEGMENT option is not selected, NCP would not add the

# deny rule. If users enable BGP and route redistribution, or select

# T1_CONNECTED/TIER1_SEGMENT option after NCP starts, user needs to restart

# NCP to let NCP set deny rule. If there is already a route map attached,

# NCP will create IP prefix list on the existing route map. Otherwise NCP

# will create a new route map and attach it. This option could be used only

# in SNAT mode and when policy_nsxapi = True.

#configure_t0_redistribution = False

# Health check interval for nsx lb monitor profile

#lb_hc_profile_interval = 5

# Health check timeout for nsx lb monitor profile

#lb_hc_profile_timeout = 15

# Health check failed count for nsx lb monitor profile. Pool member failed

# for this amount will be marked as down.

#lb_hc_profile_fall_count = 3

# Health check rise count for nsx lb monitor profile. Pool members

# previously marked down will be brought up, if succeed in the health check

# for this amount fo time.

#lb_hc_profile_rise_count = 3

# Maximum size of the buffer used to store HTTP request headers for L7

# virtual servers in cluster. A request with header larger than this value

# will be processed as best effort whereas a request with header below this

# value is guaranteed to be processed.

#lb_http_request_header_size = 1024

# Maximum size of the buffer used to store HTTP response headers for all L7

# virtual servers in cluster. A response with header larger than this value

# will be dropped.

#lb_http_response_header_size = 4096

# Maximum server idle time in seconds for L7 virtual servers in cluster. If

# backend server does not send any packet within this time, the connection

# is closed.

#lb_http_response_timeout = 60

# Determines the behavior when a Tier-1 instance restarts after a failure.

# If set to PREEMPTIVE, the preferred node will take over, even if it

# causes another failure. If set to NON_PREEMPTIVE, then the instance that

# restarted will remain secondary. Applicable to Tier-1 across cluster that

# was created by NCP and has edge cluster configured.

# Choices: PREEMPTIVE NON_PREEMPTIVE


VMware, Inc. 39

#failover_mode = NON_PREEMPTIVE

# Set this to ENABLE to enable NCP enforced pool member limit for all load

# balancer servers in cluster. Set this to CRD_LB_ONLY will only enforce

# the limit for load balancer servers created using lb CRD. Set this to

# DISABLE to turn off all limit checks. This option requires

# relax_scale_validation set to True, l4_lb_auto_scaling set to False, and

# works on Policy API only. When not disabled, NCP will enforce a pool

# member limit on LBS to prevent one LBS from using up all resources on

# edge nodes.

# Choices: DISABLE ENABLE CRD_LB_ONLY

#ncp_enforced_pool_member_limit = DISABLE

# Maximum number of pool member allowed for each small load balancer

# service. Requires ncp_enforced_pool_member_limit set to ENABLE or

# CRD_LB_ONLY to take effect.

#members_per_small_lbs = 2000

# Maximum number of pool member allowed for each medium load balancer

# service. Requires ncp_enforced_pool_member_limit set to ENABLE or

# CRD_LB_ONLY to take effect.

#members_per_medium_lbs = 2000

# Interval in seconds to clean empty segments.

#segment_gc_interval = 600

# Determines the mode NCP limits rate when sending API calls to NSX.

# Choices: NO_LIMIT SLIDING_WINDOW ADAPTIVE_AIMD

#api_rate_limit_mode = ADAPTIVE_AIMD

# When nsx_v3.api_rate_limit_mode is not set to NO_LIMIT, determines the

# maximum number of API calls sent per manager ip per second. Should be a

# positive integer.

#max_api_rate = 40

# Resource ID of the client SSL profile which will be used by Loadbalancer

# while participating in TLS handshake with the client

#client_ssl_profile = <None>

[ha]

# Time duration in seconds of mastership timeout. NCP instance will remain

# master for this duration after elected. Note that the heartbeat period

# plus the update timeout must not be greater than this period. This is

# done to ensure that the master instance will either confirm liveness or

# fail before the timeout.

#master_timeout = 18

# Time in seconds between heartbeats for elected leader. Once an NCP

# instance is elected master, it will periodically confirm liveness based

# on this value.

#heartbeat_period = 6

# Timeout duration in seconds for update to election resource. The default

# value is calculated by subtracting heartbeat period from master timeout.


VMware, Inc. 40

# If the update request does not complete before the timeout it will be

# terminated. Used for master heartbeats to ensure that the update finishes or

# is terminated before the master timeout occurs.

#update_timeout = <None>

[k8s]

# Kubernetes API server IP address.

#apiserver_host_ip = <None>

# Kubernetes API server port.

#apiserver_host_port = <None>

# Full path of the Token file to use for authenticating with the k8s API

# server.

client_token_file = /var/run/secrets/kubernetes.io/serviceaccount/token

# Full path of the client certificate file to use for authenticating with

# the k8s API server. It must be specified together with

# "client_private_key_file".

#client_cert_file = <None>

# Full path of the client private key file to use for authenticating with


# "client_cert_file".

#client_private_key_file = <None>

# Specify a CA bundle file to use in verifying the k8s API server

# certificate.

ca_file = /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

# Specify whether ingress controllers are expected to be deployed in

# hostnework mode or as regular pods externally accessed via NAT

# Choices: hostnetwork nat

#ingress_mode = hostnetwork

# Log level for the kubernetes adaptor


#loglevel = <None>

# The default HTTP ingress port

#http_ingress_port = 80

# The default HTTPS ingress port

#https_ingress_port = 443

# Specify thread pool size to process resource events

#resource_watcher_thread_pool_size = 1

# User specified IP address for HTTP and HTTPS ingresses

#http_and_https_ingress_ip = <None>

# Set this to True to enable NCP to create tier1 router, first segment and

# default SNAT IP for VirtualNetwork CRD, and then create segment port for

# VM through VirtualNetworkInterface CRD.


VMware, Inc. 41

#enable_vnet_crd = False

# Set this to True to enable NCP to create LoadBalancer on a Tier-1 for

# LoadBalancer CRD. This option does not support LB autoscaling.

#enable_lb_crd = False

# Option to set the type of baseline cluster policy. ALLOW_CLUSTER creates

# an explicit baseline policy to allow any pod to communicate any other pod

# within the cluster. ALLOW_NAMESPACE creates an explicit baseline policy

# to allow pods within the same namespace to communicate with each other.

# By default, no baseline rule will be created and the cluster will assume

# the default behavior as specified by the backend. Modification is not

# supported after the value is set.

# Choices: <None> allow_cluster allow_namespace

#baseline_policy_type = <None>

# Maximum number of endpoints allowed to create for a service.

#max_allowed_endpoints = 1000

# Set this to True to enable NCP reporting NSX backend error to k8s object

# using k8s event

#enable_ncp_event = False

# Set this to True to enable multus to create multiple interfaces for one

# pod. If passthrough interface is usedas additional interface, user should

# deploy device plugin to provide device allocation information for NCP.Pod

# annotations under prefix "k8s.v1.cni.cncf.io" cannot be modified after

# pod realized. User defined IP will not be allocated from Segment IPPool.

# "gateway" in NetworkAttachmentDefinition is not used to configure

# secondary interfaces. Default gateway of pod is configured by primary

# interface. User must define IP and/or MAC if no "ipam" is configured.Only

# available if node type is HOSTVM

#enable_multus = True

# Interval of polling loadbalancer statistics. Default to60 seconds.

#lb_statistic_monitor_interval = 60

# This option is for toggling process of network CRD.It should be set to

# False when the network status setting is done by OCP4 NetworkOperator

#process_oc_network = True

#[nsx_v3]

# Deprecated option: tier0_router

# Replaced by [nsx_v3] top_tier_router

# Deprecated option: deny_subnets_redistribution

# Replaced by [nsx_v3] configure_t0_redistribution


VMware, Inc. 42

ConfigMap nsx-node-agent-config

El archivo YAML de NCP incluye el ConfigMap nsx-node-agent-config. Puede actualizar las opciones del entorno. A continuación se muestra nsx-node-agent-config ConfigMap de ncp-ubuntu-policy.yaml para NCP 3.0.2.

kind: ConfigMap

metadata:

name: nsx-node-agent-config

namespace: nsx-system

labels:

version: v1

data:

ncp.ini: |

[DEFAULT]

# If set to true, the logging level will be set to DEBUG instead of the

# default INFO level.

#debug = False

# If set to true, log output to standard error.

#use_stderr = True

# If set to true, use syslog for logging.

#use_syslog = False

# The base directory used for relative log_file paths.

#log_dir = <None>

# Name of log file to send logging output to.

#log_file = <None>

# max MB for each compressed file. Defaults to 100 MB.

#log_rotation_file_max_mb = 100

# Total number of compressed backup files to store. Defaults to 5.

#log_rotation_backup_count = 5

[k8s]

# Kubernetes API server IP address.

#apiserver_host_ip = <None>

# Kubernetes API server port.

#apiserver_host_port = <None>

# Full path of the Token file to use for authenticating with the k8s API

# server.


# Full path of the client certificate file to use for authenticating with


# "client_private_key_file".

#client_cert_file = <None>


VMware, Inc. 43

# Full path of the client private key file to use for authenticating with


# "client_cert_file".

#client_private_key_file = <None>

# Specify a CA bundle file to use in verifying the k8s API server

# certificate.


# Specify whether ingress controllers are expected to be deployed in

# hostnework mode or as regular pods externally accessed via NAT

# Choices: hostnetwork nat

#ingress_mode = hostnetwork

# Log level for the kubernetes adaptor


#loglevel = <None>

# The default HTTP ingress port

#http_ingress_port = 80

# The default HTTPS ingress port

#https_ingress_port = 443

# Specify thread pool size to process resource events

#resource_watcher_thread_pool_size = 1

# User specified IP address for HTTP and HTTPS ingresses

#http_and_https_ingress_ip = <None>

# Set this to True to enable NCP to create tier1 router, first segment and

# default SNAT IP for VirtualNetwork CRD, and then create segment port for

# VM through VirtualNetworkInterface CRD.

#enable_vnet_crd = False

# Set this to True to enable NCP to create LoadBalancer on a Tier-1 for

# LoadBalancer CRD. This option does not support LB autoscaling.

#enable_lb_crd = False

# Option to set the type of baseline cluster policy. ALLOW_CLUSTER creates

# an explicit baseline policy to allow any pod to communicate any other pod

# within the cluster. ALLOW_NAMESPACE creates an explicit baseline policy

# to allow pods within the same namespace to communicate with each other.

# By default, no baseline rule will be created and the cluster will assume

# the default behavior as specified by the backend. Modification is not

# supported after the value is set.

# Choices: <None> allow_cluster allow_namespace

#baseline_policy_type = <None>

# Maximum number of endpoints allowed to create for a service.

#max_allowed_endpoints = 1000

# Set this to True to enable NCP reporting NSX backend error to k8s object

# using k8s event


VMware, Inc. 44

#enable_ncp_event = False

# Set this to True to enable multus to create multiple interfaces for one

# pod. If passthrough interface is usedas additional interface, user should

# deploy device plugin to provide device allocation information for NCP.Pod

# annotations under prefix "k8s.v1.cni.cncf.io" cannot be modified after

# pod realized. User defined IP will not be allocated from Segment IPPool.

# "gateway" in NetworkAttachmentDefinition is not used to configure

# secondary interfaces. Default gateway of pod is configured by primary

# interface. User must define IP and/or MAC if no "ipam" is configured.Only

# available if node type is HOSTVM

#enable_multus = True

# Interval of polling loadbalancer statistics. Default to60 seconds.

#lb_statistic_monitor_interval = 60

# This option is for toggling process of network CRD.It should be set to

# False when the network status setting is done by OCP4 NetworkOperator

#process_oc_network = True

[coe]

# Container orchestrator adaptor to plug in.

#adaptor = kubernetes

# Specify cluster for adaptor.

#cluster = k8scluster

# Log level for NCP operations


#loglevel = <None>

# Log level for NSX API client operations


#nsxlib_loglevel = <None>

# Enable SNAT for all projects in this cluster. Modification of topologies

# for existing Namespaces is not supported if this option is reset.

#enable_snat = True

# Option to enable profiling

#profiling = False

# The interval of reporting performance metrics (0 means disabled)

#metrics_interval = 0

# Name of log file for outputting metrics only (if not defined, use default

# logging facility)

#metrics_log_file = <None>

# The type of container host node

# Choices: HOSTVM BAREMETAL CLOUD WCP_WORKER

#node_type = HOSTVM

# The time in seconds for NCP/nsx_node_agent to recover the connection to


VMware, Inc. 45

# NSX manager/container orchestrator adaptor/Hyperbus before exiting. If

# the value is 0, NCP/nsx_node_agent won't exit automatically when the

# connection check fails

#connect_retry_timeout = 0

# Enable system health status report for SHA

#enable_sha = True

[nsx_kube_proxy]

# The way to process service configuration, set into OVS flow or write to

# nestdb,

# Choices: ovs nestdb

#config_handler = ovs

[nsx_node_agent]

# Prefix of node /proc and /var/run/netns path to mount on nsx_node_agent

# DaemonSet

#proc_mount_path_prefix = /host

# The log level of NSX RPC library


#nsxrpc_loglevel = ERROR

# OVS bridge name

#ovs_bridge = br-int

# The time in seconds for nsx_node_agent to wait CIF config from HyperBus

# before returning to CNI

#config_retry_timeout = 300

# The time in seconds for nsx_node_agent to backoff before re-using an

# existing cached CIF to serve CNI request. Must be less than

# config_retry_timeout.

#config_reuse_backoff_time = 15

# The OVS uplink OpenFlow port where to apply the NAT rules to.

#ovs_uplink_port = <None>

# Set this to True if you want to install and use the NSX-OVS kernel

# module. If the host OS is supported, it will be installed by nsx-ncp-

# bootstrap and used by nsx-ovs container in nsx-node-agent pod. Note that

# you would have to add (uncomment) the volumes and mounts in the nsx-ncp-

# bootstrap DS and add SYS_MODULE capability in nsx-ovs container spec in

# nsx-node-agent DS. Failing to do so will result in failure of

# installation and/or kernel upgrade of NSX-OVS kernelmodule.

#use_nsx_ovs_kernel_module = False

# The time in seconds for nsx_node_agent to call OVS command. Please

# increase the time if OVS is in heavy load to create/delete ports

#ovs_operation_timeout = 5

# Set to true to allow the CNI plugin to enable IPv6 container interfaces

#enable_ipv6 = False


VMware, Inc. 46

# Set to True if DHCP is configured on the "ovs_uplink_port". "auto" will

# try to automatically infer it but it only works on CoreOS. On other

# types host OS, it defaults to False

# Choices: True False auto

#is_dhcp_configured_on_ovs_uplink_port = auto

Aplicar el archivo YAML de NCP

Después de editar el archivo YAML de NCP, puede aplicar el archivo YAML para crear y ejecutar los recursos.

Ejecute el siguiente comando para aplicar el archivo YAML de NCP. Por ejemplo,

kubectl apply -f ncp-ubuntu.yaml

Ejecute el siguiente comando para comprobar el resultado. Por ejemplo,

~# kubectl get pods -n nsx-system

nsx-ncp-5df7fdf8b9-b6lmx 1/1 Running 0 77s

nsx-ncp-bootstrap-rv6z2 1/1 Running 0 76s

nsx-ncp-bootstrap-tzbv2 1/1 Running 0 76s

nsx-ncp-bootstrap-z4tt5 1/1 Running 0 76s

nsx-node-agent-ghnjk 3/3 Running 0 76s

nsx-node-agent-jkrct 3/3 Running 0 76s

nsx-node-agent-tz6td 3/3 Running 0 76s

También puede ejecutar el comando kubectl get all -n nsx-system para ver más detalles.

Montar un archivo de certificado en el pod de NCP

Debe montar un archivo de certificado en el pod de NCP para configurar una autenticación basada en certificados con la API de NSX-T o un certificado predeterminado para la descarga de SSL del equilibrador de carga de NSX-T.

En ambos casos, siga estos pasos:

n Cree un secreto con un certificado y una clave privada.

n Asocie un volumen de secreto al pod de NCP y monte el volumen (consulte el ConfigMap de ejemplo que se incluye a continuación).

Para configurar una autenticación basada en certificados con la API de NSX-T, especifique las opciones nsx_api_cert_file y nsx_api_private_key_file en [nsx_v3] dentro del ConfigMap nsx-ncp-config con la ruta de montaje del certificado y la clave.

Para configurar la descarga de SSL del equilibrador de carga de NSX-T, especifique las opciones lb_default_cert_path y lb_priv_key_path en [nsx_v3] dentro del ConfigMap nsx-ncp-config con la ruta de montaje del certificado y la clave.


VMware, Inc. 47

https://opengrok.eng.vmware.com/source/s?path=ncp-ubuntu.yaml&project=nsx-ujo.git

Sección de ConfigMap en la que debe especificar las rutas del certificado y la clave:

volumes:

- name: projected-volume

projected:

sources:

# ConfigMap nsx-ncp-config is expected to supply ncp.ini

- configMap:

name: nsx-ncp-config

items:

- key: ncp.ini

path: ncp.ini

# To use cert based auth, uncomment and update the secretName,

# then update ncp.ini with the mounted cert and key file paths

#- secret:

# name: nsx-secret

# items:

# - key: tls.crt

# path: nsx-cert/tls.crt

# - key: tls.key

# path: nsx-cert/tls.key

#- secret:

# name: lb-secret

# items:

# - key: tls.crt

# path: lb-cert/tls.crt

# - key: tls.key

# path: lb-cert/tls.key

# To use JWT based auth, uncomment and update the secretName.

#- secret:

# name: wcp-cluster-credentials

# items:

# - key: username

# path: vc/username

# - key: password

# path: vc/password

Configurar IPv6

Puede configurar NCP para que sea compatible con IPv6.

Para configurar IPv6, tenga en cuenta lo siguiente:

n Solo se admite el modo Directiva. Para obtener más información, consulte Capítulo 2 Configurar recursos de NSX-T.

n Se admiten tanto las topologías de un solo nivel como de dos niveles.

n Para que el tráfico de norte a sur funcione correctamente, la puerta de enlace de nivel 0 debe tener una dirección IPv6.


VMware, Inc. 48

n Los nodos de Kubernetes deben tener una dirección IPv6. De lo contrario, no habrá conectividad entre los nodos y los pods, y los sondeos de disponibilidad y de la ejecución HTTP y TCP no funcionarán. Se pueden utilizar direcciones IP estáticas o SLAAC para los nodos de Kubernetes. Los nodos de Kubernetes también pueden estar en modo de dos pilas. En este caso, debe registrar el nodo con una dirección IPv6 en Kubernetes. Para ello, especifique la dirección IPv6 con la opción -node-ip como uno de los parámetros de inicio de kubelet. De lo contrario, kubelet siempre priorizará la dirección IPv4.

n El clúster de Kubernetes debe crearse con un CIDR de red de clúster de servicios IPv6. Tenga en cuenta que el tamaño máximo de esta subred es de 16 bits.

n En la configuración de NCP, debe deshabilitar SpoofGuard estableciendo enable_spoofguard = False en la sección [nsx_v3].

n En la configuración de nsx-node-agent, IPv6 debe estar habilitado para indicar al complemento CNI que habilite IPv6 en los contenedores. Para ello, establezca enable_ipv6 = True en la sección [nsx-node-agent]. Asegúrese de configurar esta opción antes de que se ejecute el proceso de arranque de NCP.

n Todos los espacios de nombres se encontrarán en modo no SNAT. SNAT por servicio, así como cualquier otra función de SNAT, no estarán habilitados en IPv6.

n No se admite la pila dual para contenedores. Cada contenedor debe tener solo una dirección IPv6.

n Si se combinan bloques de direcciones IPv4 e IPv6 en la configuración de NCP, se producirá un error al iniciar.

Configurar syslog

Puede ejecutar un agente syslog, como rsyslog o syslog-ng, en un contenedor para enviar registros desde NCP y los componentes a un servidor syslog.

Es posible utilizar uno de los siguientes métodos para configurar el registro. Para obtener más información sobre cómo realizar registros en Kubernetes, consulte https://kubernetes.io/docs/concepts/cluster-administration/logging.

n Cree un contenedor sidecar que se ejecute en NCP o en el pod nsx-node-agent.

n Ejecute una réplica de DaemonSet en cada nodo.

Nota Con el método del contenedor sidecar, los registros del complemento CNI de NSX no se pueden enviar al servidor syslog porque el complemento no se ejecuta en un pod.

Crear un contenedor sidecar para syslog

Puede configurar un contenedor sidecar para syslog si desea ejecutarlo en el mismo pod que NCP. El siguiente procedimiento asume que la imagen del agente syslog es ejemplo/rsyslog.


VMware, Inc. 49

https://kubernetes.io/docs/concepts/cluster-administration/logging

https://kubernetes.io/docs/concepts/cluster-administration/logging

Procedimiento

1 Configure el agente del nodo de NSX y de NCP para registrarlo en un archivo.

En el archivo yaml para el agente del nodo de NSX y de NCP, establezca el parámetro log_dir y especificar el volumen que se montará. Por ejemplo,

[DEFAULT]

log_dir = /var/log/nsx-ujo/

...

spec:

...

containers:

- name: nsx-ncp

...

volumeMounts:

- name: nsx-ujo-log-dir

# Mount path must match [DEFAULT] option "log_dir"

mountPath: /var/log/nsx-ujo

volumes:

...


hostPath:

path: /var/log/nsx-ujo

Puede cambiar el nombre del archivo de registro estableciendo el parámetro log_file. Los nombres predeterminados son ncp.log, nsx_node_agent.log y nsx_kube_proxy.log. Si la opción log_dir se establece en una ruta de acceso que no sea /var/log/nsx-ujo, se debe crear un volumen hostPath o emptyDir y se debe montar en la especificación del pod correspondiente.

2 Asegúrese de que la ruta de acceso de host existe y que el usuario nsx-ncp puede escribir en ella.

a Ejecute los siguientes comandos.

mkdir -p <host-filesystem-log-dir-path>

chmod +w <host-filesystem-log-dir-path>

b Agregue el usuario nsx-ncp o cambie el modo de la ruta de acceso de host a 777.

useradd -s /bin/bash nsx-ncp

chown nsx-ncp:nsx-ncp <host-filesystem-log-dir-path>

or

chmod 777 <host-filesystem-log-dir-path>

3 En el archivo yaml de la especificación del pod de NCP, agregue ConfigMap para syslog. Por ejemplo,

kind: ConfigMap

metadata:

name: rsyslog-config


VMware, Inc. 50

labels:

version: v1

data:

ncp.conf: |

module(load="imfile")

ruleset(name="remote") {

action(type="omfwd"

Protocol="tcp"

Target="nsx.example.com"

Port="514")

stop

}

input(type="imfile"

File="/var/log/nsx-ujo/ncp.log"

Tag="ncp"

Ruleset="remote"

4 En el archivo yaml del pod de NCP, agregue el contenedor rsyslog y monte los volúmenes apropiados donde rsyslog pueda encontrar los datos de configuración y leer los registros de otros contenedores. Por ejemplo,

spec:

containers:

- name: nsx-ncp

...

- name: rsyslog

image: example/rsyslog

imagePullPolicy: IfNotPresent

volumeMounts:

- name: rsyslog-config-volume

mountPath: /etc/rsyslog.d

readOnly: true



volumes:

...


configMap:



hostPath:

path: <host-filesystem-log-dir-path>

Crear una réplica de DaemonSet para Syslog

Los registros de todos los componentes de NCP se pueden redireccionar con este método. Es necesario que se configuren las aplicaciones de forma que se registren en stderr, que está habilitado de forma predeterminada. El siguiente procedimiento asume que la imagen del agente syslog es ejemplo/rsyslog.


VMware, Inc. 51

Procedimiento

1 Cree el archivo de yaml de DaemonSet. Por ejemplo,

apiVersion: v1

kind: ConfigMap

metadata:


labels:

version: v1

data:

nsx-ncp.conf: |



if $msg contains 'nsx-container' then

action(type="omfwd"

Protocol="tcp"

Target="nsx.example.com"

Port="514")

stop

}

input(type="imfile"

File="/var/log/containers/nsx-node-agent-*.log"

Tag="nsx-node-agent"

Ruleset="remote")

input(type="imfile"

File="/var/log/containers/nsx-ncp-*.log"

Tag="nsx-ncp"

Ruleset="remote")

input(type="imfile"

File="/var/log/syslog"

Tag="nsx-cni"

Ruleset="remote")

---

# rsyslog DaemonSet

apiVersion: extensions/v1beta1

kind: DaemonSet

metadata:

name: rsyslog

labels:

component: rsyslog

version: v1

spec:

template:

metadata:

labels:

component: rsyslog

version: v1

spec:

hostNetwork: true


VMware, Inc. 52

containers:

- name: rsyslog

image: example/rsyslog


volumeMounts:



- name: log-volume

mountPath: /var/log

- name: container-volume

mountPath: /var/lib/docker/containers

volumes:


configMap:


- name: log-volume

hostPath:

path: /var/log

- name: container-volume

hostPath:

path: /var/lib/docker/containers

2 Cree DaemonSet.

kubectl apply -f <daemonset yaml file>

Ejemplo: Configuración de la rotación de registros y la ejecución de Syslog en un contenedor sidecar

El siguiente procedimiento muestra cómo configurar la rotación de registros y la ejecución de Syslog en un contenedor sidecar.

Creación del directorio de registros y configuración de la rotación de registros

n Cree el directorio de registros en todos los nodos, incluido el principal, y cambie su propietario al usuario que tenga el identificador 1000.

mkdir /var/log/nsx-ujo

chown localadmin:localadmin /var/log/nsx-ujo

n Configure la rotación de registros en todos los nodos del directorio /var/log/nsx-ujo.

cat <<EOF > /etc/logrotate.d/nsx-ujo

/var/log/nsx-ujo/*.log {

copytruncate

daily

size 100M

rotate 4

delaycompress

compress


VMware, Inc. 53

notifempty

missingok

}

EOF

Creación de la controladora de replicación de NCP

n Cree el archivo ncp.ini para NCP.

cat <<EOF > /tmp/ncp.ini

[DEFAULT]

log_dir = /var/log/nsx-ujo

[coe]

cluster = k8s-cl1

[k8s]

apiserver_host_ip = 10.114.209.77

apiserver_host_port = 6443



insecure = True

ingress_mode = nat

[nsx_v3]

nsx_api_user = admin

nsx_api_password = Password1!

nsx_api_managers = 10.114.209.68

insecure = True

subnet_prefix = 29

[nsx_node_agent]

[nsx_kube_proxy]

ovs_uplink_port = ens192

EOF

n Cree el mapa de configuración del archivo INI.

kubectl create configmap nsx-ncp-config-with-logging --from-file=/tmp/ncp.ini

n Cree la configuración de rsyslog de NCP.

cat <<EOF > /tmp/nsx-ncp-rsyslog.conf

# yaml template for NCP ReplicationController

# Correct kubernetes API and NSX API parameters, and NCP Docker image

# must be specified.

apiVersion: v1

kind: ConfigMap

metadata:


labels:

version: v1

data:

ncp.conf: |



action(type="omfwd"


VMware, Inc. 54

Protocol="tcp"

Target="nsx.licf.vmware.com"

Port="514")

stop

}

input(type="imfile"

File="/var/log/nsx-ujo/ncp.log"

Tag="ncp"

Ruleset="remote")

EOF

n Cree el mapa de configuración del elemento anterior.

kubectl create -f /tmp/nsx-ncp-rsyslog.conf

n Cree la controladora de replicación de NCP con el rsyslog sidecar.

cat <<EOF > /tmp/ncp-rc-with-logging.yml

# Replication Controller yaml for NCP

apiVersion: v1

kind: ReplicationController

metadata:

# VMware NSX Container Plugin

name: nsx-ncp

labels:

tier: nsx-networking

component: nsx-ncp

version: v1

spec:

# Active-Active/Active-Standby is not supported in current release.

# so replica *must be* 1.

replicas: 1

template:

metadata:

labels:


component: nsx-ncp

version: v1

spec:

# NCP shares the host management network.

hostNetwork: true

nodeSelector:

kubernetes.io/hostname: k8s-master

tolerations:

- key: "node-role.kubernetes.io/master"

operator: "Exists"

effect: "NoSchedule"

containers:

- name: nsx-ncp

# Docker image for NCP

image: nsx-ujo-docker-local.artifactory.eng.vmware.com/nsx-ncp:ob-6236425



VMware, Inc. 55

readinessProbe:

exec:

command:

- cat

- /tmp/ncp_ready

initialDelaySeconds: 5

periodSeconds: 5

failureThreshold: 5

securityContext:

capabilities:

add:

- NET_ADMIN

- SYS_ADMIN

- SYS_PTRACE

- DAC_READ_SEARCH

volumeMounts:

- name: config-volume

# NCP expects ncp.ini is present in /etc/nsx-ujo

mountPath: /etc/nsx-ujo

- name: log-volume


- name: rsyslog

image: jumanjiman/rsyslog


volumeMounts:



readOnly: true

- name: log-volume


volumes:


# ConfigMap nsx-ncp-config is expected to supply ncp.ini

configMap:

name: nsx-ncp-config-with-logging


configMap:


- name: log-volume

hostPath:

path: /var/log/nsx-ujo/

EOF

n Cree NCP con la especificación anterior.

kubectl apply -f /tmp/ncp-rc-with-logging.yml

Creación de DaemonSet del agente de nodo de NSX

n Cree la configuración de rsyslog para los agentes de nodo.

cat <<EOF > /tmp/nsx-node-agent-rsyslog.conf

# yaml template for NCP ReplicationController

# Correct kubernetes API and NSX API parameters, and NCP Docker image


VMware, Inc. 56

# must be specified.

apiVersion: v1

kind: ConfigMap

metadata:

name: rsyslog-config-node-agent

labels:

version: v1

data:

ncp.conf: |



action(type="omfwd"

Protocol="tcp"

Target="nsx.licf.vmware.com"

Port="514")

stop

}

input(type="imfile"

File="/var/log/nsx-ujo/nsx_kube_proxy.log"

Tag="nsx_kube_proxy"

Ruleset="remote")

input(type="imfile"

File="/var/log/nsx-ujo/nsx_node_agent.log"

Tag="nsx_node_agent"

Ruleset="remote")

EOF

n Cree el configmap a partir de los anteriores.

kubectl create -f /tmp/nsx-node-agent-rsyslog.conf

n Cree DaemonSet con el configmap sidecar.

cat <<EOF > /tmp/nsx-node-agent-rsyslog.yml

# nsx-node-agent DaemonSet


kind: DaemonSet

metadata:

name: nsx-node-agent

labels:


component: nsx-node-agent

version: v1

spec:

template:

metadata:

annotations:

container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-

apparmor

labels:


VMware, Inc. 57


component: nsx-node-agent

version: v1

spec:

hostNetwork: true

tolerations:

- key: "node-role.kubernetes.io/master"

operator: "Exists"

effect: "NoSchedule"

containers:

- name: nsx-node-agent




# override NCP image entrypoint

command: ["nsx_node_agent"]

livenessProbe:

exec:

command:

- /bin/sh

- -c

- ps aux | grep [n]sx_node_agent


periodSeconds: 5

securityContext:

capabilities:

add:

- NET_ADMIN

- SYS_ADMIN

- SYS_PTRACE

- DAC_READ_SEARCH

volumeMounts:

# ncp.ini



# mount openvswitch dir

- name: openvswitch

mountPath: /var/run/openvswitch

# mount CNI socket path

- name: cni-sock

mountPath: /var/run/nsx-ujo

# mount container namespace

- name: netns

mountPath: /var/run/netns

# mount host proc

- name: proc

mountPath: /host/proc

readOnly: true

- name: log-volume


- name: nsx-kube-proxy




# override NCP image entrypoint


VMware, Inc. 58

command: ["nsx_kube_proxy"]

livenessProbe:

exec:

command:

- /bin/sh

- -c

- ps aux | grep [n]sx_kube_proxy


periodSeconds: 5

securityContext:

capabilities:

add:

- NET_ADMIN

- SYS_ADMIN

- SYS_PTRACE

- DAC_READ_SEARCH

volumeMounts:

# ncp.ini



# mount openvswitch dir

- name: openvswitch

mountPath: /var/run/openvswitch

- name: log-volume


- name: rsyslog

image: jumanjiman/rsyslog


volumeMounts:



readOnly: true

- name: log-volume


volumes:


configMap:

name: nsx-ncp-config-with-logging

- name: cni-sock

hostPath:

path: /var/run/nsx-ujo

- name: netns

hostPath:

path: /var/run/netns

- name: proc

hostPath:

path: /proc

- name: openvswitch

hostPath:

path: /var/run/openvswitch


configMap:

name: rsyslog-config-node-agent


VMware, Inc. 59

- name: log-volume

hostPath:

path: /var/log/nsx-ujo/

EOF

n Cree DaemonSet.

kubectl apply -f /tmp/nsx-node-agent-rsyslog.yml

Consideraciones de seguridad

Cuando implemente NCP, es importante que realice los pasos pertinentes para asegurar los entornos de Kubernetes y de NSX-T Data Center.

Restringir NCP para que solo se ejecute en nodos designados

NCP tiene acceso al plano de administración de NSX-T Data Center y se debe limitar para que solo se ejecute en nodos de infraestructura designados. Puede identificar estos nodos con una etiqueta apropiada. Se debe aplicar un nodeSelector de esta etiqueta a la especificación ReplicationController de NCP. Por ejemplo,

nodeSelector:

nsx-infra: True

También puede usar otros mecanismos, como la afinidad, para asignar pods a nodos. Para obtener más información, consulte https://kubernetes.io/docs/concepts/configuration/assign-pod-node.

Asegurarse de que Docker Engine esté actualizado

Docker publica periódicamente actualizaciones de seguridad. Se debe implementar un procedimiento automatizado para aplicar esas actualizaciones.

No permitir las funciones NET_ADMIN y NET_RAW de contenedores sin confianza

Los atacantes pueden aprovechar las funciones NET_ADMIN y NET_RAW de Linux para poner en peligro la red de pods. Debe deshabilitar estas dos funciones de contenedores en los que no confía. De forma predeterminada, la función NET_ADMIN no se otorga a un contenedor sin privilegios. Tenga en cuenta que una especificación de pod puede habilitarla o establecer el contenedor en modo privilegiado. Además, en los contenedores que no son de confianza, deshabilite NET_RAW especificando este valor en la lista de funciones descartadas en la configuración SecurityContext de la especificación del contenedor. Por ejemplo,

securityContext:

capabilities:

drop:


VMware, Inc. 60

https://kubernetes.io/docs/concepts/configuration/assign-pod-node

https://kubernetes.io/docs/concepts/configuration/assign-pod-node

- NET_RAW

- ...

Control de acceso basado en funciones

Kubernetes usa la API del Control de acceso basado en funciones (Role-Based Access Control, RBAC) para tomar decisiones de autorización, permitiendo que los administradores configuren directivas. Para obtener más información, consulte https://kubernetes.io/docs/admin/authorization/rbac.

Por lo general, el administrador de clústeres es el único usuario con funciones y acceso privilegiados. Para las cuentas del servicio y de usuarios, se debe seguir el principio de mínimo privilegio al otorgar acceso.

Se recomienda seguir las siguientes instrucciones:

n Restringir el acceso a los tokens de la API de Kubernetes de los pods que los necesiten.

n Restringir el acceso a ConfigMap de NCP y a los secretos TLS del certificado cliente de NSX API al pod de NCP.

n Bloquear el acceso a la API de redes de Kubernetes desde pods que no requieran dicho acceso.

n Agregar una directiva RBAC de Kubernetes para especificar los pods que tienen acceso a la API de Kubernetes.

La directiva RBAC recomendada ya está en el archivo YAML de NCP y será efectiva cuando instale NCP.

Configuración de recursos de red

Al configurar algunos recursos de red, debe tener en cuenta ciertas restricciones.

Límites de etiquetas

Las etiquetas tienen los siguientes límites:

n El ámbito de las etiquetas tiene un límite de 128 caracteres.

n El valor de las etiquetas tiene un límite de 256 caracteres.

n Cada objeto puede tener hasta 30 etiquetas.

Estos límites pueden ocasionar problemas cuando se copian anotaciones de Kubernetes u OpenShift en los ámbitos y las etiquetas de NSX-T Data Center y se superan los límites. Por ejemplo, si una etiqueta de un puerto de conmutador se utiliza en una regla de firewall, es posible que la regla no se aplique según lo previsto debido a que la clave o el valor de anotación se hayan truncado al copiarlos en un ámbito o una etiqueta.

Las etiquetas tienen estos límites:

n Un pod no puede tener más de 25 etiquetas.


VMware, Inc. 61

https://kubernetes.io/docs/admin/authorization/rbac

https://kubernetes.io/docs/admin/authorization/rbac

n Un espacio de nombres no puede tener más de 27 etiquetas.

n Un pod de controlador de entrada no puede tener más de 24 etiquetas.

Directivas de redes

Un recurso de NetworkPolicy tiene las siguientes limitaciones:

n podSelector o namespaceSelector no pueden tener más de 4 matchLabels.

n En una sección de ingress from o egress to, si tiene un único elemento que especifica namespaceSelector y podSelector, namespaceSelector no debe seleccionar más de 5 espacios de nombres. De lo contrario, se producirá un error. Este es un ejemplo de esta especificación (tenga en cuenta que no hay guiones antes de podSelector):

- namespaceSelector:

matchLabels:

project: myproject

podSelector:

matchLabels:

role: db

n Para cualquier regla de entrada o salida, el número total de namespaceSelector más podSelector no puede ser superior a 5. Por ejemplo, esto no estaría permitido porque la regla tiene un total de 6 selectores:

ingress:


matchLabels:

project: myproject1


matchLabels:

project: myproject2


matchLabels:

project: myproject3

- podSelector:

matchLabels:

role: db

- podSelector:

matchLabels:

role: app

- podSelector:

matchLabels:

role: infra

n No se admite la directiva de red allow-all-egress con namedPorts en la sección to.ports.

n El campo matchExpressions no se admite.

n No se admite la directiva de red con SCTP en el campo protocol.


VMware, Inc. 62

Para solucionar las limitaciones, puede crear una directiva de red con matchLabels más específicas o reemplazar una directiva de red por varias directivas de red que no requieran más de 5 selectores.

Si NCP no admite una directiva de red, NCP la anotará con un error. Puede actualizar la directiva de red para solucionar el error y NCP la procesará de nuevo.

En NCP 3.0.0 y 3.0.1, si una directiva de red solo tiene especificadas salidas, pero no entradas, se creará una regla de firewall para permitir todo el tráfico de entrada. De forma similar, si una directiva de red solo tiene especificadas entradas, pero no salidas, se creará una regla de firewall para permitir todo el tráfico de salida.

A partir de NCP 3.0.2, si una directiva de red solo tiene especificadas salidas, pero no entradas, no se creará ninguna regla de firewall para el tráfico de entrada. De forma similar, si una directiva de red solo tiene especificadas entradas, pero no salidas, no se creará ninguna regla de firewall para el tráfico de salida.

Limpiar los nodos de Kubernetes

Puede limpiar los cambios que haya hecho el contenedor de arranque en el sistema de archivos.

Nota Si se elimina el DaemonSet nsx-node-agent, OVS no podrá ejecutarse en el host (ni en el contenedor ni en el PID del host).

Procedimiento para NCP 2.5.0

Para deshacer los cambios que haya hecho el contenedor de arranque, realice los siguientes pasos:

n Elimine NSX-CNI:

n Elimine /etc/cni/net.d/10-nsx.conf.

n Elimine /etc/cni/net.d/99-loopback.conf.

n Solo en RHEL, elimine /opt/cni/bin/loopback.

n Elimine /opt/cni/bin/nsx.

n Solo en Ubuntu, ejecute los siguientes comandos:

apparmor_parser -R /etc/apparmor.d/ncp-apparmor

rm -rf /etc/apparmor.d/ncp-apparmor

sudo /etc/init.d/apparmor reload

n Elimine el kmod de OVS instalado por NSX:


VMware, Inc. 63

El kmod de OVS incluye los siguientes archivos:

openvswitch.ko

vport-geneve.ko

vport-gre.ko

vport-lisp.ko

vport-stt.ko

vport-vxlan.ko

n Busque la versión del kernel en ejecución con el comando uname -r.

n Solo en RHEL, elimine todos los archivos del kmod de OVS de /lib/modules/${kversion}/weak-updates/openvswitch.

n Solo en Ubuntu, elimine todos los archivos kmod de OVS de /lib/modules/${kversion}/updates/dkms.

n Vaya a /lib/modules/${kversion}/nsx y compruebe si existe el directorio usr-ovs-kmod-backup. Si existe, significa que tuvo instalado un módulo de kernel de OVS personalizado. Realice los pasos siguientes:

n Vaya a /lib/modules/${kversion}/nsx/usr-ovs-kmod-backup.

n Busque el archivo con el nombre INFO. Este contiene la ruta donde pueden encontrarse los archivos. Utilice esta ruta de acceso para restaurar los archivos.

n Ejecute el comando depmod.

n Ejecute el comando /usr/share/openvswitch/scripts/ovs-ctl force-reload-kmod --system-id=random si OVS está instalado en la máquina host.

Procedimiento para NCP 2.5.1 y versiones posteriores

Puede crear el DaemonSet nsx-ncp-cleanup para deshacer los cambios del sistema que haya hecho DaemonSet nsx-ncp-bootstrap. Este DaemonSet solo debe crearse si aplicó previamente el archivo YAML de NCP (ncp-ubuntu.yaml o ncp-rhel.yaml) y no se ha eliminado. Tenga en cuenta que el DaemonSet nsx-ncp-cleanup desinstalará CNI de NSX, lo que provocará que el nodo de Kubeternetes tenga un estado no válido.

Para crear el DaemonSet, siga estos pasos.

n Elimine los DaemonSet nsx-ncp-bootstrap y nsx-node-agent. Por ejemplo, puede ejecutar los siguientes comandos con el nombre de espacio de nombres correspondiente:

kubectl delete ds nsx-ncp-bootstrap -n <namespace>

kubectl delete ds nsx-node-agent -n <namespace>

n Ejecute kubectl apply -f ncp-cleanup-ubuntu.yaml o kubectl apply -f ncp-cleanup-rhel.yaml (en función del sistema operativo del host) desde la línea de comandos del nodo maestro de Kubernetes.

Para poder volver a utilizar el nodo, ejecute kubectl apply -f ncp-ubuntu.yaml o kubectl apply -f ncp-rhel.yaml, según el sistema operativo del host.


VMware, Inc. 64

Instalación de NCP en un entorno de Pivotal Cloud Foundry 4Pivotal Cloud Foundry (PCF) es un proveedor de plataforma como servicio (PaaS) de código abierto. Puede instalar NSX Container Plug-in (NCP) en un entorno de PCF para proporcionar servicios de redes.

Las máquinas virtuales creadas mediante Pivotal Ops Manager deben tener conectividad de capa 3 con la red del contenedor para acceder a las funciones de NSX-T.

La alta disponibilidad (HA) se habilita automáticamente.

Nota Cuando se efectúa un cambio en un grupo de seguridad, se deben volver a realizar copias intermedias de todas las aplicaciones a las que se aplica el grupo de seguridad. Esto puede ocurrir debido a que el grupo de seguridad se aplica al espacio en el que se ejecutan las aplicaciones, o porque el grupo de seguridad es global.

Si tiene un ASG (grupo de seguridad de aplicaciones) predeterminado en el entorno de PAS, debe crear una sección de firewall global fuera de NCP para reemplazar el ASG predeterminado.


n Instalación de NCP en un entorno de Pivotal Cloud Foundry

n Cómo gestionar las etiquetas personalizadas en PAS

Instalación de NCP en un entorno de Pivotal Cloud Foundry

NCP se instala mediante la interfaz gráfica de usuario de Pivotal Ops Manager.

Requisitos previos

Una instalación nueva de Pivotal Ops Manager, NSX-T Data Center y Pivotal Application Service (PAS). Asegúrese de que Ops Manager se instale primero, luego NSX-T Data Center y, por último, PAS. Para obtener más información, consulte la documentación de Pivotal Cloud Foundry.

Procedimiento

1 Descargue el archivo de instalación de NCP para PCF.

El nombre de archivo es VMware-NSX-T.<versión>.<compilación>.pivotal.

VMware, Inc. 65

2 Inicie sesión en Pivotal Ops Manager como administrador.

3 Haga clic en Importar un producto.

4 Seleccione el archivo que se descargue.

5 Haga clic en el mosaico Ops Manager Director for VMware vSphere.

6 En la pestaña Configuración de Configuración de vCenter, seleccione Redes NSX y, en Modo de NSX, seleccione NSX-T.

7 En el campo Certificado de CA de NSX, proporcione el certificado en formato PEM.

8 Haga clic en Guardar.

9 Haga clic en el Panel de control de instalación en la esquina superior izquierda para volver al panel de control.

10 Haga clic en el mosaico Pivotal Application Service.

11 En la pestaña Configuración, seleccione Redes en el panel de navegación.

12 En el complemento de la interfaz de red del contenedor, seleccione Externo.




16 Haga clic en el mosaico VMware NSX-T.

17 Introduzca la dirección de NSX Manager.

18 Seleccione el método de autenticación de NSX Manager.

Opción Acción

Autenticación de certificado de cliente

Proporcione el certificado y la clave privada para NSX Manager.

Autenticación básica con nombre de usuario y contraseña

Proporcione el nombre de usuario y la contraseña del administrador de NSX Manager.

19 En el campo Certificado de CA de NSX Manager, proporcione el certificado.


21 Seleccione NCP en el panel de navegación.

22 Introduzca el nombre de la fundación PAS.

Esta cadena identifica una fundación PAS de forma exclusiva en la API de NSX. Esta cadena también se utiliza como prefijo en los nombres de los recursos de NSX creados por NCP para la fundación PAS.

23 Indique el valor de Zona de transporte superpuesta.


VMware, Inc. 66

24 Introduzca el valor de Enrutador de nivel 0.

25 Especifique uno o varios bloques de IP de redes del contenedor.

a Haga clic en Agregar.

b Introduzca el nombre del bloque de IP. Puede ser un bloque de IP nuevo o existente.

c Solo para un nuevo bloque de IP, especifique el bloque en formato CIDR; por ejemplo, 10.1.0.0/16.

26 Especifique el prefijo de subred de las redes del contenedor.

27 Haga clic en Habilitar SNAT para redes del contenedor para habilitar SNAT.

28 Especifique uno o varios grupos de IP que se utilizan para proporcionar una dirección IP externa (NAT) a redes de organización.

a Haga clic en Agregar.

b Introduzca el nombre del grupo de IP. Puede ser un grupo de IP nuevo o existente.

c Solo para un nuevo grupo de IP, especifique las direcciones IP mediante la entrega de CIDR y los rangos de IP.

29 (opcional) Introduzca el marcador de la sección del firewall superior.

30 (opcional) Introduzca el marcador de la sección del firewall inferior.

31 (opcional) Habilite o deshabilite las siguientes opciones.

Opción Valor predeterminado

Registrar tráfico perdido de la aplicación

Deshabilitado. Si se habilita, se registrará el tráfico que se pierda debido a una regla de firewall.

Habilitar el nivel de depuración para el registro de NCP

Habilitado.


33 (opcional) Seleccione Agente de nodo de NSX en el panel de navegación.

a Marque la casilla Habilitar el nivel de depuración de registro para el agente de nodo de NSX para habilitar el registro a nivel de depuración.

b Haga clic en Guardar.


35 Haga clic en Aplicar cambios.

Cómo gestionar las etiquetas personalizadas en PAS

NCP puede gestionar las etiquetas personalizadas que cree en una aplicación en PAS. NCP creará las etiquetas correspondientes en NSX-T para esas etiquetas.


VMware, Inc. 67

En PAS, puede utilizar el siguiente comando para crear etiquetas. Por ejemplo,

cf curl v3/apps/<app-guid> -X PATCH -d '{"metadata": {"labels": {"aaa": "111", "bbb": "222"}}

También puede eliminar una etiqueta. Para ello, establezca el valor null para la etiqueta. Por ejemplo:

cf curl v3/apps/<app-guid> -X PATCH -d '{"metadata": {"labels":{"aaa": null}}}'

Estos comandos activan eventos que NCP puede recuperar. En el caso de una etiqueta nueva (por ejemplo, "aaa":"111"), NCP creará la etiqueta app_label/aaa:111 para los puertos lógicos de todas las instancias de la aplicación. Si quita una etiqueta, se eliminará la etiqueta correspondiente.


VMware, Inc. 68

Equilibrio de carga 5El equilibrador de carga de NSX-T Data Center está integrado en Kubernetes.


n Configuración del equilibrio de carga

n Cómo configurar la persistencia del equilibrador de carga de Capa 4 y Capa 7

n Ingress

n LoadBalancer CRDs to Handle Ingress Scaling

n Servicio de tipo LoadBalancer

n Equilibrador de carga y directiva de red

n Script de ejemplo para generar un certificado firmado por CA

n Controladores de entrada de terceros

Configuración del equilibrio de carga

Puede configurar la integración del equilibrador de carga de NSX-T con NCP para los servicios LoadBalancer y los recursos de entrada de Kubernetes.

Cuando se configura un servicio de Kubernetes de tipo LoadBalancer, se crea un equilibrador de carga de Capa 4, mientras que cuando se configura un recurso de entrada de Kubernetes se crea un equilibrador de carga de Capa 7.

Para configurar el equilibrio de carga, realice estos pasos en el ConfigMap nsx-ncp-config:

1 Establezca use_native_loadbalancer como True.

2 (Opcional) Establezca pool_algorithm como ROUND_ROBIN o LEAST_CONNECTION/IP_HASH. El valor predeterminado es ROUND_ROBIN.

3 (Opcional) Establezca service_size como SMALL, MEDIUM o LARGE. El valor predeterminado es SMALL. En el modo Directiva, establezca este valor para que coincida con el tamaño de asignación de grupo de la puerta de enlace de nivel 1.

VMware, Inc. 69

El algoritmo LEAST_CONNECTION/IP_HASH indica que el tráfico de la misma dirección IP de origen se enviará al mismo pod de back-end.

Para obtener detalles sobre lo que admiten los equilibradores de carga de NSX-T de diferentes tamaños, consulte la Guía de administración de NSX-T Data Center.

Después de que se crea el equilibrador de carga, no es posible cambiar su tamaño actualizando el archivo de configuración. Se puede cambiar mediante la interfaz de usuario o la API de NSX Manager.

Puede configurar un IPSet que NCP rellenará con las direcciones IP de todos los servicios virtuales. Para habilitar esta función, establezca la opción lb_vs_ip_set en el ConfigMap nsx-ncp-config para que sea el nombre o el UUID de un IPSet. Varios clústeres pueden compartir el IPSet. Las direcciones IP deben ser únicas en todos los clústeres. NCP administrará la asignación de las direcciones IP.

Cómo configurar la persistencia del equilibrador de carga de Capa 4 y Capa 7

Puede especificar la configuración de persistencia con los parámetros l4_persistence y l7_persistence en el ConfigMap de NCP.

La opción disponible para la persistencia de capa 4 es la IP de origen. Las opciones disponibles para la persistencia de capa 7 son IP de origen y cookie. El valor predeterminado es <None>. Por ejemplo,

# Choice of persistence type for ingress traffic through L7 Loadbalancer.

# Accepted values:

# 'cookie'

# 'source_ip'

l7_persistence = cookie

# Choice of persistence type for ingress traffic through L4 Loadbalancer.

# Accepted values:

# 'source_ip'

l4_persistence = source_ip

Para los equilibradores de carga de Kubernetes, también puede establecer sessionAffinity en la especificación del servicio para configurar su comportamiento de persistencia si la persistencia global de capa 4 está desactivada (es decir, si l4_persistence se ha establecido como <None>). Si se ha establecido l4_persistence como source_ip, se puede utilizar sessionAffinity en la especificación de servicio para personalizar el tiempo de espera de la persistencia del servicio. El tiempo de espera predeterminado de la persistencia de capa 4 es de 10800 segundos (como se especifica en la documentación de Kubernetes para servicios (https://kubernetes.io/docs/


VMware, Inc. 70

https://kubernetes.io/docs/concepts/services-networking/service

concepts/services-networking/service). Los servicios con un tiempo de espera de persistencia predeterminado compartirán el mismo perfil de persistencia del equilibrador de carga de NSX-T. Se creará un perfil dedicado para cada servicio con un tiempo de espera de persistencia no predeterminado.

Nota Si el servicio back-end de una entrada es un servicio de tipo equilibrador de carga, el servidor virtual de capa 4 para el servicio y el servidor virtual de capa 7 para la entrada no pueden tener configuraciones de persistencia diferentes (por ejemplo, source_ip para la capa 4 y cookie para la capa 7). En tal caso, la configuración de persistencia para ambos servidores virtuales debe ser la misma (source_ip, cookie o None) o una de ellas debe ser None (y la otra configuración puede ser source_ip o cookie). A continuación, se muestra un ejemplo de este escenario:


kind: Ingress

metadata:

name: cafe-ingress

spec:

rules:

- host: cafe.example.com

http:

paths:

- path: /tea

backend:

serviceName: tea-svc

servicePort: 80

-----

apiVersion: v1

kind: Service

metadata:

name: tea-svc <==== same as the Ingress backend above

labels:

app: tea

spec:

ports:

- port: 80

targetPort: 80

protocol: TCP

name: tcp

selector:

app: tea

type: LoadBalancer

Ingress

NCP will create one layer 7 load balancer for Ingresses with TLS specification, and one layer 7 load balancer for Ingresses without TLS specification. You can also create CRDs (CustomResourceDefinitions) to handle Ingress scaling.


VMware, Inc. 71

https://kubernetes.io/docs/concepts/services-networking/service

Note the following:

n All Ingresses will get a single IP address.

n The Ingress resource is allocated an IP address from the external IP pool specified by the external_ip_pools option in the [nsx_v3] section in ncp.ini. The load balancer is exposed on this IP address and the HTTP and HTTPS ports (80 and 443).

n The Ingress resource is allocated an IP address from the external IP pool specified by the external_ip_pools_lb option in the [nsx_v3] section in ncp.ini. If the external_ip_pools_lb option does not exist, the pool specified by external_ip_pools is used. The load balancer is exposed on this IP address and the HTTP and HTTPS ports (80 and 443).

n You can change to a different IP pool by changing the configuration and restarting NCP.

n You can specify a default certificate for TLS. See below for information about generating a certificate and mounting a certificate into the NCP pod.

n Ingresses without TLS specification will be hosted on HTTP virtual server (port 80).

n Ingresses with TLS specification will be hosted on HTTPS virtual server (port 443). The load balancer will act as an SSL server and terminate the client SSL connection.

n Modification of Ingress by adding or removing the TLS section is supported. When the tls key is removed from the Ingress specification, the Ingress rules will be transferred from the HTTPS virtual server (port 443) to the HTTP virtual server (port 80). Similarly, when the tls key is added to Ingress specification, the Ingress rules are transferred from the HTTP virtual server (port 80) to the HTTPS virtual server (port 443).

n If there are duplicate rules in Ingress definitions for a single cluster, only the first rule will be applied. The other Ingresses with the duplicate rules will be annotated with error. For example, if you create two Ingresses with the same host and path, and one Ingress is TLS while and the other is non-TLS, and kubernetes.io/ingress.allow-http is false, the two rules will be created on different virtual servers and will not conflict with each other. However, if kubernetes.io/ingress.allow-http is true, the Ingress that is applied later will be annotated with an error. See the "Errors" section below for more information.

n Only a single Ingress with a default backend is supported per cluster. Traffic not matching any Ingress rule will be forwarded to the default backend.

n If there are multiple Ingresses with a default backend, only the first one will be configured. The others will be annotated with an error. See the "Errors" section below for more information.

n (NCP 3.0.0 and 3.0.1) The rules are applied in the following order:

a Rules with both host and path specified, and without regular expression matching.

b Rules with both host and path specified, and with regular expression matching (with the longest Ingress path first).

c Rules with host or path specified, and without regular expression matching.


VMware, Inc. 72

d Rules with host or path specified, and with regular expression matching (with the longest Ingress path first).

n (NCP 3.0.2 and later) The rules are applied in the following order:

a Rules with both host and path specified.

1 Rules with the Exact pathType.

2 Rules with the Prefix pathType.

3 Rules with the Regex pathType.

b Rules with host or path specified.

1 Rules with the Exact pathType.

2 Rules with the Prefix pathType.

3 Rules with the Regex pathType.

Note: If multiple paths match a request, precedence will be given to the longest matching path.

About pathType:

n ImplementationSpecific is treated the same as Exact.

n Two matching paths with different pathTypes can co-exist.

n For the Prefix type, /foo will match /foo/, /foo/bar but not /foo or /foobar. To match /foo, add the Exact path /foo to the Ingress rule.

n (This is applicable if you use Policy mode.) If a TLS Ingress is created with a default backend, it is recommended that you set up the default backend to respond to both HTTP and HTTPS requests because:

n The load balancer will terminate TLS and send HTTP requests to the default backend server if there is a TLS Ingress (in the cluster for the Kubernetes/PKS use case, or in the same namespace for the Project Pacific use case) with host which matches the host in the request.

n The load balancer will re-encrypt and send HTTPS request to the backend server if there is no TLS Ingress (in the cluster for the Kubernetes/PKS use case, or in the same namespace for the Project Pacific use case) with host which matches the host in the request.

n The IngressClass resource is not supported.

n (NCP 3.0.0 and 3.0.1) The pathType attribute is not supported.

n (NCP 3.0.2 and later) The pathType attribute is supported.

n (NCP 3.0.2 and later) JWT (JSON Web Token) client authentication is supported. This feature requires NSX-T Data Center 3.0.0 or later.


VMware, Inc. 73

Feature Annotations

The following table lists annotations that NCP supports:

Annotation Description Supported Values Default Value NCP Version

kubernetes.io/ingress.allow-http

Enables HTTP requests in addition to HTTPS

true, false true 2.5 and later

ncp/use-regex Enables path pattern matching

true, false false 2.5.1 and later

ingress.kubernetes.io/rewrite-target

Rewrites path of incoming request

n (NCP 2.5 and later) Path starting with ‘/’

n (NCP 2.5.1 and later, and NSX-T 2.5.1 and later) Path with a numbered placeholder for a group captured in a regular expression, for example, /$1

No default value See the Supported Values column

ncp/http-redirect Redirects HTTP requests to HTTPS

true, false false 2.5.1 and later

kubernetes.io/ingress.class

Indicates which Ingress controller is responsible for this Ingress

nsx, nginx, etc. nsx 2.5 and later

nsx/loadbalancer Places an Ingress on a dedicated load balancer

Name of a LoadBalancer CRD

No default value 2.5.1 and later

ncp/whitelist-source-range

Limits Ingress access by request source IP

Comma-separated list of CIDRs, IP addresses, or IP ranges.


ncp/ssl-mode Selects SSL mode for all the rules in an Ingress

offload, reencrypt, passthrough

offload 3.0.1 and later

ncp/jwt-alg Determines the algorithm to be used to validate JWT signature. Enables JWT client authentication when set with ncp/jwt-secret.

HS256, RS256 No default value 3.0.2 and later


VMware, Inc. 74

Annotation Description Supported Values Default Value NCP Version

ncp/jwt-secret Specifies the name of the Kubernetes secret that contains the JWT secret or public key used for signature validation. Enables JWT client authentication when set with ncp/jwt-alg.

Name of a Kubernetes secret


ncp/jwt-token Additional location to search for JWT in the HTTP request.

_arg_<param_name>, _cookie_<cookie_name>


ncp/jwt-realm Specifies the Realm header returned with 401 when authentication failed.

String indicating the realm

Hostname of the ingress rule

3.0.2 and later

ncp/jwt-preserve Option to keep JWT and pass to backend after successful authentication.

true, false true 3.0.2 and later

Details about the annotations:

n Path Regex (Regular Expression) Matching

n For NCP 2.5.0 and earlier

In NCP 2.5.0 and earlier, all sub-path matching is automatically enabled using the regular expression characters '.' and '*'. For example, the path /coffee/.* matches /coffee/ followed by zero, one or more characters, such as /coffee/, /coffee/a, and /coffee/b, but not /coffee, /coffeecup or /coffeecup/a.

An Ingress specification example:

kind: Ingress

metadata:

name: cafe-ingress

spec:

rules:

- http:

paths:

- path: /coffee/.* #Matches /coffee/, /coffee/a but NOT /coffee, /coffeecup, etc.

backend:

serviceName: coffee-svc

servicePort: 80

n For NCP 2.5.1 and later


VMware, Inc. 75

You can enable or disable regular expression matching of the Ingress path (but not host) parameter using the annotation ncp/use-regex. If set to false, exact path matching will be performed by doing the equals match. If set to true, regular expression matching will be performed by adding the start of string character (^) and end of string character ($) to the path so that the entire request URI matches the pattern. Note that when using the OR operator (|), always specify the scope with parentheses so that ^ and $ apply to all the operands. For example, path: /(tea|coffee|milk). An Ingress specification example:

kind: Ingress

metadata:

name: cafe-ingress

annotations:

kubernetes.io/ingress.class: "nsx"

ncp/use-regex: "true"

spec:

rules:


http:

paths:

- path: /tea/.*

backend:


servicePort: 80

n Updating Ingresses prior to upgrading NCP to 2.5.1 or later

This is required only if you have Ingresses requiring all sub-path matching using the characters '.' and '*'.

1 Update the Ingresses to include the annotation ncp/use-regex: true.

2 For all sub-path matching, if you have paths such as /coffee/* or /*, change them to /coffee/.* and /.*.

/coffee/.* will match /coffee/, /coffee/a, /coffee/b, /coffee/a/b, and so on. /.* will match /coffee, /tea, /coffee/a, and so on. Omitting the path will produce the same behavior as path: /.*.

n Example of the annotation ingress.kubernetes.io/rewrite-target:

kind: Ingress

metadata:

name: cafe-ingress

annotations:

ingress.kubernetes.io/rewrite-target: /

spec:

rules:


http:

paths:

- path: /tea

backend:



VMware, Inc. 76

servicePort: 80

- path: /coffee

backend:


servicePort: 80

The paths /tea and /coffee will be rewritten to / before the URL is sent to the backend service.

Starting with NCP 2.5.1 and NSX-T 2.5.1, if path is specified using a regular expression, the captured groups are saved in numbered placeholders in the form $1, $2, and so on. These placeholders can be used as parameters in the ingress.kubernetes.io/rewrite-target annotation. Named capture groups and named placeholders are not supported. For example,

kind: Ingress

metadata:

name: cafe-ingress

annotations:


ncp/use-regex: "true"

#/tea/cup will be rewritten to /cup before sending request to endpoint

ingress.kubernetes.io/rewrite-target: /$1

spec:

rules:


http:

paths:

- path: /tea/(.*)

backend:


servicePort: 80

n About the annotation kubernetes.io/ingress.allow-http:

n If the annotation is set to false, rules will be created for the HTTPS virtual server.

n If the annotation is set to true or missing, rules will created for both HTTP and HTTPS virtual servers. Note that HTTPS rules will be created only if the TLS section is present in the Ingress specification.

n About the annotation ncp/http-redirect:

n If the annotation is set to false, Incoming HTTP traffic (port 80) to HTTP Virtual Server will not be redirected to HTTPS Virtual Server.

n If the annotation is set to true, Incoming HTTP traffic (port 80) to HTTP Virtual Server will be redirected to HTTPS Virtual Server (port 443).

This annotation is only valid if the TLS section is present. This annotation takes precedence over kubernetes.io/ingress.allow-http. When set to true, it will direct matched HTTP traffic to HTTPS, regardless of how kubernetes.io/ingress.allow-http is set.


VMware, Inc. 77

n About the annotation kubernetes.io/ingress.class:

n If the value is nsx, this ingress will be handled by NCP. If any other value is specified, the Ingress will be ignored by NCP. For more info see Controladores de entrada de terceros.

n For more information about the annotation nsx/loadbalancer, see LoadBalancer CRDs to Handle Ingress Scaling.

n About the annotation ncp/whitelist-source-range:

n When set, an incoming request will only be accepted if its source IP is included in this annotation. Otherwise, traffic will be dropped.

n You can specify a combination of CIDR, IP addresses, and IP ranges. For example, 1.1.1.1/24, 2.2.2.2, 3.3.3.3-4.4.4.4.

n Example YAML:

kind: Ingress

metadata:

name: cafe-ingress

annotations:


ncp/whitelist-source-range: "192.168.128.0/17, 192.168.64.0-192.168.64.255, 192.168.16.32"

spec:

tls:

- hosts:

- cafe.example.com

rules:


http:

paths:

- path: /tea

backend:


servicePort: 80

n About the annotation ncp/ssl-mode:

n This annotation applies to all the rules in an Ingress and the load balancer will operate in the selected SSL mode for these rules.

Note: If ncp/ssl-mode is set to reencrypt or passthrough, kubernetes.io/ingress.allow-http must be set to False. This annnotation cannot be set to passthrough if the ingress.kubernetes.io/rewrite-target, ncp/use-regex or ncp/whitelist-source-range annotation is set.

n About JWT client authentication:

n To enable JWT client authentication for all rules under an Ingress, both ncp/jwt-alg and ncp/jwt-secret need to be set to a valid value. When enabled, incoming HTTP traffic will only be passed to the backend if bearing valid JSON web token. Otherwise, traffic will be rejected with the 401 status.


VMware, Inc. 78

n This feature is incompatible with the following annotations:

n kubernetes.io/ingress.allow-http: true

n ncp/http-redirect: true

n ncp/ssl-mode: passthrough

n ncp/jwt-alg:

n Supported symmetrical algorithms: HS256

n Supported asymmetrical algorithms: RS256

n ncp/jwt-secret:

n A symmetrical key or public certificate must be configured in a Kubernetes secret with the name specified in this annotation under the same namespace as the Ingress.

n For symmetrical algorithms, the secret must be stored in the jwt.key field.

n For asymmetrical algorithms, the public cert must be stored in the tls.crt field.

n JWT client authentication will be disabled if the symmetrical secret or public certificate is not stored in the locations mentioned above, or if the data stored in the secret is invalid.

n ncp/jwt-token:

n Only one item can be configured in this annotation.

n _arg_<param_name>: For JWT passed in as a URI parameter. Specify the parameter name that contains JWT.

n _cookie_<cookie_name>: For JWT passed in as a cookie. Specify the cookie name that contains JWT.

Errors

Errors are annotated to the Ingress resource. The error key is ncp/error.loadbalancer and the warning key is ncp/warning.loadbalancer. The possible error and warning are:

n ncp/error.loadbalancer: DEFAULT_BACKEND_IN_USE

This error indicates that an Ingress with a default backend already exists. The Ingress will be inactive. This error will occur if (1) this Ingress is for HTTP and another Ingress for HTTP with a default backend exists; (2) this Ingress is for HTTPS and another Ingress for HTTPS with a default backend exists; or (3) this Ingress is for HTTP and HTTPS and another Ingress for HTTP and HTTPS with a default backend exists. To fix the error, delete and recreate the Ingress with a correct specification.

n ncp/warning.loadbalancer: SECRET_NOT_FOUND


VMware, Inc. 79

This error indicates that the secret specified in the Ingress specification does not exist, or if ncp/jwt-alg and ncp/jwt-secret are anootated but the secret cannot be found under the same namespace as the Ingress. The Ingress will be partially active. To fix the error, create the missing secret. Note that once a warning is in the annotation, it will not be cleared during the life cycle of the Ingress resource.

n ncp/warning.loadbalancer: INVALID_INGRESS

This error indicates that one of the following conditions is true. The Ingress will be inactive. To fix the error, delete and recreate the Ingress with a correct specification.

n An Ingress rule conflicts with another Ingress rule in the same Kubernetes cluster. Conflicts are determined only for Ingresses with the same match strategy, that is, the same ncp/use-regex annotation value.

n The kubernetes.io/ingress.allow-http annotation is set to false and the Ingress does not have a TLS section.

n The ncp/http-redirect annotation is set to true and the Ingress does not have a TLS section.

n An Ingress rule does not have host and path specified. Such an Ingress rule has the same functionality as the Ingress default backend. Use the Ingress default backend instead.

n The Ingress has JWL annotations that cannot be correctly processed. For example:

n Either ncp/jwt-alg or ncp/jwt-secret is missing.

n ncp/jwt-alg is configured with an unsupported algorithm.

n ncp/jwt-alg and ncp/jwt-secret are configured with other HTTP enabling annotations, or with ssl passthrough.

LoadBalancer CRDs to Handle Ingress Scaling

You can create CRDs (CustomResourceDefinitions) to monitor the usage of NSX load balancers and to create additional NSX layer 7 load balancers to handle Ingress workloads that the default load balancer cannot handle. These CRDs are not for scaling layer 4 load balancers that are created for Kubernetes LoadBalancer services.

In Manager mode, this feature is supported starting with NCP 2.5.1. In Policy mode, this feature is supported starting with NCP 3.0.1.

The CRDs are:

n NSXLoadBalancerMonitor - This CRD is used to report usage statistics of the NSX load balancers. In Policy mode, this CRD will only monitor namespace load balancers created using the LoadBalancer CRD.

n LoadBalancer - This CRD is used to create new NSX load balancers. The definition of this resource is in the NCP YAML file. In Policy mode and PKS deployments, this is a namespace resource. In Manager mode deployments, this is a clusterwide resource.


VMware, Inc. 80

In Manager mode, perform the following steps to enable this feature:

n Set the enable_lb_crd option in the k8s section to True.

n Apply the NCP YAML file with the following command:

kubectl apply -f ncp-<platform>.yaml

In Policy mode, perform the following steps to enable this feature:

n If you upgraded NCP from a previous version to 3.0.1, delete the old CRD definitions with the following commands:

kubectl delete crd nsxlbmonitors.vmware.com

kubectl delete crd loadbalancers.vmware.com

n Set the enable_lb_crd and enable_vnet_crd options in the k8s section to True.

n Apply the Policy version of the NCP YAML file with the following command:

kubectl apply -f ncp-<platform>-policy.yaml

In Manager mode, to create a new NSX load balancer, apply a YAML file that defines a LoadBalancer CRD. For example,

apiVersion: vmware.com/v1alpha1

kind: LoadBalancer

metadata:

name: cluster1-lbs0

spec:

httpConfig: {}

In Policy mode, LoadBalancer needs to be created with VirtualNetwork. For example,


kind: VirtualNetwork

metadata:

name: vnet

---


kind: LoadBalancer

metadata:

name: cluster1-lbs0

spec:

virtualNetworkName: vnet # Set to match VirtualNetwork object name

httpConfig: {}

This YAML file will create an NSX load balancer of small size, and a pair of layer 7 virtual servers without persistence, SSL or X-forward settings. The IP of the virtual server is allocated from the configured default external pool for load balancers. The ports by default are 80 and 443. Non-standard ports are supported if the custom port is included in the HTTP HOST header. Note that custom ports are only supported in non-TLS Ingresses.


VMware, Inc. 81

To check the creation status of the LoadBalancer CRD, run the following command:

kubectl get lb <name of the LoadBalancer> -o yaml

The result looks something like the following:

status:

conditions:

- status: "True"

type: Ready

httpVirtualIP: <realized virtual IP>

This result indicates that the creation was successful. If the creation failed, status will be "False" and there will not be a virtual IP.

You can also customize settings for the NSX load balancer and virtual servers. To configure the IP and port for the virtual server:

spec:

httpConfig:

virtualIP: <ip address, default to auto-allocate>

port: <port number, default to 80>

To specify the session affinity and X-forwarded-mode:

spec:

httpConfig:

xForwardedFor: <INSERT or REPLACE, default to None>

affinity:

type: <source_ip or cookie, default to None>

timeout: <timeout number, default to 10800>

To configure TLS settings:

spec:

httpConfig:

tls:

port: <tls port number, default to 443>

secretName: <name of secret, default to None>

secretNamespace: <namespace of secret, default to None>

Note that even if you set the HTTP and HTTPS ports to non-default values, the Ingress printer will always display the default port values (80 and 443) when showing the Ingress status because of a Kubernetes limitation. You should still use the configured ports to access Ingress. For example,

curl -I -HHost:tea.example.com http://$INGRESS_IP:$CRD_LB_HTTP_PORT/tea


VMware, Inc. 82

You can create the secret before or after the creation of LoadBalancer. To update the certificate, remove the secretName and secretNamespace from the LoadBalancer spec first, update the data of the secret, then re-attach the same secret using the above configuration. Creating a new secret and updating the secretName and secretNamespace will also work. Note that sharing the same secret data between different CRD load balancers is not supported. You must configure CRD load balancers with different certificates.

To view the status and statistics of NSX load balancers, run the following command:

kubectl get lbm

This will list all the NSXLoadBlancerMonitors, one for each NSX load balancer. The following information is displayed:

n Usage - The number of workloads on the NSX load balancer.

n Traffic - The aggregated statistics of each Virtual Server.

n Health - This field has two dimensions:

n servicePressureIndex - This indicates the performance of the load balancer. Two values are provided: score and severity.

n infraPressureIndex - This indicates the performance of the underlying infrastructure components. In NCP 2.5.1, this value is not always accurate.

n The field metrics gives an idea of the parameters that are considered when the health score is calculated.

When the servicePressureIndex of a load balancer is HIGH, you can migrate the Ingress workload to other load balancers, which must be the default load balancer or load balancers created using the LoadBalancer CRD.

To place an Ingress on a dedicated load balancer, add an annotation to the Ingress specification. For example,

annotations:

nsx/loadbalancer: <name of the LoadBalancer CRD>

If the annotation is missing or set to null, the Ingress is placed on the default NSX load balancer.

Servicio de tipo LoadBalancer

NCP creará un grupo y un servidor virtual del equilibrador de carga de Capa 4 para cada puerto de servicio.

Información sobre esta función:

n Se admiten los protocolos TCP y UDP.

n Cada servicio tendrá una dirección IP exclusiva.


VMware, Inc. 83

n Al servicio se le asigna una dirección IP de un grupo de direcciones IP externas según el campo loadBalancerIP de la definición del equilibrador de carga. El campo loadBalancerIP puede estar vacío, tener una dirección IP o el nombre o identificador de un grupo de direcciones IP. Si el campo loadBalancerIP está vacío, se asignará la dirección IP del grupo de direcciones IP externas especificada en la opción external_ip_pools_lb de la sección [nsx_v3] de ncp.ini. Si la opción external_ip_pools_lb no existe, se utiliza el grupo que external_ip_pools especifica. El servicio de equilibrador de carga se expone en esta dirección IP y en el puerto del servicio.

n Puede utilizar otro grupo de direcciones IP cambiando la configuración y reiniciando NCP.

n El grupo de direcciones IP especificado por loadBalancerIP debe tener la etiqueta scope: ncp/owner, tag: cluster:<cluster_name>.

n A partir de NCP 3.0.2, en el modo Directiva, se admite un servicio de tipo LoadBalancer sin un selector. Para este tipo de servicio, la dirección IP de SNAT del equilibrador de carga de NSX-T será la IP del servicio de tipo equilibrador de carga. La IP de SNAT del equilibrador de carga de NSX-T se actualizará si se actualiza la dirección IP del servicio de tipo equilibrador de carga.

n Se anota un error en un servicio. La clave de error es ncp/error.loadbalancer. Los posibles errores son:

n ncp/error.loadbalancer: IP_POOL_NOT_FOUND

Este error indica que especifica loadBalancerIP: <nsx-ip-pool>, pero <nsx-ip-pool> no existe. El servicio estará inactivo. Para solucionar el error, especifique un grupo de direcciones IP válido, y elimine y vuelva a crear el servicio.

n ncp/error.loadbalancer: IP_POOL_EXHAUSTED

Este error indica que especifica loadBalancerIP: <nsx-ip-pool>, pero el grupo de direcciones IP ya agotó las direcciones IP. El servicio estará inactivo. Para solucionar el error, especifique un grupo de direcciones IP que tenga direcciones IP disponibles, y elimine y vuelva a crear el servicio.

n ncp/error.loadbalancer: IP_POOL_NOT_UNIQUE

Este error indica que varios grupos de direcciones IP tienen el nombre que loadBalancerIP especifica: <nsx-ip-pool>. El servicio estará inactivo.

n ncp/error.loadbalancer: POOL_ACCESS_DENIED

Este error indica que el grupo de direcciones IP que loadBalancerIP especifica no tiene la etiqueta scope: ncp/owner, tag: cluster:<cluster_name> o que el clúster especificado en la etiqueta no coincide con el nombre del clúster de Kubernetes.

n ncp/error.loadbalancer: LB_VIP_CONFLICT

Este error indica que la dirección IP especificada en el campo loadBalancerIP es la misma que la dirección IP de un servicio activo. El servicio estará inactivo.


VMware, Inc. 84

n El equilibrador de carga de capa 4 admite la escala automática. Si se crea o se modifica un servicio de equilibrador de carga de Kubernetes de manera que requiera servidores virtuales adicionales y el equilibrador de carga de capa 4 existente no tiene la capacidad, se creará un nuevo equilibrador de carga de capa 4. NCP también eliminará un equilibrador de carga de capa 4 que ya no tenga servidores virtuales asociados. Esta función está habilitada de forma predeterminada. Si desea deshabilitar esta función, deberá establecer el valor false para l4_lb_auto_scaling en el ConfigMap de NCP.

Equilibrador de carga y directiva de red

Cuando el tráfico se reenvía a los pods desde el servidor virtual del equilibrador de carga de NSX, la IP de origen es la dirección IP del puerto de enlace ascendente del enrutador de nivel 1. Esta dirección se encuentra en la red de tránsito privada de nivel 1. Puede provocar que las directivas de red basadas en CIDR impidan el tráfico que se debería permitir.

Para evitar este problema, la directiva de red debe configurarse de manera que la dirección IP del puerto de enlace ascendente del enrutador de nivel 1 sea parte del bloque de CIDR permitido. Esta dirección IP interna estará visible en el campo status.loadbalancer.ingress.ip y como una anotación (ncp/internal_ip_for_policy) en el recurso de entrada.

Por ejemplo, si la dirección IP externa del servidor virtual es 4.4.0.5 y la dirección IP del puerto de enlace ascendente del enrutador de nivel 1 interno es 100.64.224.11, el estado será:

status:

loadBalancer:

ingress:

- ip: 4.4.0.5

- ip: 100.64.224.11

La anotación de la entrada y el servicio del tipo de recurso del equilibrador de carga será:

ncp/internal_ip_for_policy: 100.64.224.11

La dirección IP 100.64.224.11 debe pertenecer al CIDR permitido en el selector de ipBlock de la directiva de red. Por ejemplo,

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

...

ingress:

- from:

- ipBlock:

cidr: 100.64.224.11/32


VMware, Inc. 85

Script de ejemplo para generar un certificado firmado por CA

Puede crear un script para generar un certificado firmado por CA y una clave privada que se almacenan en los archivos <nombredearchivo>.crt y <nombredearchivo>.key respectivamente.

El comando genrsa genera una clave de CA. La clave de CA debe estar cifrada. Puede especificar un método de cifrado con un comando, como aes256. Por ejemplo,

#!/bin/bash

host="www.example.com"

filename=server

openssl genrsa -out ca.key 4096

openssl req -key ca.key -new -x509 -days 365 -sha256 -extensions v3_ca -out ca.crt -subj "/C=US/ST=CA/

L=Palo Alto/O=OS3/OU=Eng/CN=${host}"

openssl req -out ${filename}.csr -new -newkey rsa:2048 -nodes -keyout ${filename}.key -subj "/C=US/

ST=CA/L=Palo Alto/O=OS3/OU=Eng/CN=${host}"

openssl x509 -req -days 360 -in ${filename}.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out $

{filename}.crt -sha256

Controladores de entrada de terceros

Puede configurar NCP para que admita controladores de entrada de terceros.

Editar el archivo ncp.ini

Debe editar el archivo de configuración /var/vcap/data/jobs/ncp/xxxxxxxx/config/ncp.ini (xxxxxxxx es el identificador de implementación de BOSH). Este archivo se copiará en rootfs y NCP lo usará cada vez que se reinicie. El archivo se debe editar en cada nodo principal.

Importante Los cambios en ncp.ini no se mantienen en las actualizaciones del clúster de PKS. Si realiza cambios a través del mosaico de PKS y, a continuación, actualiza la implementación de PKS, se perderán los cambios en ncp.ini.

Las opciones correspondientes se encuentran en la sección nsx_v3.

n use_native_loadbalancer - Si se establece como False, NCP no procesará ninguna entrada ni servicio del tipo actualizaciones de LoadBalancer, independientemente de sus anotaciones. Este ajuste se aplica a todo el clúster de PKS. El valor predeterminado es True.

n default_ingress_class_nsx - Si se establece como True, NCP se convertirá en el controlador de entrada predeterminado y controlará tanto las entradas anotadas con kubernetes.io/ingress.class: "nsx" como las entradas sin ninguna anotación. Si se establece como False, NCP solo controlará las entradas anotadas con kubernetes.io/ingress.class: "nsx". El valor predeterminado es True.


VMware, Inc. 86

Si desea que NCP asigne una dirección IP flotante al pod del controlador NGINX y actualice el estado de las entradas con dicha IP flotante, haga lo siguiente:

n En la sección k8s de ncp.ini, establezca el valor ingress_mode=nat.

n Agregue la anotación ncp/ingress-controller: "True" al pod del controlador de entrada NGINX.

NCP actualizará el estado de las entradas que incluyan la anotación kubernetes.io/ingress.class: "nginx" con la IP flotante del pod del controlador de entrada NGINX. Si default_ingress_class_nsx=False, NCP también actualizará el estado de los ingresos sin la anotación kubernetes.io/ingress.class con la IP flotante del pod del controlador de entrada NGINX.

Nota: Aunque el pod del controlador de entrada NGINX no incluya la anotación ncp/ingress-controller: "True", NCP actualizará el estado de las entradas mencionadas anteriormente a loadBalancer: {}. A continuación, las entradas pueden quedar bloqueadas en un bucle en el que el controlador NGINX actualiza el estado de las entradas a loadBalancer: {ingress: [{ip: <IP>}]} y NCP lo actualiza a loadBalancer: {}. Para resolver este problema, siga estos pasos:

n Si el controlador de entrada es de https://github.com/kubernetes/ingress-nginx:

n En el controlador de entrada, cambie el valor de ingress-class por uno que no sea "nginx".

n Si hay una entrada con la anotación kubernetes.io/ingress-class: "nginx", cámbiela a un valor diferente.

n Para obtener más información, consulte https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress.

n Si el controlador de entrada es de https://github.com/nginxinc/kubernetes-ingress:

n En el controlador de entrada, cambie el valor de ingress-class por uno que no sea "nginx".

n Si hay una entrada con la anotación kubernetes.io/ingress-class: "nginx", cámbiela a un valor diferente.

n En el pod del controlador de entrada, establezca use-ingress-class-only como True. Esto evitará que este controlador actualice las entradas sin la anotación kubernetes.io/ingress-class.

n Para obtener más información, consulte https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/multiple-ingress-controllers.md.

Para los controladores de entrada de terceros implementados en modo NAT, puede modificar los parámetros http_ingress_port y https_ingress_port en la sección k8s para especificar puertos personalizados para las reglas NAT que se exponen para la controladora de entrada.


VMware, Inc. 87

https://github.com/kubernetes/ingress-nginx

https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress

https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress

https://github.com/nginxinc/kubernetes-ingress

https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/multiple-ingress-controllers.md

https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/multiple-ingress-controllers.md

Escenario 1: NCP controla las entradas, pero no es el controlador de entrada predeterminado.

Siga este procedimiento para permitir que NCP controle las entradas de clase nsx.

1 Edite la sección nsx_v3 del archivo ncp.ini de cada nodo principal.

a Establezca default_ingress_class_nsx como False.

b Deje use_native_loadbalancer establecido como True, el valor predeterminado.

2 Reinicie NCP en cada nodo principal. Esto puede provocar una conmutación por error generalizada.

3 Anote todas las entradas que desea que controle NCP con kubernetes.io/ingress.class: "nsx".

Escenario 2: NCP es el controlador de entrada predeterminado.

Siga este procedimiento:

1 No es necesario editar ncp.ini, pero asegúrese de que todas las entradas estén anotadas.

2 Las entradas que gestionará NCP deben estar anotadas con kubernetes.io/ingress.class: "nsx".

Aunque NCP controlará las entradas sin la anotación kubernetes.io/ingress.class, en el caso de que haya varios controladores de entrada, se recomienda tener siempre la anotación kubernetes.io/ingress.class para no depender del comportamiento del controlador de entrada predeterminado.

3 Las entradas que se controlarán mediante controladores de entrada de terceros deben anotarse con el valor que requieran dichos controladores.

Importante A menos que desee que NGINX sea el controlador de entrada predeterminado, no utilice nginx como el controlador de entrada NGINX, ya que eso convertirá a NGINX en el controlador de entrada predeterminado.

Escenario 3: NCP no controla ninguna entrada, independientemente de su anotación.

Siga este procedimiento:

1 Edite la sección nsx_v3 del archivo ncp.ini de cada nodo principal.

a Establezca use_native_loadbalancer como False. El valor de default_ingress_class_nsx ahora es irrelevante.

2 Reinicie NCP en cada nodo principal. Esto puede provocar una conmutación por error generalizada.

Tenga en cuenta que NCP tampoco controlará los servicios del tipo LoadBalancer.


VMware, Inc. 88

Actualizar NCP 6Puede actualizar NCP desde la versión 2.4.* o 2.5.* hasta 3.0.x.


n Actualización de NCP en un entorno de Kubernetes

n Actualización de NCP en un entorno de Pivotal Cloud Foundry

Actualización de NCP en un entorno de Kubernetes

En esta sección se describe cómo actualizar NCP de la versión 2.5.* hasta 3.0.x en un entorno de Kubernetes.

1 Descargue los archivos de instalación. Consulte Descargar archivos de instalación.

2 Ejecute los siguientes comandos para ver el ConfigMap y el ncp.ini en el entorno actual:

kubectl describe configmap nsx-ncp-config -n nsx-system

kubectl describe configmap nsx-node-agent-config -n nsx-system

3 Edite el archivo YAML de NCP según su entorno actual. Como referencia, consulte Editar el archivo YAML de NCP.

n Debe definir ovs_uplink_port en la sección [nsx_node_agent].

n Reemplace todas las instancias de image: nsx-ncp del nuevo nombre de imagen de NCP.

n Si utiliza secretos de Kubernetes para almacenar certificados de NCP, consulte la sección "Actualizar las especificaciones de implementación de NCP" en Editar el archivo YAML de NCP sobre cómo montar los volúmenes secretos.

4 Ejecute el siguiente comando para comprobar la sintaxis del archivo YAML de NCP:

kubectl apply -f ncp-<platform_name>.yml --server-dry-run

La respuesta mostrará una lista de los recursos que se van a crear o a actualizar (que se muestran como "configurados" en la salida). Por ejemplo,

customresourcedefinition.apiextensions.k8s.io/nsxerrors.nsx.vmware.com created (server dry run)

customresourcedefinition.apiextensions.k8s.io/nsxlocks.nsx.vmware.com created (server dry run)

namespace/nsx-system unchanged (server dry run)

serviceaccount/ncp-svc-account unchanged (server dry run)

VMware, Inc. 89

clusterrole.rbac.authorization.k8s.io/ncp-cluster-role configured (server dry run)

clusterrole.rbac.authorization.k8s.io/ncp-patch-role configured (server dry run)

clusterrolebinding.rbac.authorization.k8s.io/ncp-cluster-role-binding unchanged (server dry run)

clusterrolebinding.rbac.authorization.k8s.io/ncp-patch-role-binding unchanged (server dry run)

serviceaccount/nsx-node-agent-svc-account unchanged (server dry run)

clusterrole.rbac.authorization.k8s.io/nsx-node-agent-cluster-role configured (server dry run)

clusterrolebinding.rbac.authorization.k8s.io/nsx-node-agent-cluster-role-binding unchanged

(server dry run)

configmap/nsx-ncp-config configured (server dry run)

deployment.extensions/nsx-ncp configured (server dry run)

configmap/nsx-node-agent-config configured (server dry run)

daemonset.extensions/nsx-ncp-bootstrap configured (server dry run)

daemonset.extensions/nsx-node-agent configured (server dry run)

5 Ejecute el siguiente comando para eliminar los recursos de NCP antiguos:

kubectl delete deployment nsx-ncp -n nsx-system

6 Ejecute el siguiente comando para comprobar si se han finalizado todos los pods de NCP anteriores:

kubectl get pods -l component=nsx-ncp -n nsx-system

No debe aparecer ningún pod si se finalizan todos los pods de NCP anteriores. Espere a que se terminen todos los pods antes de continuar.

7 Borre el bloqueo de la elección anterior. En la interfaz de usuario web de NSX Manager, vaya a la página de búsqueda y realice una búsqueda avanzada de recursos con las siguientes etiquetas:

Scope: ncp\/ha Tag: true

Scope: ncp\/cluster Tag: <name of the cluster in ncp.ini>

Debería ver uno o varios recursos SpoofGuard. Borre todas las etiquetas de estos recursos.

8 Ejecute el siguiente comando para iniciar la actualización:

kubectl apply -f ncp-{platform_name}.yml

9 Ejecute el siguiente comando para comprobar el estado de la actualización:

kubectl get pods -o wide -n nsx-system

El resultado debe mostrar nuevos pods creados y pods antiguos terminados. Una vez que la actualización se haya completado correctamente, todos los pods deben aparecer como En ejecución.


VMware, Inc. 90

Actualización de NCP en un entorno de Pivotal Cloud Foundry

Esta sección describe cómo actualizar NCP a la versión 3.0.x en un entorno de Pivotal Cloud Foundry.

Procedimiento

1 Actualice el mosaico NSX-T o NCP a la versión 3.0.x.

2 (opcional) Actualice Pivotal Operations Manager y, a continuación, actualice Pivotal Application Service.

3 (opcional) Actualice NSX-T Data Center a la versión 3.0.

Si el hipervisor es ESXi, actualícelo al menos a la versión 6.5p03 desde 6.5 o a la versión 6.7ep6 desde 6.7 antes de actualizar NSX-T Data Center.

4 (opcional) Actualice el hipervisor (KVM o contenedor sin sistema operativo).


VMware, Inc. 91

Importar objetos de Manager a Directiva 7NSX-T ofrece dos métodos de configuración de redes: el modo Manager y el modo Directiva. Si va a actualizar NCP, tiene la opción de importar objetos de Manager a Directiva. Puede usar el script mp_to_policy_importer.py, que permite importar objetos de Manager a Directiva.

Esta función es compatible si tiene un entorno Kubernetes, pero no un entorno Pivotal Cloud Foundry (PCF) o Pivotal Container Service (PKS).


n Flujo de trabajo de importar objetos de Manager a Directiva

n Importar recursos compartidos

n Importación de un clúster de Kubernetes

n Información sobre el proceso de importación

n Error y recuperación

n Recursos personalizados

n Limitaciones y soluciones alternativas

n Orden de especificación de recursos

n Ejemplo config.yaml

n Ejemplo user-spec.yaml

Flujo de trabajo de importar objetos de Manager a Directiva

La importación de un clúster de Kubernetes puede tardar algún tiempo y requiere el bloqueo del clúster (no se permiten operaciones de creación, actualización ni eliminación). Se recomienda importar un clúster cada vez para no tener que bloquear todos los clústeres.

Antes de iniciar el proceso de importación, debe realizar una copia de seguridad de NSX Manager. Esto garantiza que, si se produce un error irrecuperable, podrá restaurar NSX Manager a su estado antes de la importación.

El script de Python3 que realiza la importación, mp_to_policy_importer.py, se encuentra en el directorio scripts/mp_to_policy_import. Debe ejecutarlo en el nodo principal de Kubernetes que está ejecutando el clúster.

VMware, Inc. 92

Para conocer las limitaciones y las soluciones alternativas, consulte Limitaciones y soluciones alternativas. Para obtener información sobre solucionar problemas, consulte Error y recuperación.

El flujo de trabajo para importar objetos de Manager a Directiva:

1 Actualice NSX-T a la versión 3.0.0 o una posterior.

2 Actualice NCP a la versión 3.0.1.

3 En el archivo YAML de NCP, asegúrese de que policy_nsxapi esté establecido en false.

4 Cree una copia de seguridad.

5 Importe los recursos compartidos. Consulte Importar recursos compartidos.

6 Bloquee el clúster de Kubernetes. El servidor de la API de Kubernetes estará en modo de solo lectura. No realice operaciones de creación, actualización o eliminación en los recursos de Kubernetes. Espere al menos 10 minutos antes de continuar con el siguiente paso.

7 Detenga NCP.

8 Cree una copia de seguridad.

9 Importe el clúster de Kubernetes. Consulte Importación de un clúster de Kubernetes.

10 Actualice ncp.ini si es necesario para este clúster. Consulte Importar recursos compartidos.

11 En el archivo YAML de NCP, asegúrese de que policy_nsxapi esté establecido en true e inicie NCP.

12 Desbloquee el clúster. Ahora puede realizar operaciones de creación, actualización o eliminación en los recursos de Kubernetes.

13 Repita los pasos del 4 al 12 para el siguiente clúster.

14 Cambie PKS Automation y BOSH CPI para usar la API de Directiva una vez que se importen todos los clústeres de la implementación.

Importar recursos compartidos

El primer paso en el proceso de importación de Manager a Directiva es importar recursos compartidos, como enrutadores, grupos y bloques de IP, NsGroups, etc.

NCP en modo Directiva solo acepta el identificador de Directiva de recursos de NSX en ncp.ini. Los recursos compartidos se importan a Directiva desde Manager con un identificador de Directiva derivado de sus nombres de la siguiente manera:

n Cada espacio (' ') literal se reemplaza por un carácter de subrayado ('_')

n Cada barra diagonal ('/') se reemplaza por el carácter de subrayado ('_')

n Si el nombre para mostrar solo tiene puntos (por ejemplo, '.', '.....', etc.), se antepone a un guion bajo ('_')


VMware, Inc. 93

Ejemplos:

n "mp display name" se convierte en el identificador de Directiva: "mp_display_name"

n "mp display/name" se convierte en el identificador de Directiva: "mp_display_name"

n "....." se convierte en el identificador de Directiva: "_....."

Debe asegurarse de que todos los recursos de NSX que se creen tengan nombres para mostrar únicos.

Si es necesario, actualice ncp.ini siguiendo las reglas anteriores cada vez que la configuración lea el identificador del recurso de NSX.

Editar user-spec.yaml

Debe editar user-spec.yaml para especificar los recursos que se importarán. Puede especificar:

n El recurso usando display_name o el identificador en la API de Manager. Si el recurso no se encuentra en la API de Manager, se omitirá.

n Las asignaciones de IP que se importarán para cualquier grupo de direcciones IP en la especificación user-spec.yaml en "ip-allocations". Dos escenarios:

a Con IpPoolAllocations personalizadas de este IpPool

Si creó algunas IpAllocations de forma manual, deberá especificarlas aquí. La clave es el allocation_id de la IpPoolAllocation y el valor es el identificador de Directiva esperado. No importe ningún otro recurso, como IpBlock, Tier0, etc. . Una vez que se importen, vuelva a ejecutar el script para importar shared_resources, pero según se especifica en el paso 2 a continuación.

b Sin IpPoolAllocations personalizada de este IpPool (valor predeterminado)

No edite ni especifique la asignación de direcciones IP en cualquier IpPool y agregue los demás recursos como IpBlock, Tier0, etc. en la especificación que se va a importar

n Puertos de enrutador y rutas estáticas que se importarán para un enrutador de nivel 1.

No cambie el identificador `key` y `value` en la especificación, sino solo los valores asignados. `key` es el identificador de Manager y `value` es el identificador de Directiva esperado.

Consulte Orden de especificación de recursos para ver cómo se deben especificar los recursos compartidos en user-spec.yaml.

Pasos para importar recursos compartidos

1 Rellene la información adecuada en config.yaml y establezca import_shared_resources_only en True. Consulte Ejemplo config.yaml.

2 Rellene la información de recursos compartidos en user-spec.yaml . Consulte Ejemplo user-spec.yaml.

3 Ejecute mp_to_policy_importer utilizando los argumentos de la línea de comandos o el archivo de configuración. Por ejemplo:


VMware, Inc. 94

python3 mp_to_policy_importer.py --config-file config.yaml

Importación de un clúster de Kubernetes

Después de importar los recursos compartidos, puede importar un clúster de Kubernetes.

Editar user-spec.yaml

En user-spec.yaml, especifique:

n El identificador del enrutador de nivel superior y el tipo de clúster

n Todos los recursos personalizados que se deben importar como parte de cualquier importación de recursos. Por ejemplo, puede especificar el identificador de Manager de una regla NAT que se debe importar como parte de los recursos de espacio de nombres. Consulte Recursos personalizados para obtener más información. No es necesario hacer nada aquí, a menos que haya creado manualmente algunos recursos en los recursos creados por NCP. Por ejemplo: agregó una ruta estática en un enrutador de nivel 1 creado por NCP.

n Identificador de Manager del lb-service creado como lb-service-mp-id para importar el lb-service que se utiliza de forma predeterminada en NCP si está configurado. Este es el mismo recurso que lb_service en la especificación de NCP (ncp.ini). Si no se utiliza, no es necesario especificarlo.

Pasos para importar un clúster de Kubernetes

1 Rellene la información adecuada en config.yaml y establezca import_shared_resources_only en False. Consulte Ejemplo config.yaml.

2 Rellene la información del clúster de Kubernetes en user-spec.yaml. Consulte Ejemplo user-spec.yaml.

3 Ejecute mp_to_policy_importer utilizando los argumentos de la línea de comandos o el archivo de configuración. Por ejemplo:

python3 mp_to_policy_importer.py --config-file config.yaml

Tenga en cuenta que solo se importará el clúster de Kubernetes especificado en config.yaml aunque se mencione en el archivo user-spec.yaml.

Información sobre el proceso de importación

El proceso de importación consta de cuatro fases.


VMware, Inc. 95

Fase 1

Recupere todos los recursos de la API de Manager. Filtre los recursos en función de la etiqueta de clúster de Kubernetes (npc/clúster) o los recursos compartidos especificados en user-spec.yaml. Comience a hacer que los cuerpos de solicitud se envíen al servidor de migración. Si no se puede generar ninguna solicitud, NCP no migrará el clúster y se cerrará.

Errores esperados y soluciones:

n No se pueden recuperar recursos de la API de Manager debido a un problema de conectividad

Solución: vuelva a intentarlo después de solucionar el problema de conectividad

n Kubernetes no contiene un recurso que se recupere desde la API de Manager

Solución: vuelva a ejecutar NCP en modo de Manager hasta que alcance un estado inactivo, es decir, que no vaya a realizar ninguna operación CRUD (creación, lectura, actualización y eliminación). Debe esperar al menos 10 minutos, ya que es el intervalo de tiempo máximo hasta que NCP envía solicitudes de reintento. Si no hay errores en los registros de NCP, se debe solucionar el problema.

Fase 2

Comience a enviar a la API de migración las solicitudes de importación creadas en la fase 1. Una vez que la solicitud se procese correctamente, registre los manager_id incluidos en la solicitud del disco local del cliente. Si se produce un error en alguna solicitud, revierta los recursos que ya se hayan importado utilizando los manager_id almacenados en el disco local. Si la API de migración indica que es una solicitud duplicada, el importador eliminará sus manager_id del cuerpo de la solicitud y volverá a enviar la solicitud.


n Problema de conectividad


n Error en la API de migración

Solución: vuelva a intentarlo después de un tiempo, ya que puede ser la API de Directiva en estado de error o la API de migración. Si el problema persiste, revierta todos los recursos importados si el importador se detiene de forma inesperada mediante la opción rollback_imported_resources en config.yaml. De forma predeterminada, el importador se revertirá si se produce algún problema en esta fase. Sin embargo, si se produce un problema durante la reversión, deberá volver a intentarlo manualmente. Si la reversión con mp_to_policy_importer no se realiza correctamente, deberá restaurar NSX Manager desde una copia de seguridad al estado que tenía antes de importar el clúster de Kubernetes.

Nota: si se importaron secciones y reglas de DFW y se produce un error en las solicitudes de importación de recursos después, deberá restaurar el estado de Manager con la copia de seguridad creada antes de volver a iniciar la importación del clúster.


VMware, Inc. 96

Fase 3

Deduzca las etiquetas que es necesario agregar o eliminar de los recursos en Directiva para todos los recursos importados. Si no se puede deducir ninguna etiqueta (el motivo podría ser que falta el recurso de Kubernetes correspondiente), el importador revertirá los recursos que ya se importaron mediante los manager_id almacenados en el disco local. Esto puede ocurrir cuando se detuvo NCP en el modo Manager en mitad de la transacción. Por lo tanto, deberá volver a iniciar NCP en modo Manager y esperar un poco.


n Kubernetes no contiene un recurso que se recupere desde la API de Manager

Solución: después de la reversión, ejecute de nuevo NCP en el modo Manager hasta que se alcance el estado inactivo. Debe esperar al menos 10 minutos, ya que es el intervalo de tiempo máximo hasta que NCP envía solicitudes de reintento. Si no hay errores en los registros de NCP, se debe solucionar el problema.

Fase 4

Esta es la fase más crucial. Es muy importante que no se produzca un error inesperado en esta fase. En esta fase, el importador actualizará los recursos en Directiva con nuevas etiquetas o información adicional (p. ej., el importador actualizará display_name de segmentos). Si el recurso no se puede actualizar en este momento, el importador almacenará el cuerpo del recurso de directiva actualizado y la URL del recurso de directiva en el disco local del cliente, y le pedirá que vuelva a intentarlo después de solucionar el problema (el problema se debe a la API de Directiva o a un problema de conectividad).


n Problema de conectividad


En las cuatro fases, también hay riesgo de errores de alimentación inesperados y otros problemas que se gestionan como se describe en Error y recuperación.

Error y recuperación

Es posible que el proceso de importación no pueda completar la importación debido a un problema externo, como un fallo de alimentación, un agotamiento del disco, un problema de conectividad, etc. En esos casos, existen formas de recuperación.

Si se producen errores en las fases 1, 2 o 3, puede establecer manualmente la opción rollback_imported_resources como True en config.yaml y volver a ejecutar el script. Esta acción revertirá todos los recursos importados. Si no establece la marca en True, NCP lo volverá a intentar y continuará la importación de recursos. De forma predeterminada, rollback_imported_resources es False.


VMware, Inc. 97

Si se produce un error en la fase 4, vuelva a ejecutar mp_to_policy_importer. NCP intentará insertar los cuerpos de recursos actualizados en la memoria caché en la NSX Manager. Si se produjo un error y la información no se almacenó en la memoria caché, deberá revertir mediante la función de copia de seguridad y restauración para restaurar el clúster. Esto se debe a que, una vez que se actualizan las etiquetas en Directiva y se revierten los recursos, se pierden todas las etiquetas.

Reversión de la importación de Manager a Directiva

El proceso de mp_to_policy_importer almacena el ID de los recursos en el disco local del cliente si se importan correctamente. Si se produce un error mientras el importador se está ejecutando, se revertirán inmediatamente todos los recursos importados y se eliminarán del sistema de archivos si la reversión se realizó correctamente. Sin embargo, si se produce un error durante la reversión, puede establecer rollback_imported_resources como True en config.yaml para volver a intentar revertir manualmente los recursos importados ejecutando otra vez mp_to_policy_importer. El importador indicará en los registros si todos los recursos se revirtieron correctamente. Si la reversión a través del script no se realiza correctamente, utilice la función de copia de seguridad y restauración para restaurar el clúster a su estado original.

Recursos personalizados

Puede importar recursos personalizados que no se importan de forma predeterminada cuando se importa un clúster.

NCP no crea los recursos personalizados. Hay métodos en el archivo nsxt_mp_to_policy_converter.py (busque la palabra "custom" en las definiciones de métodos), que se puede anular para implementar el comportamiento esperado durante la importación de Directiva a Manager. De forma predeterminada, NCP no realiza ninguna acción para estos recursos y, por lo tanto, no se implementa ningún comportamiento personalizado. Si especifica un identificador de recurso personalizado, se creará una solicitud simple para importarlo (el ID de Directiva se deducirá de display_name en este caso, no se realizarán actualizaciones en las fases 2 y 3). Puede especificar los identificadores de estos recursos en el archivo de especificaciones del usuario (consulte el siguiente ejemplo) usando el identificador custom_resources. A continuación se muestra la sintaxis:

k8s-clusters:

<k8s cluster name>:

<NSX Resource Shell Class Name>:

<NSX Resource - 1 Class Name>:

custom_resources:

<NSX Resource - 1A ID>:

metadata:

- "key": <metadata key recognized by Migration API>

"value": <metadata value associated with the key recognized by

Migration API>

linked_ids:

- "key": <linked_ids key recognized by Migration API>

"value": <linked_ids value associated with the key recognized by


VMware, Inc. 98

Migration API>

<NSX Resource - 2 Class Name>: # these resources are imported after NSX Resource - 1A is

custom_resources:

<NSX Resource - 2A ID>:

metadata:


"value": <metadata value associated with the key

recognized by Migration API>

linked_ids:


"value": <linked_ids value associated with the key

recognized by Migration API> <NSX Resource - 1 Class Name>:

<NSX Resource - 1B ID>:

metadata:


"value": <metadata value associated with the key recognized by

Migration API>

linked_ids:


"value": <linked_ids value associated with the key recognized by

Migration API>

Ejemplo para especificar recursos personalizados en user-spec.yaml

k8s-clusters:

k8scluster:

# top-tier-router-id is required for each cluster

top-tier-router-id: t1-router-id

top-tier-router-type: TIER1

# Provide custom resources as follow:

NamespaceResources:

Tier1Router:

custom_resources:

# Custom resources are specified only with MP ID

6d93a932-87ea-42de-a30c-b39f397322b0:

metadata:

# It should be a list

- key: 'metadata-key'

value: 'metadata-value'

linked_ids:


- key: 'linked_id-key'

value: 'linked_id-value'

NATRules:

custom_resources:


536870924:

metadata:




linked_ids:



VMware, Inc. 99



Consulte Orden de especificación de recursos para ver cómo se deben especificar los recursos personalizados en user-spec.yaml.

Limitaciones y soluciones alternativas

El proceso de importación tiene ciertas limitaciones. Algunas tienen soluciones alternativas.

n (Solo NCP 3.0.1) Las IpPoolAllocations de los IpPools externos (los IpPools creados por el usuario) no se eliminan una vez que NCP se ejecuta en el modo Directiva después de la importación. Por ejemplo, al eliminar un espacio de nombres.

Solución alternativa: ninguna

n El importador de Manager a Directiva no se puede revertir completamente una vez que las reglas y las secciones del firewall distribuido se importan en la fase 2.

Solución alternativa: debe utilizar la función de copia de seguridad y restauración en este caso para restaurar el clúster a su configuración original en Manager.

n (Solo NCP 3.0.1) Se produce un error al importar de Manager a Directiva si hay una regla NAT con varios puertos de destino. Uno de estos casos es cuando ingress_mode de Kubernetes es nat y existe un pod con la anotación ncp/ingress-controller.

Solución alternativa: cuando NCP no se está ejecutando y antes de iniciar la importación, edite la regla NAT y quite los puertos de destino "80" y "443".

n (Solo NCP 3.0.1) No se pueden eliminar los niveles 1 de equilibrador de carga de escalado automáticamente si se requiere NCP en modo Directiva después de la importación.

Solución alternativa: elimine manualmente el nivel 1 de la interfaz de usuario si es necesario.

n Los clústeres con el CRD del equilibrador de carga no se pueden importar. El CRD del equilibrador de carga tiene una especificación diferente en los modos Manager y Directiva, y no se puede transformar. Por lo tanto, no debe haber ningún CRD del LB presente en Kubernetes antes de iniciar la importación.

Solución alternativa: Ninguna

Orden de especificación de recursos

A continuación se muestra la lista de nombres de recursos para especificar recursos compartidos y personalizados en user-spec.yaml.

SharedResources

- IpBlock

- IpPool

- IpPoolAllocation (specified as ip-allocations; see the sample user-spec.yaml for an example)

- Tier0Router

- Tier0RouterPorts (cannot be specified in user-spec.yaml)


VMware, Inc. 100

- Tier0RouterConfig (cannot be specified in user-spec.yaml)

- Tier1Router

- Tier1RouterPortsAndStaticRoutes

- SpoofguradProfile

- NodeLogicalSwitch

- NsGroup

- IpSet

- FirewallSectionsAndRules

- Certificate

ClusterResources

- LogicalPort

- Tier1Router


NamespaceResources

- IpBlockSubnet

- IpPoolAllocation

- Tier1Router

- Tier1RouterPorts

- NATRules

- SpoofguradProfile

- NodeLogicalSwitch

- NsGroup

PodResources

- LogicalPort

- NATRules

NetworkPolicyResources

- IpSet

- FirewallSectionsAndRules

SecretResources

- Certificate

LBClusterWideResources

- IpPool

- IpPoolAllocation

- NodeLogicalSwitch

- Tier1Router


- Certificate

- ServerPool

- CookiePersistenceProfile

- SourceIPPersistenceProfile

- ApplicationProfile

- VirtualServer

L4ServiceResources

- SourceIPPersistenceProfile

- VirtualServer

- LBService


VMware, Inc. 101

Ejemplo config.yaml

Puede utilizar el siguiente ejemplo config.yaml como referencia.

# NSX Manager IP address

mgr_ip: null

# NSX Manager username, ignored if nsx_api_cert_file is set

username: "username"

# NSX Manager password, ignored if nsx_api_cert_file is set

password: "password"

# Principal Identity used to import the NSX resource

principal_identity: "admin"

# Path to NSX client certificate file. If specified, the username and

# password options will be ignored. Must be specified along with

# nsx_api_private_key_file option

# nsx_api_cert_file: /root/nsx-ujo/sample_scripts/com.vmware.nsx.ncp/nsx.crt

# Path to NSX client private key file. If specified, the username and

# password options will be ignored. Must be specified along with

# nsx_api_cert_file option

# nsx_api_private_key_file: /root/nsx-ujo/sample_scripts/com.vmware.nsx.ncp/nsx.key

# Specify one or a list of CA bundle files to use in verifying the NSX

# Manager server certificate. This option is ignored if "allow_insecure"

# is set to True. If "allow_insecure" is set to False and ca_file

# is unset, the system root CAs will be used to verify the server

# certificate

# ca_file: None

# Import only the shared resources

# To import a cluster, this flag must be set to False

import_shared_resources_only: True

# If true, all the imported MP to Policy resources will be rollbacked

# Default=False

rollback_imported_resources: False

# Name of the Kubernetes clusters to be imported, optional.

# Can be specified to import only specific K8s clusters from the

# ones specified under user-spec.yaml

# If not specified, all the clusters will be imported

k8s_cluster_names:

- k8scluster

# Name of the directory that records the IDs of resources

# that are successfully imported

# Default=successfull_records

# records_dir_name: successfull_records

# Path where the records of successfully imported resources are


VMware, Inc. 102

# saved. You can use this in conjunction with records_dir_name

# By default, we use the current working directory

# records_dir_base_path: None

# YAML config file that stores the information of resources

# to be imported

user_spec_file: "/root/nsx-ujo/sample_scripts/mp_to_policy_import/user-spec.yaml"

# Disable urllib's insecure request warning

# Default=False

no_warning: False

# If true, the NSX Manager server certificate is not verified. If false the

# CA bundle specified via "ca_file" will be used or if unset the default

# system root CAs will be used

# Default=False

allow_insecure: False

# Enable the debug logs

# Default=False

enable_debug_logs: False

# Do not print the logs on the console.

# Can be used with logging enabled to a file.

# Default=False

# disable_console_logs: False

# Output the logs to this file.

# Default=/var/log/nsx-ujo/mp_to_policy_import.log

# log_file: /var/log/nsx-ujo/mp_to_policy_import.log

Ejemplo user-spec.yaml

Puede utilizar el siguiente ejemplo user-spec.yaml como referencia.

Para NCP 3.0.1:

SharedResources:

# IMPORTANT: If there are multiple resources with the same

# display_name, please make the display_names unique before

# initiating the import

IpPool:

resources:

# Specify the resources to import here with their UUID or

# display_name

k8s-snat-pool:

# Duplicate MP to Policy imports allowed for ip-allocations

# ip-allocations:

# - key: "172.24.4.4"

# value: "ip-alloc-1"

k8s-lb-pool:

IpBlock:

resources:

k8s-container-block:


VMware, Inc. 103

IpSet:

resources:

vs-ipset-1:

Tier0Router:

resources:

node-t0:

Tier1Router:

resources:

# NOTE: If a Tier1 router is a top-tier router, it should not be imported

# as a shared resource

node-lr:

is-any-cluster-top-tier: False # required attribute

Tier1RouterPortsAndStaticRoutes:

resources:

# NOTE: If a Tier1 router is a top-tier router for any cluster,

# it should not be imported as a shared resource

node-lr:


# static_routes_import_info:

# - key: "a4b04674-feb9-4418-8d5f-ac8bca4665eb"

# value: st-r-1

# router_ports_import_info:

# - key: "s2f24456-feb9-4418-8d5f-ar8aqa4665vf"

# value: rp-1

NsGroup:

# resources:

# test-ns-group:

# domain: my-domain

SpoofguradProfile:

resources:

nsx-default-spoof-guard-vif-profile:

NodeLogicalSwitch:

resources:

node-ls:

FirewallSectionsAndRules:

resources:

# Make sure to write the DFW Section and Rules in the order

# in which they should be imported. Otherwise there might be a

# moment in which the section that is present at lower priority

# is imported before section that is present above it making the

# traffic flow inconsistent. The best way to do it is to mention

# the Sections and Rules with increasing |priority| number. Note

# that lower priority numbers are present at the top in the Section

# and Rules order in NSX

fw-section-1:

section_info:

# category is a Security Policy attribute

category: "Application"

# You can specify either priority or bool is_top_section.

# If is_top_section is True, priority is auto-assigned to 5

# If is_top_section is False, priority is auto-assigned to 95

# If is_top_section and priority are specified, priority is used

# If both are not specified, error is thrown

is_top_section: True

# priority: 1


VMware, Inc. 104

# domain is a Security Policy attribute

domain: "my-domain"

rules_info:

- name: "rule-name" # name or id must be specified

priority: 1 # optional. If not specified, FW Rule priority will be

# used as sequence number of Policy Rule

- id: 'rule-id' # name or id must be specified

Certificate:

resources:

my-cert:

k8s-clusters:

k8scluster:

# top-tier-router-id (MP) is required for each cluster

top-tier-router-id: null

# top-tier-router-type is required for each cluster

# choices: TIER0 or TIER1


# lb-service-mp-id is the same as lb_service in ncp.ini config file

lb-service-mp-id: null # optional

# NamespaceResources:

# Tier1Router:

# custom_resources:

# 6d93a932-87ea-42de-a30c-b39f397322b0:

k8scluster-2:





NamespaceResources:

Tier1Router:

custom_resources:


6d93a932-87ea-42de-a30c-b39f397322b0:

metadata:




linked_ids:




Para NCP 3.0.2:

SharedResources:

# IMPORTANT: If there are multiple resources with the same

# display_name, please make the display_names unique before

# initiating the import

IpPool:

resources:

# Specify the resources to import here with their UUID or

# display_name

k8s-snat-pool:

# Duplicate MP to Policy imports allowed for ip-allocations

# ip-allocations:


VMware, Inc. 105

# - key: "172.24.4.4"

# value: "ip-alloc-1"

k8s-lb-pool:

IpBlock:

resources:

k8s-container-block:

IpSet:

resources:

vs-ipset-1:

Tier0Router:

resources:

node-t0:

Tier1Router:

resources:

# NOTE: If a Tier1 router is a top-tier router, it should not be imported

# as a shared resource

node-lr:


Tier1RouterPortsAndStaticRoutes:

resources:

# NOTE: If a Tier1 router is a top-tier router for any cluster,

# it should not be imported as a shared resource

node-lr:


# static_routes_import_info:

# - key: "a4b04674-feb9-4418-8d5f-ac8bca4665eb"

# value: st-r-1

# router_ports_import_info:

# - key: "s2f24456-feb9-4418-8d5f-ar8aqa4665vf"

# value: rp-1

NsGroup:

# resources:

# test-ns-group:

# domain: my-domain

SpoofguradProfile:

resources:

nsx-default-spoof-guard-vif-profile:

NodeLogicalSwitch:

resources:

node-ls:

FirewallSectionsAndRules:

resources:

# Make sure to write the DFW Section and Rules in the order

# in which they should be imported. Otherwise there might be a

# moment in which the section that is present at lower priority

# is imported before section that is present above it making the

# traffic flow inconsistent. The best way to do it is to mention

# the Sections and Rules with increasing |priority| number. Note

# that lower priority numbers are present at the top in the Section

# and Rules order in NSX

fw-section-1:

section_info:

# category is a Security Policy attribute

category: "Application"

# You can specify either priority or bool is_top_section.


VMware, Inc. 106

# If is_top_section is True, priority is auto-assigned to 5

# If is_top_section is False, priority is auto-assigned to 95

# If is_top_section and priority are specified, priority is used

# If both are not specified, error is thrown

is_top_section: True

# priority: 1

# domain is a Security Policy attribute

domain: "my-domain"

rules_info:

- name: "rule-name" # name or id must be specified

priority: 1 # optional. If not specified, FW Rule priority will be

# used as sequence number of Policy Rule

- id: 'rule-id' # name or id must be specified

Certificate:

resources:

my-cert:

k8s-clusters:

k8scluster:



# top-tier-router-type is required for each cluster

# choices: TIER0 or TIER1




external-ip-pools-lb-mp-id: [] # required. leave empty, [], if not used

external-ip-pools-mp-id: [] # required. leave empty, [], if not used

http-and-https-ingress-ip: null

# NamespaceResources:

# Tier1Router:

# custom_resources:

# 6d93a932-87ea-42de-a30c-b39f397322b0:

k8scluster-2:






external-ip-pools-lb-mp-id: [] # required. leave empty, [], if not used

external-ip-pools-mp-id: [] # required. leave empty, [], if not used

http-and-https-ingress-ip: null


NamespaceResources:

Tier1Router:

custom_resources:


6d93a932-87ea-42de-a30c-b39f397322b0:

metadata:




linked_ids:





VMware, Inc. 107

Administrar NSX Container Plug-in 8Puede administrar NSX Container Plug-in desde la GUI de NSX Manager o desde la interfaz de la línea de comandos (command-line interface, CLI).

Nota Si una máquina virtual de host del contenedor se ejecuta en ESXi 6.5 y se migra mediante vMotion a otro host ESXi 6.5, los contenedores que se ejecuten en el host del contenedor perderán la conectividad con los contenedores que se ejecuten en otros hosts del contenedor. Para resolver el problema, desconecte y conecte la vNIC del host del contenedor. Este problema no ocurre con ESXi 6.5 Update 1 o versiones posteriores.

HyperBus reserva el identificador de VLAN 4094 en el hipervisor para la configuración de PVLAN. Este identificador no se puede cambiar. Para evitar conflictos de VLAN, no configure los conmutadores lógicos de VLAN ni las vmknics de VTEP con el mismo identificador de VLAN.


n Visualización de la información de errores almacenada en objetos NSXError de recursos de Kubernetes

n Limpieza del entorno de NSX-T

n Cambiar el nombre de un clúster en ejecución

n Comandos de la CLI

n Códigos de error

Visualización de la información de errores almacenada en objetos NSXError de recursos de Kubernetes

Para cada objeto de recurso de Kubernetes que tenga errores de back-end NSX, se crea un objeto NSXError con información del error. También existe un objeto de error para todos los errores que se aplican a todo el clúster.

VMware, Inc. 108

Esta función no está habilitada de forma predeterminada. Para habilitarla, debe establecer enable_nsx_err_crd como True en ncp.ini al instalar NCP.

Nota No debe crear, actualizar ni eliminar objetos NSXError.

Si inicia NCP en modo de directiva (con la opción policy_nsxapi=true en el archivo YAML de NCP), no se admitirá el recurso NSXError.

Comandos para mostrar los objetos NSXError:

n kubectl get nsxerrors

Enumera todos los objetos NSXError.

n kubectl get nsxerrors -l error-object-type=<type of resource>

Enumera los objetos NSXError relacionados con un tipo específico de objetos de Kubernetes; por ejemplo, los objetos de tipo services.

n kubectl get nsxerrors <nsxerror name> -o yaml

Muestra los detalles de un objeto NSXError.

n kubectl get svc <service name> -o yaml | grep nsxerror

Busca el objeto NSXError asociado a un servicio específico.

Cuando se muestran los detalles de un objeto NSXError, la sección de especificaciones contiene la siguiente información importante. Por ejemplo,

error-object-id: default.svc-1

error-object-name: svc-1

error-object-ns: default

error-object-type: services

message:

- '[2019-01-21 20:25:36]23705: Number of pool members requested exceed LoadBalancerlimit'

En este ejemplo, el espacio de nombres es default. El nombre del servicio es svc-1. El tipo de recurso de Kubernetes es services.

En esta versión, el objeto NSXError admite los siguientes errores.

n El ajuste de escala automático no pudo asignar equilibradores de carga adicionales debido a un límite de NSX Edge.

n El número de servidores virtuales del equilibrador de carga supera el límite (el ajuste de escala automático no está habilitado).

n El número de grupos de servidores del equilibrador de carga supera el límite.

n El número de miembros del grupo de servidores del equilibrador de carga supera el límite de equilibrador de carga o el límite de NSX Edge.

n Las direcciones IP flotantes se agotan al procesar un servicio de tipo equilibrador de carga.


VMware, Inc. 109

Limpieza del entorno de NSX-T

Si es necesario, puede ejecutar un script para eliminar todos los objetos de NSX-T creados por NCP.

Los archivos de instalación incluyen los siguientes scripts de limpieza:

n nsx_policy_cleanup.py: utilice este script si los recursos de NSX-T se crearon con el modo Directiva.

n nsx_cleanup.py: utilice este script si se crean recursos de NSX-T se crearon cono el modo Manager.

Antes de ejecutar el script, debe detener NCP.

El modo Directiva

Usage: nsx_policy_cleanup.py [options]

Options:

-h, --help show this help message and exit

--mgr-ip=MGR_IP NSX Manager IP address

-u USERNAME, --username=USERNAME

NSX Manager username, ignored if nsx-cert is set

-p PASSWORD, --password=PASSWORD

NSX Manager password, ignored if nsx-cert is set

-n NSX_CERT, --nsx-cert=NSX_CERT

NSX certificate path

-k KEY, --key=KEY NSX client private key path

--vc-endpoint=VC_ENDPOINT

IpAddress or Hostname of VC, ignored if environment

variable VC_ENDPOINT is set

--vc-username=VC_USERNAME

Username for the VC ServiceAccount, ignored if

environment variable VC_USERNAME is set

--vc-password=VC_PASSWORD

Password for the VC ServiceAccount, ignored if

environment variable VC_PASSWORD is set

--vc-https-port=VC_HTTPS_PORT

HTTPS port of VC, ignored if environment variable

VC_HTTPS_PORT is set. If not present, 443 default

value will be used

--vc-sso-domain=VC_SSO_DOMAIN

SSO Domain of VC, ignored if environment variable

VC_SSO_DOMAIN is set. If not present, local default

value will be used

--vc-ca-cert=VC_CA_CERT

Specify a CA bundle to verify the VC server

certificate. It will be ignored if environment

VC_CA_CERT is set

--vc-insecure Not verify VC server certificate

-c CLUSTER, --cluster=CLUSTER

Cluster to be removed

-r, --remove CAVEAT: Removes NSX resources. If not set will do dry-


VMware, Inc. 110

run.

--top-tier-router-id=TOP_TIER_ROUTER_ID

Specify the top tier router id. Must be specified if

top tier router does not have the cluster tag

--all-res Also clean up HA switching profile, ipblock, external

ippool. These resources could be created by PAS NSX-T

Tile

--no-warning Disable urllib's insecure request warning

--status Check the deletion status, the exit code can be

success(0), in progress(EXIT_CODE_IN_PROGRESS or

failure(other non-zerovalues)

--thumbprint=THUMBPRINT

Specify one or a list of thumbprint strings to use in

verifying the NSX Manager server certificate

Por ejemplo:

python nsx_policy_cleanup.py --mgr-ip={nsx_mngr_ip} -u admin -p {password} -c {k8s_cluster_name} --no-

warning -r

En algunos casos, se debe especificar el parámetro top-tier-router-id.

El modo Manager

Usage: nsx_cleanup.py [options]

Options:

-h, --help show this help message and exit

--mgr-ip=MGR_IP NSX Manager IP address

-u USERNAME, --username=USERNAME

NSX Manager username, ignored if nsx-cert is set

-p PASSWORD, --password=PASSWORD

NSX Manager password, ignored if nsx-cert is set

-n NSX_CERT, --nsx-cert=NSX_CERT

NSX certificate path

-k KEY, --key=KEY NSX client private key path

-c CLUSTER, --cluster=CLUSTER

Cluster to be removed

-r, --remove CAVEAT: Removes NSX resources. If not set will do dry-

run.

--top-tier-router-uuid=TOP_TIER_ROUTER_UUID

Specify the top tier router uuid. Must be specified if

top tier router does not have the cluster tag or for a

single-tier1 topology

--all-res Also clean up HA switching profile, ipblock, external

ippool. These resources could be created by PAS NSX-T

Tile

--no-warning Disable urllib's insecure request warning

Por ejemplo:

python nsx_cleanup.py --mgr-ip={nsx_mngr_ip} -u admin -p {password} -c {k8s_cluster_name} --top-tier-

router-uuid={top_tier_router_uuid} --no-warning -r


VMware, Inc. 111

Cambiar el nombre de un clúster en ejecución

No se recomienda cambiar el nombre de un clúster en ejecución. Si es necesario, siga el procedimiento que se indica a continuación.

1 Detenga NCP.

2 Descargue el script de limpieza para eliminar los recursos de NSX-T.

Para los recursos creados con el modo Manager, descargue nsx_cleanup.py. Para los recursos creados con el modo Directiva, descargue nsx_policy_cleanup.py.

3 Ejecute el script de limpieza.

4 Inicie NCP con el nuevo nombre de clúster.

5 Vuelva a crear los pods.

Comandos de la CLI

Para ejecutar comandos de la CLI, inicie sesión en el contenedor de NSX Container Plug-in, abra un terminal y ejecute el comando nsxcli.

También puede obtener avisos de la CLI ejecutando el siguiente comando en un nodo:

kubectl exec -it <pod name> nsxcli

Tabla 8-1. Comandos de la CLI para el contenedor de NCP

Tipo Comando Nota

Estado get ncp-master status Para Kubernetes y PCF.

Estado get ncp-nsx status Para Kubernetes y PCF.

Estado get ncp-watcher <nombre-monitor> Para Kubernetes y PCF.

Estado get ncp-watchers Para Kubernetes y PCF.

Estado get ncp-k8s-api-server status Solo para Kubernetes.

Estado check projects Solo para Kubernetes.

Estado check project <nombre-proyecto> Solo para Kubernetes.

Estado get ncp-bbs status Solo para PCF.

Estado get ncp-capi status Solo para PCF.

Estado get ncp-policy-server status Solo para PCF.

Caché get project-caches Solo para Kubernetes.

Caché get project-cache <nombre-proyecto> Solo para Kubernetes.

Caché get namespace-caches Solo para Kubernetes.

Caché get namespace-cache <nombre-espaciodenombres> Solo para Kubernetes.

Caché get pod-caches Solo para Kubernetes.

Caché get pod-cache <nombre-pod> Solo para Kubernetes.


VMware, Inc. 112

Tabla 8-1. Comandos de la CLI para el contenedor de NCP (continuación)

Tipo Comando Nota

Caché get ingress-caches Solo para Kubernetes.

Caché get ingress-cache <ingress-name> Solo para Kubernetes.

Caché get ingress-controllers Solo para Kubernetes.

Caché get ingress-controller <nombre-controlador-entrada> Solo para Kubernetes.

Caché get network-policy-caches Solo para Kubernetes.

Caché get network-policy-cache <nombre-pod> Solo para Kubernetes.

Caché get asg-caches Solo para PCF.

Caché get asg-cache <ID-asg> Solo para PCF.

Caché get org-caches Solo para PCF.

Caché get org-cache <ID-org> Solo para PCF.

Caché get space-caches Solo para PCF.

Caché get space-cache <ID-espacio> Solo para PCF.

Caché get app-caches Solo para PCF.

Caché get app-cache <<ID-aplicación> Solo para PCF.

Caché get instance-caches <ID-aplicación> Solo para PCF.

Caché get instance-cache <ID-aplicación> <ID-instancia> Solo para PCF.

Caché get policy-caches Solo para PCF.

Soporte técnico

get ncp-log file <nombredearchivo> Para Kubernetes y PCF.

Soporte técnico

get ncp-log-level Para Kubernetes y PCF.

Soporte técnico

set ncp-log-level <nivel-registro> Para Kubernetes y PCF.

Soporte técnico

get support-bundle file <nombredearchivo> Solo para Kubernetes.

Soporte técnico

get node-agent-log file <nombredearchivo> Solo para Kubernetes.

Soporte técnico

get node-agent-log file <nombredearchivo> <nombre-nodo>

Solo para Kubernetes.

Tabla 8-2. Comandos de la CLI para el contenedor de agentes del nodo de NSX

Tipo Comando

Estado get node-agent-hyperbus status

Caché get container-cache <nombre-contenedor>

Caché get container-caches


VMware, Inc. 113

Tabla 8-3. Comandos de la CLI para el contenedor de Kube Proxy de NSX

Tipo Comando

Estado get ncp-k8s-api-server status

Estado get kube-proxy-watcher <nombre-monitor>

Estado get kube-proxy-watchers

Estado dump ovs-flows

Comandos de estado para el contenedor de NCP

n Mostrar el estado del maestro de NCP

get ncp-master status

Ejemplo:

kubenode> get ncp-master status

This instance is not the NCP master

Current NCP Master id is a4h83eh1-b8dd-4e74-c71c-cbb7cc9c4c1c

Last master update at Wed Oct 25 22:46:40 2017

n Mostrar el estado de la conexión entre NCP y NSX Manager

get ncp-nsx status

Ejemplo:

kubenode> get ncp-nsx status

NSX Manager status: Healthy

n Mostrar el estado del monitor para la entrada, el espacio de nombres, el pod y el servicio

get ncp-watchers

get ncp-watcher <watcher-name>

Ejemplo:

kubenode> get ncp-watchers

pod:

Average event processing time: 1145 msec (in past 3600-sec window)

Current watcher started time: Mar 02 2017 10:51:37 PST

Number of events processed: 1 (in past 3600-sec window)

Total events processed by current watcher: 1

Total events processed since watcher thread created: 1

Total watcher recycle count: 0

Watcher thread created time: Mar 02 2017 10:51:37 PST

Watcher thread status: Up

namespace:




VMware, Inc. 114







ingress:









service:









kubenode> get ncp-watcher pod









n Mostrar el estado de conexión entre el servidor de API de NCP y de Kubernetes

get ncp-k8s-api-server status

Ejemplo:

kubenode> get ncp-k8s-api-server status

Kubernetes ApiServer status: Healthy

n Comprobar todos los proyectos o uno específico

check projects

check project <project-name>


VMware, Inc. 115

Ejemplo:

kubenode> check projects

default:

Tier-1 link port for router 1b90a61f-0f2c-4768-9eb6-ea8954b4f327 is missing

Switch 40a6829d-c3aa-4e17-ae8a-7f7910fdf2c6 is missing

ns1:

Router 8accc9cd-9883-45f6-81b3-0d1fb2583180 is missing

kubenode> check project default

Tier-1 link port for router 1b90a61f-0f2c-4768-9eb6-ea8954b4f327 is missing

Switch 40a6829d-c3aa-4e17-ae8a-7f7910fdf2c6 is missing

n Comprobar el estado de conexión entre BBS de NCP y PCF

get ncp-bbs status

Ejemplo:

node> get ncp-bbs status

BBS Server status: Healthy

n Comprobar el estado de conexión entre CAPI de NCP y PCF

get ncp-capi status

Ejemplo:

node> get ncp-capi status

CAPI Server status: Healthy

n Comprobar el estado de conexión entre el servidor de directivas de NCP y PCF

get ncp-policy-server status

Ejemplo:

node> get ncp-bbs status

Policy Server status: Healthy

Comandos de caché para el contenedor de NCP

n Obtener la caché interna para los proyectos o los espacios de nombres

get project-cache <project-name>

get project-caches

get namespace-cache <namespace-name>

get namespace-caches


VMware, Inc. 116

Ejemplo:

kubenode> get project-caches

default:

logical-router: 8accc9cd-9883-45f6-81b3-0d1fb2583180

logical-switch:

id: 9d7da647-27b6-47cf-9cdb-6e4f4d5a356d

ip_pool_id: 519ff57f-061f-4009-8d92-3e6526e7c17e

subnet: 10.0.0.0/24

subnet_id: f75fd64c-c7b0-4b42-9681-fc656ae5e435

kube-system:

logical-router: 5032b299-acad-448e-a521-19d272a08c46

logical-switch:

id: 85233651-602d-445d-ab10-1c84096cc22a

ip_pool_id: ab1c5b09-7004-4206-ac56-85d9d94bffa2

subnet: 10.0.1.0/24

subnet_id: 73e450af-b4b8-4a61-a6e3-c7ddd15ce751

testns:

ext_pool_id: 346a0f36-7b5a-4ecc-ad32-338dcb92316f

labels:

ns: myns

project: myproject

logical-router: 4dc8f8a9-69b4-4ff7-8fb7-d2625dc77efa

logical-switch:

id: 6111a99a-6e06-4faa-a131-649f10f7c815

ip_pool_id: 51ca058d-c3dc-41fd-8f2d-e69006ab1b3d

subnet: 50.0.2.0/24

subnet_id: 34f79811-bd29-4048-a67d-67ceac97eb98

project_nsgroup: 9606afee-6348-4780-9dbe-91abfd23e475

snat_ip: 4.4.0.3

kubenode> get project-cache default


logical-switch:



subnet: 10.0.0.0/24


kubenode> get namespace-caches

default:


logical-switch:



subnet: 10.0.0.0/24


kube-system:

logical-router: 5032b299-acad-448e-a521-19d272a08c46

logical-switch:


VMware, Inc. 117

id: 85233651-602d-445d-ab10-1c84096cc22a

ip_pool_id: ab1c5b09-7004-4206-ac56-85d9d94bffa2

subnet: 10.0.1.0/24

subnet_id: 73e450af-b4b8-4a61-a6e3-c7ddd15ce751

testns:

ext_pool_id: 346a0f36-7b5a-4ecc-ad32-338dcb92316f

labels:

ns: myns

project: myproject

logical-router: 4dc8f8a9-69b4-4ff7-8fb7-d2625dc77efa

logical-switch:

id: 6111a99a-6e06-4faa-a131-649f10f7c815

ip_pool_id: 51ca058d-c3dc-41fd-8f2d-e69006ab1b3d

subnet: 50.0.2.0/24

subnet_id: 34f79811-bd29-4048-a67d-67ceac97eb98

project_nsgroup: 9606afee-6348-4780-9dbe-91abfd23e475

snat_ip: 4.4.0.3

kubenode> get namespace-cache default


logical-switch:



subnet: 10.0.0.0/24


n Obtener la caché interna para los pods

get pod-cache <pod-name>

get pod-caches

Ejemplo:

kubenode> get pod-caches

nsx.default.nginx-rc-uq2lv:

cif_id: 2af9f734-37b1-4072-ba88-abbf935bf3d4

gateway_ip: 10.0.0.1

host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 1c8b5c52-3795-11e8-ab42-005056b198fb

ingress_controller: False

ip: 10.0.0.2/24

labels:

app: nginx

mac: 02:50:56:00:08:00

port_id: d52c833a-f531-4bdf-bfa2-e8a084a8d41b

vlan: 1

nsx.testns.web-pod-1:

cif_id: ce134f21-6be5-43fe-afbf-aaca8c06b5cf


host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 3180b521-270e-11e8-ab42-005056b198fb



VMware, Inc. 118

ip: 50.0.2.3/24

labels:

app: nginx-new

role: db

tier: cache

mac: 02:50:56:00:20:02

port_id: 81bc2b8e-d902-4cad-9fc1-aabdc32ecaf8

vlan: 3

kubenode> get pod-cache nsx.default.nginx-rc-uq2lv

cif_id: 2af9f734-37b1-4072-ba88-abbf935bf3d4


host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 1c8b5c52-3795-11e8-ab42-005056b198fb


ip: 10.0.0.2/24

labels:

app: nginx

mac: 02:50:56:00:08:00

port_id: d52c833a-f531-4bdf-bfa2-e8a084a8d41b

vlan: 1

n Obtener todas las cachés de entrada o una específica

get ingress caches

get ingress-cache <ingress-name>

Ejemplo:

kubenode> get ingress-caches

nsx.default.cafe-ingress:

ext_pool_id: cc02db70-539a-4934-a938-5b851b3e485b

lb_virtual_server:

id: 895c7f43-c56e-4b67-bb4c-09d68459d416

lb_service_id: 659eefc6-33d1-4672-a419-344b877f528e

name: dgo2-http

type: http

lb_virtual_server_ip: 5.5.0.2

name: cafe-ingress

rules:

host: cafe.example.com

http:

paths:

path: /coffee

backend:


servicePort: 80

lb_rule:

id: 4bc16bdd-abd9-47fb-a09e-21e58b2131c3

name: dgo2-default-cafe-ingress/coffee

kubenode> get ingress-cache nsx.default.cafe-ingress

ext_pool_id: cc02db70-539a-4934-a938-5b851b3e485b


VMware, Inc. 119

lb_virtual_server:

id: 895c7f43-c56e-4b67-bb4c-09d68459d416

lb_service_id: 659eefc6-33d1-4672-a419-344b877f528e

name: dgo2-http

type: http

lb_virtual_server_ip: 5.5.0.2

name: cafe-ingress

rules:

host: cafe.example.com

http:

paths:

path: /coffee

backend:


servicePort: 80

lb_rule:

id: 4bc16bdd-abd9-47fb-a09e-21e58b2131c3

name: dgo2-default-cafe-ingress/coffee

n Obtener información sobre todos los controladores de entrada o uno específico, incluidos los controladores que están deshabilitados

get ingress controllers

get ingress-controller <ingress-controller-name>

Ejemplo:

kubenode> get ingress-controllers

native-load-balancer:

ingress_virtual_server:

http:

default_backend_tags:

id: 895c7f43-c56e-4b67-bb4c-09d68459d416

pool_id: None

https_terminated:


id: 293282eb-f1a0-471c-9e48-ba28d9d89161

pool_id: None

lb_ip_pool_id: cc02db70-539a-4934-a938-5b851b3e485b

loadbalancer_service:

first_avail_index: 0

lb_services:

id: 659eefc6-33d1-4672-a419-344b877f528e

name: dgo2-bfmxi

t1_link_port_ip: 100.64.128.5

t1_router_id: cb50deb2-4460-45f2-879a-1b94592ae886

virtual_servers:

293282eb-f1a0-471c-9e48-ba28d9d89161

895c7f43-c56e-4b67-bb4c-09d68459d416

ssl:

ssl_client_profile_id: aff205bb-4db8-5a72-8d67-218cdc54d27b

vip: 5.5.0.2


VMware, Inc. 120

nsx.default.nginx-ingress-rc-host-ed3og

ip: 10.192.162.201

mode: hostnetwork

pool_id: 5813c609-5d3a-4438-b9c3-ea3cd6de52c3

kubenode> get ingress-controller native-load-balancer

ingress_virtual_server:

http:


id: 895c7f43-c56e-4b67-bb4c-09d68459d416

pool_id: None

https_terminated:


id: 293282eb-f1a0-471c-9e48-ba28d9d89161

pool_id: None

lb_ip_pool_id: cc02db70-539a-4934-a938-5b851b3e485b

loadbalancer_service:

first_avail_index: 0

lb_services:

id: 659eefc6-33d1-4672-a419-344b877f528e

name: dgo2-bfmxi

t1_link_port_ip: 100.64.128.5

t1_router_id: cb50deb2-4460-45f2-879a-1b94592ae886

virtual_servers:

293282eb-f1a0-471c-9e48-ba28d9d89161

895c7f43-c56e-4b67-bb4c-09d68459d416

ssl:

ssl_client_profile_id: aff205bb-4db8-5a72-8d67-218cdc54d27b

vip: 5.5.0.2

n Obtener cachés de directiva de red o una específica

get network-policy caches

get network-policy-cache <network-policy-name>

Ejemplo:

kubenode> get network-policy-caches

nsx.testns.allow-tcp-80:

dest_labels: None

dest_pods:

50.0.2.3

match_expressions:

key: tier

operator: In

values:

cache

name: allow-tcp-80

np_dest_ip_set_ids:

22f82d76-004f-4d12-9504-ce1cb9c8aa00

np_except_ip_set_ids:

np_ip_set_ids:

14f7f825-f1a0-408f-bbd9-bb2f75d44666

np_isol_section_id: c8d93597-9066-42e3-991c-c550c46b2270


VMware, Inc. 121

np_section_id: 04693136-7925-44f2-8616-d809d02cd2a9

ns_name: testns

src_egress_rules: None

src_egress_rules_hash: 97d170e1550eee4afc0af065b78cda302a97674c

src_pods:

50.0.2.0/24

src_rules:

from:

namespaceSelector:

matchExpressions:

key: tier

operator: DoesNotExist

matchLabels:

ns: myns

ports:

port: 80

protocol: TCP

src_rules_hash: e4ea7b8d91c1e722670a59f971f8fcc1a5ac51f1

kubenode> get network-policy-cache nsx.testns.allow-tcp-80

dest_labels: None

dest_pods:

50.0.2.3

match_expressions:

key: tier

operator: In

values:

cache

name: allow-tcp-80

np_dest_ip_set_ids:

22f82d76-004f-4d12-9504-ce1cb9c8aa00

np_except_ip_set_ids:

np_ip_set_ids:

14f7f825-f1a0-408f-bbd9-bb2f75d44666

np_isol_section_id: c8d93597-9066-42e3-991c-c550c46b2270

np_section_id: 04693136-7925-44f2-8616-d809d02cd2a9

ns_name: testns

src_egress_rules: None

src_egress_rules_hash: 97d170e1550eee4afc0af065b78cda302a97674c

src_pods:

50.0.2.0/24

src_rules:

from:

namespaceSelector:

matchExpressions:

key: tier

operator: DoesNotExist

matchLabels:

ns: myns

ports:

port: 80

protocol: TCP

src_rules_hash: e4ea7b8d91c1e722670a59f971f8fcc1a5ac51f1


VMware, Inc. 122

n Obtener todas las cachés de ASG o una específica

get asg-caches

get asg-cache <asg-ID>

Ejemplo:

node> get asg-caches

edc04715-d04c-4e63-abbc-db601a668db6:

fws_id: 3c66f40a-5378-46d7-a7e2-bee4ba72a4cc

name: org-85_tcp_80_asg

rules:

destinations:

66.10.10.0/24

ports:

80

protocol: tcp

rule_id: 4359

running_default: False

running_spaces:

75bc164d-1214-46f9-80bb-456a8fbccbfd

staging_default: False

staging_spaces:

node> get asg-cache edc04715-d04c-4e63-abbc-db601a668db6

fws_id: 3c66f40a-5378-46d7-a7e2-bee4ba72a4cc

name: org-85_tcp_80_asg

rules:

destinations:

66.10.10.0/24

ports:

80

protocol: tcp

rule_id: 4359

running_default: False

running_spaces:

75bc164d-1214-46f9-80bb-456a8fbccbfd

staging_default: False

staging_spaces:

n Obtener todas las cachés de organización o una específica

get org-caches

get org-cache <org-ID>

Ejemplo:

node> get org-caches

ebb8b4f9-a40f-4122-bf21-65c40f575aca:

ext_pool_id: 9208a8b8-57d7-4582-9c1f-7a7cefa104f5

isolation:

isolation_section_id: d6e7ff95-4737-4e34-91d4-27601897353f

logical-router: 94a414a2-551e-4444-bae6-3d79901a165f


VMware, Inc. 123

logical-switch:

id: d74807e8-8f74-4575-b26b-87d4fdbafd3c

ip_pool_id: 1b60f16f-4a30-4a3d-93cc-bfb08a5e3e02

subnet: 50.0.48.0/24

subnet_id: a458d3aa-bea9-4684-9957-d0ce80d11788

name: org-50

snat_ip: 70.0.0.49

spaces:

e8ab7aa0-d4e3-4458-a896-f33177557851

node> get org-cache ebb8b4f9-a40f-4122-bf21-65c40f575aca

ext_pool_id: 9208a8b8-57d7-4582-9c1f-7a7cefa104f5

isolation:

isolation_section_id: d6e7ff95-4737-4e34-91d4-27601897353f

logical-router: 94a414a2-551e-4444-bae6-3d79901a165f

logical-switch:

id: d74807e8-8f74-4575-b26b-87d4fdbafd3c

ip_pool_id: 1b60f16f-4a30-4a3d-93cc-bfb08a5e3e02

subnet: 50.0.48.0/24

subnet_id: a458d3aa-bea9-4684-9957-d0ce80d11788

name: org-50

snat_ip: 70.0.0.49

spaces:

e8ab7aa0-d4e3-4458-a896-f33177557851

n Obtener todas las cachés de espacio o una específica

get space-caches

get space-cache <space-ID>

Ejemplo:

node> get space-caches

global_security_group:

name: global_security_group

running_nsgroup: 226d4292-47fb-4c2e-a118-449818d8fa98

staging_nsgroup: 7ebbf7f5-38c9-43a3-9292-682056722836

7870d134-7997-4373-b665-b6a910413c47:

name: test-space1

org_id: a8423bc0-4b2b-49fb-bbff-a4badf21eb09

running_nsgroup: 4a3d9bcc-be36-47ae-bff8-96448fecf307

running_security_groups:

aa0c7c3f-a478-4d45-8afa-df5d5d7dc512

staging_security_groups:


node> get space-cache 7870d134-7997-4373-b665-b6a910413c47

name: test-space1


running_nsgroup: 4a3d9bcc-be36-47ae-bff8-96448fecf307


VMware, Inc. 124

running_security_groups:


staging_security_groups:


n Obtener todas las cachés de aplicación o una específica

get app-caches

get app-cache <app-ID>

Ejemplo:

node> get app-caches

aff2b12b-b425-4d9f-b8e6-b6308644efa8:

instances:

b72199cc-e1ab-49bf-506d-478d:

app_id: aff2b12b-b425-4d9f-b8e6-b6308644efa8

cell_id: 0dda88bc-640b-44e7-8cea-20e83e873544

cif_id: 158a1d7e-6ccc-4027-a773-55bb2618f51b

gateway_ip: 192.168.5.1

host_vif: 53475dfd-03e4-4bc6-b8ba-3d803725cbab

id: b72199cc-e1ab-49bf-506d-478d

index: 0

ip: 192.168.5.4/24

last_updated_time: 1522965828.45

mac: 02:50:56:00:60:02

port_id: a7c6f6bb-c472-4239-a030-bce615d5063e

state: RUNNING

vlan: 3

name: hello2

rg_id: a8423bc0-4b2b-49fb-bbff-a4badf21eb09

space_id: 7870d134-7997-4373-b665-b6a910413c47

node> get app-cache aff2b12b-b425-4d9f-b8e6-b6308644efa8

instances:

b72199cc-e1ab-49bf-506d-478d:




gateway_ip: 192.168.5.1


id: b72199cc-e1ab-49bf-506d-478d

index: 0

ip: 192.168.5.4/24


mac: 02:50:56:00:60:02


state: RUNNING

vlan: 3

name: hello2


space_id: 7870d134-7997-4373-b665-b6a910413c47


VMware, Inc. 125

n Obtener todas cachés de instancia de una aplicación o una caché de instancia específica

get instance-caches <app-ID>

get instance-cache <app-ID> <instance-ID>

Ejemplo:

node> get instance-caches aff2b12b-b425-4d9f-b8e6-b6308644efa8

b72199cc-e1ab-49bf-506d-478d:




gateway_ip: 192.168.5.1


id: b72199cc-e1ab-49bf-506d-478d

index: 0

ip: 192.168.5.4/24


mac: 02:50:56:00:60:02


state: RUNNING

vlan: 3

node> get instance-cache aff2b12b-b425-4d9f-b8e6-b6308644efa8 b72199cc-e1ab-49bf-506d-478d




gateway_ip: 192.168.5.1


id: b72199cc-e1ab-49bf-506d-478d

index: 0

ip: 192.168.5.4/24


mac: 02:50:56:00:60:02


state: RUNNING

vlan: 3

n Obtener todas las cachés de directiva

get policy-caches

Ejemplo:

node> get policy-caches

aff2b12b-b425-4d9f-b8e6-b6308644efa8:

fws_id: 3fe27725-f139-479a-b83b-8576c9aedbef

nsg_id: 30583a27-9b56-49c1-a534-4040f91cc333

rules:

8272:

dst_app_id: aff2b12b-b425-4d9f-b8e6-b6308644efa8

ports: 8382

protocol: tcp


VMware, Inc. 126

src_app_id: f582ec4d-3a13-440a-afbd-97b7bfae21d1

f582ec4d-3a13-440a-afbd-97b7bfae21d1:

nsg_id: d24b9f77-e2e0-4fba-b258-893223683aa6

rules:

8272:

dst_app_id: aff2b12b-b425-4d9f-b8e6-b6308644efa8

ports: 8382

protocol: tcp

src_app_id: f582ec4d-3a13-440a-afbd-97b7bfae21d1

Comandos de soporte para el contenedor de NCP

n Guardar el paquete de soporte técnico de NCP en el almacén de archivos

El paquete de soporte técnico consta de los archivos de registro de todos los contenedores de los pods con la etiqueta tier:nsx-networking. El archivo de paquete tiene formato tgz y se guarda en el directorio del almacén de archivos predeterminado de la CLI /var/vmware/nsx/file-store. Puede utilizar el comando del almacén de archivos de la CLI para copiar el archivo de paquete a un sitio remoto.

get support-bundle file <filename>

Ejemplo:

kubenode>get support-bundle file foo

Bundle file foo created in tgz format

kubenode>copy file foo url scp://[email protected]:/tmp

n Guardar los registros de NCP en el almacén de archivos

El archivo de registro se guarda en formato tgz y en el directorio del almacén de archivos predeterminado de la CLI /var/vmware/nsx/file-store. Puede utilizar el comando del almacén de archivos de la CLI para copiar el archivo de paquete a un sitio remoto.

get ncp-log file <filename>

Ejemplo:

kubenode>get ncp-log file foo

Log file foo created in tgz format

n Guardar los registros del agente del nodo en el almacén de archivos

Guarde los registros del agente del nodo de uno nodo o de todos. Los registros se guardan en formato tgz y en el directorio del almacén de archivos predeterminado de la CLI /var/vmware/nsx/file-store. Puede utilizar el comando del almacén de archivos de la CLI para copiar el archivo de paquete a un sitio remoto.

get node-agent-log file <filename>

get node-agent-log file <filename> <node-name>


VMware, Inc. 127

Ejemplo:

kubenode>get node-agent-log file foo

Log file foo created in tgz format

n Obtener y establecer el nivel de registro

Los niveles de registro disponibles son NOTSET, DEBUG, INFO, WARNING, ERROR y CRITICAL.

get ncp-log-level

set ncp-log-level <log level>

Ejemplo:

kubenode>get ncp-log-level

NCP log level is INFO

kubenode>set ncp-log-level DEBUG

NCP log level is changed to DEBUG

Comandos de estado para el contenedor de agentes del nodo de NSX

n Mostrar el estado de conexión entre HyperBus y el agente de este nodo.

get node-agent-hyperbus status

Ejemplo:

kubenode> get node-agent-hyperbus status

HyperBus status: Healthy

Comandos de caché para el contenedor de agentes del nodo de NSX

n Obtener la caché interna para contenedores de agentes del nodo de NSX.

get container-cache <container-name>

get container-caches

Ejemplo:

kubenode> get container-caches

cif104:

ip: 192.168.0.14/32

mac: 50:01:01:01:01:14

gateway_ip: 169.254.1.254/16

vlan_id: 104

kubenode> get container-cache cif104


VMware, Inc. 128

ip: 192.168.0.14/32

mac: 50:01:01:01:01:14

gateway_ip: 169.254.1.254/16

vlan_id: 104

Comandos de estado para el contenedor del proxy de NSX Kube

n Mostrar el estado de conexión entre el servidor de Kube Proxy y de Kubernetes

get ncp-k8s-api-server status

Ejemplo:

kubenode> get kube-proxy-k8s-api-server status

Kubernetes ApiServer status: Healthy

n Mostrar el estado del monitor de Kube Proxy

get kube-proxy-watcher <watcher-name>

get kube-proxy-watchers

Ejemplo:

kubenode> get kube-proxy-watchers

endpoint:


Current watcher started time: May 01 2017 15:06:24 PDT





Watcher thread created time: May 01 2017 15:06:24 PDT


service:









kubenode> get kube-proxy-watcher endpoint






VMware, Inc. 129





n Volcar los flujos OVS en un nodo

dump ovs-flows

Ejemplo:

kubenode> dump ovs-flows

NXST_FLOW reply (xid=0x4):

cookie=0x0, duration=8.876s, table=0, n_packets=0, n_bytes=0, idle_age=8, priority=100,ip

actions=ct(table=1)

cookie=0x0, duration=8.898s, table=0, n_packets=0, n_bytes=0, idle_age=8, priority=0

actions=NORMAL

cookie=0x0, duration=8.759s, table=1, n_packets=0, n_bytes=0, idle_age=8,

priority=100,tcp,nw_dst=10.96.0.1,tp_dst=443 actions=mod_tp_dst:443


priority=100,ip,nw_dst=10.96.0.10 actions=drop


priority=90,ip,in_port=1 actions=ct(table=2,nat)

cookie=0x0, duration=8.799s, table=1, n_packets=0, n_bytes=0, idle_age=8, priority=80,ip

actions=NORMAL

cookie=0x0, duration=8.856s, table=2, n_packets=0, n_bytes=0, idle_age=8, actions=NORMAL

Códigos de error

En esta sección se muestran los códigos de error que generan los diferentes componentes.

Códigos de error de NCP

Código de error Descripción

NCP00001 Configuración no válida

NCP00002 Error en la inicialización

NCP00003 Estado no válido

NCP00004 Adaptador no válido

NCP00005 Certificado no encontrado

NCP00006 Token no encontrado

NCP00007 Configuración de NSX no válida

NCP00008 Etiqueta de NSX no válida

NCP00009 Error en la conexión de NSX

NCP00010 Etiqueta de nodo no encontrada

NCP00011 Puerto de conmutador lógico de nodo no válido

NCP00012 Error en la actualización de VIF principal


VMware, Inc. 130


NCP00013 VLAN agotada

NCP00014 Error en la liberación de VLAN

NCP00015 Grupo de direcciones IP agotado

NCP00016 Error en la liberación de IP

NCP00017 Bloque de direcciones IP agotado

NCP00018 Error en la creación de la subred de direcciones IP

NCP00019 Error en la eliminación de la subred de direcciones IP

NCP00020 Error en la creación del grupo de direcciones IP

NCP00021 Error en la eliminación del grupo de direcciones IP

NCP00022 Error en la creación del enrutador lógico

NCP00023 Error en la actualización del enrutador lógico

NCP00024 Error en la eliminación del enrutador lógico

NCP00025 Error en la creación del conmutador lógico


NCP00026 Error en la actualización del conmutador lógico

NCP00027 Error en la eliminación del conmutador lógico

NCP00028 Error en la creación del puerto de enrutador lógico

NCP00029 Error en la eliminación del puerto de enrutador lógico

NCP00030 Error en la creación del puerto de conmutador lógico

NCP00031 Error en la actualización del puerto de conmutador lógico

NCP00032 Error en la eliminación del puerto de conmutador lógico

NCP00033 Directiva de red no encontrada

NCP00034 Error en la creación del firewall

NCP00035 Error en la lectura del firewall

NCP00036 Error en la actualización del firewall

NCP00037 Error en la eliminación del firewall

NCP00038 Varias instancias de firewall encontradas

NCP00039 Error en la creación del grupo NSGroup

NCP00040 Error en la eliminación del grupo NSGroup

NCP00041 Error en la creación del conjunto de direcciones IP

NCP00042 Error en la actualización del conjunto de direcciones IP

NCP00043 Error en la eliminación del conjunto de direcciones IP

NCP00044 Error en la creación de reglas SNAT

NCP00045 Error en la eliminación de reglas SNAT


VMware, Inc. 131


NCP00046 Error en la conexión de la API de adaptador

NCP00047 Excepción de monitor de adaptador

NCP00048 Error en la eliminación del servicio de equilibrador de carga

NCP00049 Error en la creación del servidor virtual del equilibrador de carga

NCP00050 Error en la actualización del servidor virtual del equilibrador de carga


NCP00051 Error en la eliminación del servidor virtual del equilibrador de carga

NCP00052 Error en la creación del grupo de equilibradores de carga

NCP00053 Error en la actualización del grupo de equilibradores de carga

NCP00054 Error en la eliminación del grupo de equilibradores de carga

NCP00055 Error en la creación de la regla de equilibrador de carga

NCP00056 Error en la actualización de la regla de equilibrador de carga

NCP00057 Error en la eliminación de la regla de equilibrador de carga

NCP00058 Error en la liberación de IP del grupo de equilibradores de carga

NCP00059 Asociación entre el servicio y el servidor virtual del equilibrador de carga no encontrada

NCP00060 Error en la actualización del grupo NSGroup

NCP00061 Error en la obtención de las reglas de firewall

NCP00062 Grupo NSGroup sin criterios

NCP00063 Máquina virtual de nodo no encontrada

NCP00064 VIF de nodo no encontrado

NCP00065 Error en la importación del certificado

NCP00066 Error en la anulación de la importación del certificado

NCP00067 Error en la actualización del enlace de SSL

NCP00068 Perfil de SSL no encontrado

NCP00069 Grupo de direcciones IP no encontrado

NCP00070 Clúster de Edge T0 no encontrado

NCP00071 Error en la actualización del grupo de direcciones IP

NCP00072 Error en el distribuidor

NCP00073 Error en la eliminación de reglas NAT

NCP00074 Error en la obtención del puerto de enrutador lógico

NCP00075 Error en la validación de la configuración de NSX


NCP00076 Error en la actualización de reglas SNAT

NCP00077 Regla SNAT superpuesta


VMware, Inc. 132


NCP00078 Error en la adición de endpoints de equilibrador de carga

NCP00079 Error en la actualización de endpoints de equilibrador de carga

NCP00080 Error en la creación del grupo de reglas de equilibrador de carga

NCP00081 Servidor virtual del equilibrador de carga no encontrado

NCP00082 Error en la lectura del conjunto de direcciones IP

NCP00083 Error en la obtención del grupo SNAT

NCP00084 Error en la creación del servicio de equilibrador de carga

NCP00085 Error en la actualización del servicio de equilibrador de carga

NCP00086 Error en la actualización del puerto de enrutador lógico

NCP00087 Error en la inicialización del equilibrador de carga

NCP00088 El grupo de direcciones IP no es único

NCP00089 Error en la sincronización de la memoria caché del equilibrador de carga de capa 7

NCP00090 El grupo de equilibradores de carga no existe

NCP00091 Error en la inicialización de la memoria caché de la regla de equilibrador de carga

NCP00092 Error en el proceso SNAT

NCP00093 Error en el certificado predeterminado de equilibrador de carga

NCP00094 Error en la eliminación del endpoint de equilibrador de carga

NCP00095 Proyecto no encontrado

NCP00096 Acceso denegado al grupo

NCP00097 No se pudo obtener un servicio de equilibrador de carga

NCP00098 No se pudo crear un servicio de equilibrador de carga

NCP00099 Error en la sincronización de la memoria caché del grupo de equilibradores de carga

Códigos de error del agente de nodo de NSX


NCP01001 Vínculo superior de OVS no encontrado

NCP01002 Dirección MAC de host no encontrada

NCP01003 Error en la creación del puerto de OVS

NCP01004 Sin configuración de pod

NCP01005 Error en la configuración de pod

NCP01006 Error en la anulación de la configuración de pod

NCP01007 Socket de CNI no encontrado

NCP01008 Error en la conexión de CNI

NCP01009 Error de coincidencia de la versión de CNI

NCP01010 Error en la recepción del mensaje de CNI


VMware, Inc. 133


NCP01011 Error en la transmisión del mensaje de CNI

NCP01012 Error en la conexión de HyperBus

NCP01013 Error de coincidencia de la versión de HyperBus

NCP01014 Error en la recepción del mensaje de HyperBus

NCP01015 Error en la transmisión del mensaje de HyperBus

NCP01016 Error en el envío de GARP

NCP01017 Error en la configuración de interfaz

Códigos de error de nsx-kube-proxy


NCP02001 Puerto de puerta de enlace no válido de proxy

NCP02002 Error en el comando de proxy

NCP02003 Error en la validación de proxy

Códigos de error de la CLI


NCP03001 Error en el inicio de la CLI

NCP03002 Error en la creación del socket de la CLI

NCP03003 Excepción de socket de la CLI

NCP03004 Solicitud no válida del cliente de la CLI

NCP03005 Error en la transmisión del servidor de la CLI

NCP03006 Error en la recepción del servidor de la CLI

NCP03007 Error en la ejecución del comando de la CLI

Códigos de error de Kubernetes


NCP05001 Error en la conexión de Kubernetes

NCP05002 Configuración no válida de Kubernetes

NCP05003 Error en la solicitud de Kubernetes

NCP05004 Clave de Kubernetes no encontrada

NCP05005 Tipo de Kubernetes no encontrado

NCP05006 Excepción de monitor de Kubernetes

NCP05007 Longitud no válida del recurso de Kubernetes

NCP05008 Tipo no válido del recurso de Kubernetes


VMware, Inc. 134


NCP05009 Error en el identificador del recurso de Kubernetes

NCP05010 Error en el identificador del servicio de Kubernetes

NCP05011 Error en el identificador del endpoint de Kubernetes

NCP05012 Error en el identificador de la entrada de Kubernetes

NCP05013 Error en el identificador de la directiva de red de Kubernetes

NCP05014 Error en el identificador del nodo de Kubernetes

NCP05015 Error en el identificador del espacio de nombres de Kubernetes

NCP05016 Error en el identificador del pod de Kubernetes

NCP05017 Error en el identificador del secreto de Kubernetes

NCP05018 Error en el back-end predeterminado de Kubernetes

NCP05019 Expresión de coincidencia no admitida de Kubernetes

NCP05020 Error en la actualización del estado de Kubernetes

NCP05021 Error en la actualización de la anotación de Kubernetes

NCP05022 Memoria caché de espacio de nombres de Kubernetes no encontrada

NCP05023 Secreto de Kubernetes no encontrado

NCP05024 El back-end predeterminado de Kubernetes está en uso

NCP05025 Error en el identificador del servicio de equilibrador de carga de Kubernetes

Códigos de error de Pivotal Cloud Foundry


NCP06001 Error en la conexión de BBS de PCF

NCP06002 Error en la conexión de CAPI de PCF

NCP06006 Memoria caché de PCF no encontrada

NCP06007 Dominio desconocido de PCF

NCP06020 Error en la conexión del servidor de directivas de PCF

NCP06021 Error en el procesamiento de directivas de PCF

NCP06030 Error en el procesamiento de eventos de PCF

NCP06031 Tipo de evento inesperado de PCF

NCP06032 Instancia de evento inesperada de PCF

NCP06033 Error en la eliminación de la tarea de PCF

NCP06034 Error de acceso al archivo de PCF


VMware, Inc. 135

Documents

NSX Container Plug-in 3.0, 3.0.1 VMware NSX-T Data Center 3...Nota Al configurar NAT, el número total de direcciones IP traducidas no puede ser superior a 1000. n Implementa directivas