Guía de instalación y administración de NSX Container Plug-in para OpenShift. NSX Container Plug-in 3.1, 3.1.1, VMware NSX-T Data Center 3.

(1)

Guía de instalación y administración de NSX Container Plug-in para OpenShift

NSX Container Plug-in 3.1, 3.1.1, 3.1.2

VMware NSX-T Data Center 3.1

(2)

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 94304 www.vmware.com

VMware Spain, S.L.

Calle Rafael Boti 26 2.ª planta

Madrid 28023 Tel.: +34 914125000 www.vmware.com/es

(3)

Contenido

Guía de instalación y administración de NSX-T Container Plug-in para OpenShift 4

1

Descripción general de NSX Container Plugin 5

Requisitos de compatibilidad 6 Descripción general de la instalación 6

2

Configurar recursos de NSX-T 7

Configurar los recursos de NSX-T 7

3

Preparing NCP for OpenShift 4 11

4

Instalación de OpenShift 4 17

5

Configuración del equilibrio de carga 19

6

Upgrade NCP 26

7

Administrar NSX Container Plug-in 28

Limpieza del entorno de NSX-T 28

Cambiar el nombre de un clúster en ejecución 30 Comandos de la CLI 31

Códigos de error 42

(4)

NSX-T Container Plug-in para OpenShift

Esta guía describe cómo instalar y administrar NSX Container Plug-in (NCP) para integrar NSX-T Data Center y OpenShift.

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 y OpenShift 4.

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.

(5)

Descripción general de NSX

Container Plugin 1

NSX Container Plugin (NCP) integra NSX-T Data Center y orquestadores de contenedores, como Kubernetes, así como también integra NSX-T Data Center y productos de software de PaaS (plataforma como servicio) basados en contenedores, como OpenShift.

Esta guía describe cómo configurar NCP con OpenShift 4. Para configurar NCP con OpenShift 3, consulte la parte de esta guía sobre NCP 2.5.

El componente principal de NCP se ejecuta en un contenedor y se comunica con NSX Manager y con el plano de control de OpenShift. 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 la API de Directiva de NSX-T.

El complemento CNI de NSX se ejecuta en cada nodo de OpenShift. 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 para un clúster de OpenShift y crea una red lógica independiente para cada espacio de nombres de OpenShift.

n Conecta pods de OpenShift 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 OpenShift.

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

n Implementa directivas de red de OpenShift con el firewall distribuido de NSX-T.

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.

(6)

n Implementa la ruta de OpenShift con el equilibrador de carga de capa 7 de NSX-T.

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

n Compatibilidad con rutas con back-ends alternativos y subdominios comodín.

n Crea etiquetas en el puerto de conmutador lógico de NSX-T 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 Data Center con base en etiquetas.

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.1: https://docs.vmware.com/es/VMware-NSX-T-Data-Center/3.1/rn/

NSX-Container-Plugin-31-Release-Notes.html

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

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

Descripción general de la instalación

La instalación y configuración de NCP incluye los siguientes pasos. Para realizar los pasos

correctamente, debe estar familiarizado con la instalación y administración de NSX-T Data Center y OpenShift 4.

Tenga en cuenta que todos los objetos de NSX-T deben crearse mediante la interfaz de usuario de Directiva.

1 Instale NSX-T Data Center.

2 Crear una zona de transporte superpuesta.

3 Cree un segmento superpuesto y una puerta de enlace de nivel 1 y conecte los nodos de OpenShift al segmento.

4 Instale OpenShift y NCP.

(7)

Configurar recursos de NSX-T

2

Antes 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.1/

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

administration/GUID-BB26CDC8-2A90-4C7E-9331-643D13FEEC4A.html.

Para OpenShift 4, debe utilizar el modo de directiva o la API de Directiva para configurar los recursos de NSX-T.

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 los recursos de NSX-T

Configurar los recursos de NSX-T

En esta sección se describe cómo configurar los recursos en el modo de directiva de NSX Manager.

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

Puertas de enlace y segmento

1 Cree un segmento para los nodos de Kubernetes, por ejemplo, ocp4-segment.

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

(8)

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 ocp4-segment. 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 segmento que se crea automáticamente. Puede encontrarlo en la pestaña Redes > Segmentos con el mismo nombre que el segmento (ocp4-segment).

7 Si utiliza DHCP, puede proporcionar un enlace DHCP estático en el segmento para los nodos.

NCP debe conocer el identificador de la VIF de la vNIC. Para ver los puertos de ocp4-segment creados automáticamente, vaya a Redes > Segmentos. Estos puertos no se pueden editar, excepto por la propiedad de su etiqueta. Estos puertos deben tener las siguientes etiquetas:

n etiqueta: <cluster_name>, ámbito: ncp/cluster

n etiqueta: <node_name>, ámbito: ncp/node_name

Nota: No es necesario agregar manualmente las etiquetas anteriores. El operador de red de NCP lo agregará automáticamente.

Bloques de IP para los pods de Kubernetes

NCP creará automáticamente los bloques de IP. El operador de red de NSX pasará el valor del parámetro cidr en la sección networking.clusterNetwork de install-config.yaml. Por ejemplo:

networking:

networkType: ncp clusterNetwork:

- cidr: 10.4.0.0/16 hostPrefix: 23

machineCIDR: 10.114.16.0/24 serviceNetwork:

- 172.30.0.0/16

El adaptador de OpenShift 4 creará un nuevo bloque de IP para cada CIDR configurado en el archivo install-config.yaml. Debe tener cuidado si existe algún bloque de direcciones IP con el mismo CIDR. No se recomienda utilizar bloques de direcciones IP superpuestos, ya que NCP habilita el anuncio de rutas de subred conectadas entre el nivel 0 y el nivel 1.

(9)

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 (parte del operador de red de NCP) 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.

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 cambiar a un grupo de direcciones IP diferente cambiando el configmap nsx-ncp- operator-config en el proyecto nsx-system-operator una vez que se implemente el clúster.

Topología de nivel 1 compartida

En el siguiente diagrama se muestra una topología compartida de nivel 1.

Guía de instalación y administración de NSX Container Plug-in para OpenShift

(10)

Enrutador físico 1

Enrutador físico 2 EBGP/Static

Nivel 0 Activo/Activo Nivel 0 Activo/En espera

Equilibrador de carga de NSX para servicio de tipo LoadBalancer

Firewall distribuido e IDS por POD

La IP de SNAT por proyecto se configura aquí

Nivel 1 por clúster de OCP Segmento lógico y subred

por proyecto de OpenShift

10.24.0.0/24 10.24.2.0/24

vSphere, NSX-T, almacenamiento

Plano de control de OCP Nodos de trabajo de OCP Nivel 1

Esta es la única topología de OpenShift 4. Para configurar esta topología, realice las siguientes configuraciones:

n Establezca la opción top_tier_router para el identificador de la 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 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.

(11)

Preparing NCP for OpenShift 4

3

Before installing OpenShift 4, you must update some NCP configuration files.

Starting with NCP 3.1.1 the YAML files are included in the NCP download file

from download.vmware.com. You can go to https://github.com/vmware/nsx-container-plugin- operator/releases, find the corresponding operator release (for example, v3.1.1) and download openshift4.tar.gz.

For NCP 3.1.0, check out v0.2.0 from https://github.com/vmware/nsx-container-plugin-operator/

releases.

The following files are in the nsx-container-plugin-operator/deploy folder:

n configmap.yaml – Update this file with the NSX-T information.

n operator.yaml – Specify the NCP image location in this file.

n namespace.yaml – The namespace specification for the operator. Do not edit this file.

n role_binding.yaml - The role binding specefication for the operator. Do not edit this file.

n role.yaml - The role specification for the operator. Do not edit this file.

n service_account.yaml - The service account specification for the operator. Do not edit this file.

n lb-secret.yaml - Secret for the default NSX-T load balancer certificate.

n nsx-secret.yaml - Secret for certificate-based authentication to NSX-T. This is used instead of nsx_api_user and nsx_api_password in the configmap.yaml.

n operator.nsx.vmware.com_ncpinstalls_crd.yaml - Operator-owned Customer Resource Definition.

n operator.nsx.vmware.com_v1_ncpinstall_cr.yaml - Operator-owned Customer Resource.

The following connfigmap.yaml example shows a basic configuration. See configmap.yaml in the deploy folder for more options. You must specify values for the following parameters according to your environment:

n cluster

n nsx_api_managers

(12)

n nsx_api_user

n nsx_api_password

n external_ip_pools

n tier0_gateway

n overlay_tz

n edge_cluster

n apiserver_host_ip

n apiserver_host_port

kind: ConfigMap metadata:

ncp.ini: | [vc]

[coe]

# Container orchestrator adaptor to plug in.

adaptor = openshift4

# Specify cluster name.

cluster = ocp [DEFAULT]

[nsx_v3]

policy_nsxapi = True

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

nsx_api_managers = 10.114.209.10,10.114.209.11,10.114.209.12

nsx_api_user = admin nsx_api_password = VMware1!

# Do not use in production insecure = True

# Choices: ALL DENY <None>

log_firewall_traffic = DENY

(13)

external_ip_pools = 10.114.17.0/25 #top_tier_router = <None>

tier0_gateway = t0a

single_tier_topology = True

overlay_tz = 3efa070d-3870-4eb1-91b9-a44416637922 edge_cluster = 3088dc2b-d097-406e-b9de-7a161e8d0e47 [ha]

[k8s]

# Kubernetes API server IP address.

apiserver_host_ip = api-int.ocp.yasen.local

# Kubernetes API server port.

apiserver_host_port = 6443

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

# Choices: <None> allow_cluster allow_namespace baseline_policy_type = allow_cluster

enable_multus = False process_oc_network = False [nsx_kube_proxy]

[nsx_node_agent]

ovs_bridge = br-int

# The OVS uplink OpenFlow port ovs_uplink_port = ens192 [operator]

# The default certificate for HTTPS load balancing.

# Must be specified along with lb_priv_key option.

# Operator will create lb-secret for NCP based on these two options.

#lb_default_cert = <None>

# The private key for default certificate for HTTPS load balancing.

# Must be specified along with lb_default_cert option.

#lb_priv_key = <None>

In operator.yaml, you must specify the location of NCP image in the env section.

kind: Deployment metadata:

namespace: nsx-system-operator spec:

replicas: 1 selector:

matchLabels:

(14)

metadata:

labels:

hostNetwork: true

serviceAccountName: nsx-ncp-operator tolerations:

- effect: NoSchedule

key: node-role.kubernetes.io/master - effect: NoSchedule

key: node.kubernetes.io/not-ready containers:

- name: nsx-ncp-operator

# Replace this with the built image name

image: vmware/nsx-container-plugin-operator:latest

command: ["/bin/bash", "-c", "nsx-ncp-operator --zap-time-encoding=iso8601"]

imagePullPolicy: Always env:

- name: POD_NAME valueFrom:

fieldRef:

fieldPath: metadata.name - name: OPERATOR_NAME

value: "nsx-ncp-operator"

- name: NCP_IMAGE value: "{NCP Image}"

For the operator image, specify the NCP version that will need to be installed. For example, for NCP 3.1.1, the operator image is vmware/nsx-container-plugin-operator:v3.1.1.

Note that pulling directly dockerhub is not recommended in a production environment because of its rate limiting policy. Once pulled from dockerhub, the image can be pushed to a local registry, possibly the same where NCP images are available.

Alternatively, you can use the operator image file included in the NCP download file from download.vmware.com and import it into a local registry. This image is the same as the one published on VMware's dockerhub.

To set the MTU value for CNI, modify the mtu parameter in the [nsx-node-agent] section of the Operator ConfigMap. The operator will trigger a recreation of the nsx-ncp-boostrap pods ensuring that CNI config files are properly updated on all the nodes. You must also update the node MTU accordingly. A mismatch between the node and pod MTU can cause problems for node-pod communication, affecting, for example, TCP liveness and readiness probes.

Note: Enabling HA in the Operator ConfigMap will create a single NCP pod because the

ncpReplicas parameter is set to 1 by default. To have 3 NCP pods created, you can change it to 3. After the cluster is installed, you can change the number of NCP replicas with the command oc edit ncpinstalls ncp-install -n nsx-system.

(15)

Configuring certificate-based authentication to NSX-T using principal identity

In a production environment, it is recommended that you do not expose administrator credentials in configmap.yaml with the nsx_api_user and nsx_api_password parameters. The following steps describe how to create a principal identity and allow NCP to use a certificate for

authentication.

1 Generate a certificate and key.

2 In NSX Manager, navigate to System > Users and Roles and click Add > Principal Identity with Role. Add a principal identity and paste the certificate generated in step 1.

3 Add the base64-encoded crt and key values in nsx-secret.yaml.

4 Set the location of the certificate and key files in configmap.yaml under the [nsx_v3] section:

nsx_api_cert_file = /etc/nsx-ujo/nsx-cert/tls.crt nsx_api_private_key_file = /etc/nsx-ujo/nsx-cert/tls.key

Note: Changing the authentication method on a cluster that is already bootstrapped is not supported.

(Optional) Configuring the default NSX-T load balancer certificate

An NSX-T load balancer can implement OpenShift HTTPS Route objects and offload the OCP HAProxy. To do that a default certificate is required. Perform the following steps to configure the default certificate:

1 Add the base64-encoded crt and key values in lb-secret.yaml.

2 Set the location for the certificate and the key in configmap.yaml under the [nsx_v3]

section:

lb_default_cert_path = /etc/nsx-ujo/lb-cert/tls.crt lb_priv_key_path = /etc/nsx-ujo/lb-cert/tls.key

(Optional) Configuring certificate-based authentication to NSX Managers

If you set insecure = False in the ConfigMap, you must specify the certificate thumbprints of all three managers in the NSX Manager cluster. The following procedure is an example of how to do this.

Copy the certificates of all three NSX Managers to a file:

ssh -l admin 10.114.209.10 -f 'get certificate api' > nsx1.crt ssh -l admin 10.114.209.11 -f 'get certificate api' > nsx2.crt Guía de instalación y administración de NSX Container Plug-in para OpenShift

(16)

ssh -l admin 10.114.209.12 -f 'get certificate api' > nsx3.crt

NSX1=`openssl x509 -in nsx1.crt -fingerprint -noout|awk -F"=" '{print $2}'`

THUMB="$NSX1,$NSX2,$NSX3"

echo $THUMB

Edit the ConfigMap and add the thumbprints in the [nsx_v3] section:

oc edit cm nsx-ncp-operator-config -n nsx-system-operator

nsx_api_managers = 10.114.209.10,10.114.209.11,10.114.209.12 nsx_api_user = admin

nsx_api_password = VMwareVMware1!

insecure = False thumbprint =

E0:A8:D6:06:88:B9:65:7D:FB:F8:14:CF:D5:E5:23:98:C9:43:10:71,A7:B0:26:B5:B2:F6:72:2B:39:86:19:8 4:E6:DD:AB:43:16:0E:CE:BD,52:9B:99:90:88:4C:9F:9B:83:5E:F7:AF:FC:60:06:50:BE:9E:32:08

(17)

Instalación de OpenShift 4

4

Para instalar un clúster de OpenShift, siga las instrucciones de la documentación oficial de RedHat OpenShift.

Puede consultar la documentación en https://docs.openshift.com/container-platform/4.4/

installing/installing_vsphere/installing-vsphere.html.

Un ejemplo de install-config.yaml:

apiVersion: v1

baseDomain: yasen.local compute:

- hyperthreading: Enabled name: worker

replicas: 0 controlPlane:

hyperthreading: Enabled name: master

replicas: 3 metadata:

networkType: ncp clusterNetwork:

- cidr: 10.4.0.0/16 hostPrefix: 23

machineCIDR: 10.114.16.0/24 serviceNetwork:

- 172.30.0.0/16 platform:

vsphere:

vcenter: vc.yasen.local

username: [email protected] password: VMware1!

datacenter: Datacenter1 defaultDatastore: NFS pullSecret: ''

sshKey: 'ssh-rsa xxxx'

Asegúrese de que networkType esté establecido en ncp (distingue entre mayúsculas y minúsculas) y cidr esté establecido en la subred deseada.

(18)

Después de las instrucciones de instalación de OpenShift, deberá copiar el contenido de nsx- container-plugin-operator/deploy en la carpeta <directorio_instalación>/manifests y, a continuación, generar ignition-configs.

Para generar manifiestos, ejecute el siguiente comando:

$ ./openshift-install create manifests --dir=<installation_directory>

Para copiar los archivos YAML del operador de red de NCP en la carpeta manifests, ejecute el siguiente comando:

$ cp nsx-container-plugin-operator/deploy/*.yaml <installation_directory>/manifests

Para generar ignition-configs, ejecute el siguiente comando:

$ ./openshift-install create ignition-configs --dir=<installation_directory>

Usar DDNS con nodos de OpenShift

Puede utilizar DDNS con nodos de OpenShift que ejecutan CoreOS. Cuando se ejecuta el contenedor nsx-ovs, este detiene la conexión activa en el host que está utilizando DHCP y clona una nueva conexión desde él con "NSX" antepuesto al nombre de la conexión actual.

Esta conexión de NSX tiene la configuración de IP dinámica (dirección, puerta de enlace, DNS y dominio) de la conexión original. Se iniciará un nuevo cliente DHCP dentro del contenedor para mantener y renovar la concesión. Si el DNS o el nombre de dominio cambian mientras nsx-ovs se está ejecutando, se cerrará y se reiniciará. Esto se lleva a cabo para que NetworkManager y, a continuación, nsx-ovs obtengan la información de la IP. Las propiedades de la conexión de NSX no se pueden anular mientras esta esté activa.

(19)

Configuración del equilibrio de

carga 5

El equilibrador de carga de NSX-T Data Center está integrado con OpenShift y actúa como enrutador de OpenShift.

NCP supervisa los eventos de endpoint y la ruta de OpenShift, y configura las reglas de equilibrio de carga en el equilibrador de carga en función de la especificación de ruta. A raíz de ello, el equilibrador de carga de NSX-T Data Center reenviará el tráfico entrante de capa 7 a los pods de back-end adecuados según las reglas.

La configuración del equilibrio de carga conlleva configurar un servicio de equilibrador de carga de Kubernetes o una ruta de OpenShift. También se debe configurar el controlador de replicación de NCP. El servicio de equilibrador de carga corresponde al tráfico de capa 4, mientras que la ruta de OpenShift corresponde al tráfico de capa 7.

Cuando se configura un servicio de equilibrador de carga de Kubernetes, se le asigna una dirección IP del bloque de IP externo que se haya configurado. El equilibrador de carga se expone en esta dirección IP y en el puerto del servicio. Puede especificar el nombre o el identificador de un grupo de IP usando la especificación loadBalancerIP en la definición del equilibrador de carga. La IP del servicio de equilibrador de carga se asignará a partir de este grupo de direcciones IP. Si la especificación loadBalancerIP está vacía, la IP se asignará a partir del bloque de direcciones IP externo que configure.

El grupo de direcciones IP especificado por loadBalancerIP debe tener la etiqueta scope: ncp/

owner, tag: cluster:<cluster_name>.

Para usar el equilibrador de carga de NSX-T Data Center, hay que configurar el equilibrio de carga de NCP. En el archivo ncp_rc.yml, haga lo siguiente:

1 Establezca use_native_loadbalancer como True.

2 Establezca pool_algorithm como WEIGHTED_ROUND_ROBIN.

3 Establezca lb_default_cert_path y lb_priv_key_path como los nombres de ruta completa del archivo de certificado firmado por CA y del archivo de clave privada, respectivamente. A continuación se incluye un script de ejemplo que permite generar un certificado firmado por CA. Adicionalmente, monte la clave y el certificado predeterminados en el pod de NCP. Consulte las instrucciones más adelante.

(20)

4 (Opcional) Especifique una configuración de persistencia con los parámetros

l4_persistence y l7_persistence. 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

5 (Opcional) Establezca service_size como SMALL, MEDIUM o LARGE. El valor predeterminado es SMALL.

6 Si ejecuta OpenShift 3.11, debe aplicar la siguiente configuración de manera que OpenShift no asigne una dirección IP al servicio de equilibrador de carga.

n Establezca ingressIPNetworkCIDR como 0.0.0.0/32 en networkConfig en el archivo /etc/origin/master/master-config.yaml.

n Reinicie los controladores y el servidor de API con los siguientes comandos:

master-restart api

master-restart controllers

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

(21)

(https://kubernetes.io/docs/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:

apiVersion: extensions/v1beta1 kind: Ingress

metadata:

rules:

- host: cafe.example.com http:

paths:

- path: /tea backend:

serviceName: tea-svc servicePort: 80 ---

apiVersion: v1 kind: Service metadata:

app: tea spec:

ports:

- port: 80 targetPort: 80 protocol: TCP name: tcp selector:

app: tea

type: LoadBalancer

(22)

Ejemplo de equilibrador de carga de capa 7

Con el siguiente archivo YAML se configuran dos controladores de replicación (tea-rc y

coffee-rc), dos servicios (tea-svc y coffee-svc) y dos rutas (cafe-route-multi y cafe-route) para proporcionar equilibrio de carga de capa 7.

# RC

apiVersion: v1

kind: ReplicationController metadata:

replicas: 2 template:

metadata:

labels:

app: tea spec:

containers:

- name: tea

image: nginxdemos/hello imagePullPolicy: IfNotPresent ports:

- containerPort: 80 ---

apiVersion: v1

kind: ReplicationController metadata:

replicas: 2 template:

metadata:

labels:

app: coffee spec:

containers:

- name: coffee

image: nginxdemos/hello imagePullPolicy: IfNotPresent ports:

- containerPort: 80 ---

# Services apiVersion: v1 kind: Service metadata:

app: tea spec:

ports:

- port: 80 targetPort: 80

(23)

protocol: TCP name: http selector:

app: tea ---

apiVersion: v1 kind: Service metadata:

app: coffee spec:

ports:

- port: 80 targetPort: 80 protocol: TCP name: http selector:

app: coffee ---

# Routes apiVersion: v1 kind: Route metadata:

host: www.cafe.com path: /drinks to:

kind: Service name: tea-svc weight: 1 alternateBackends:

- kind: Service name: coffee-svc weight: 2 ---

apiVersion: v1 kind: Route metadata:

host: www.cafe.com path: /tea-svc to:

kind: Service name: tea-svc weight: 1

Notas adicionales

n Se admiten todos los modos de finalización: edge, passthrough y reencrypt.

(24)

n Se admiten subdominios comodín. Por ejemplo, si wildcardPolicy está establecido como Subdomain y el nombre de host se establece como wildcard.example.com, se atenderá cualquier solicitud a *.ejemplo.com.

n Si NCP genera un error al procesar un evento de ruta debido a una configuración errónea, será necesario corregir el archivo YAML de la ruta y, a continuación, eliminar y volver a crear el recurso de ruta.

n NCP no aplica la propiedad de nombre de host por espacios de nombres.

n Se admite un servicio de equilibrador de carga por cada clúster de Kubernetes.

n NSX-T Data Center creará un grupo y un servidor virtual de equilibrador de carga de capa 4 por cada puerto de servicio de equilibrador de carga. Se admiten los protocolos TCP y UDP.

n El equilibrador de carga de NSX-T Data Center viene en diferentes tamaños. Para obtener información sobre la configuración de un equilibrador de carga de NSX-T Data Center, 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.

n Se admite el ajuste de escala automático del equilibrador de carga de capa 4. 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. Se puede deshabilitar estableciendo l4_lb_auto_scaling como false en ConfigMap de NCP.

n En una especificación de ruta, el parámetro destinationCACertificate no es compatible y NCP lo ignorará.

n Cada ruta TLS debe tener un certificado firmado por una entidad de certificación (CA) diferente.

Script de ejemplo para generar un certificado firmado por CA

Con el siguiente script se genera 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. Se puede especificar un método de cifrado con el comando (p. ej., aes256).

#!/bin/bash

host="www.example.com"

filename=server

openssl genrsa -out ca.key 4096

(25)

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

(26)

6

NSX Container Plugin Operator is responsible for managing the life cycle of NCP.

Upgrade of NCP is done by updating the NCP Operator and NCP image. Before performing the upgrade, check the release notes for product compatibility.

Requisitos previos

Download the latest nsx-container zip file (nsx-container-x.x.x.y.zip) from https://

downloads.vmware.com.

The following tar files are needed for the upgrade:

n nsx-container-x.x.x.y/Kubernetes/nsx-container-plugin-operator-x.x.x.y.tar

n nsx-container-x.x.x.y/Kubernetes/nsx-ncp-ubi-x.x.x.y.tar The two images must be uploaded to your container registry.

Procedimiento

1 Edit operator.yaml.

Modify the nsx-ncp-container image:

containers:

image: <URL to the NCP operator in your container registry>

Modify the NCP_IMAGE URL:

image: <URL to the NCP operator in your container registry>

2 Update configmap.yaml with any new required fields for this release. The information about any new required attributes is available in the release notes.

3 Apply role.yaml with the following command.

oc apply -f role.yaml -n nsx-system-operator

(27)

4 Apply operator.yaml (and confimap.yaml if changed) in the nsx-system-operator namespace with the following command.

oc apply -f operator.yaml -n nsx-system-operator

There is no need to edit the running config.

(28)

7

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

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.

(29)

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

(30)

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

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.

(31)

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 7-1. Comandos de la CLI para el contenedor de NCP

Tipo Comando

Estado get ncp-master status Estado get ncp-nsx status

Estado get ncp-watcher <nombre-monitor>

Estado get ncp-watchers

Estado get ncp-k8s-api-server status

Estado check projects

Estado check project <nombre-proyecto>

Caché get project-cache <nombre-proyecto>

Caché get project-caches

Caché get namespace-cache <nombre-espaciodenombres>

Caché get namespace-caches

Caché get pod-cache <nombre-pod>

Caché get pod-caches

Caché get ingress-caches

Caché get ingress-cache <ingress-name>

Caché get ingress-controllers

Caché get ingress-controller <nombre-controlador-entrada>

Caché get network-policy-caches

Caché get network-policy-cache <nombre-pod>

Soporte técnico get ncp-log file <nombredearchivo>

(32)

Tabla 7-1. Comandos de la CLI para el contenedor de NCP (continuación)

Soporte técnico get ncp-log-level

Soporte técnico set ncp-log-level <nivel-registro>

Soporte técnico get support-bundle file <nombredearchivo>

Soporte técnico get node-agent-log file <nombredearchivo>

Soporte técnico get node-agent-log file <nombredearchivo> <nombre-nodo>

Tabla 7-2. Comandos de la CLI para el contenedor de agentes del nodo de NSX

Estado get node-agent-hyperbus status

Caché get container-cache <nombre-contenedor>

Caché get container-caches

Tabla 7-3. Comandos de la CLI para el contenedor de Kube Proxy de NSX

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

(33)

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-watcher <watcher-name>

get ncp-watchers

Ejemplo 1:

kubenode> get ncp-watcher pod

Average event processing time: 1174 msec (in past 3600-sec window) Current watcher started time: Mar 02 2017 10:47:35 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:47:35 PST Watcher thread status: Up

Ejemplo 2:

kubenode> get ncp-watchers pod:

namespace:

ingress:

(34)

service:

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>

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

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

Ejemplo:

kubenode> get project-caches default:

logical-router: 8accc9cd-9883-45f6-81b3-0d1fb2583180

(35)

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-router: 8accc9cd-9883-45f6-81b3-0d1fb2583180 logical-switch:

kubenode> get namespace-caches default:

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 Guía de instalación y administración de NSX Container Plug-in para OpenShift

(36)

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

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 gateway_ip: 50.0.2.1

host_vif: d6210773-5c07-4817-98db-451bd1f01937 id: 3180b521-270e-11e8-ab42-005056b198fb ingress_controller: False

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

(37)

kubenode> get pod-cache 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

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

(38)

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

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>