Guía de instalación y
administración de NSX Container Plug-in para OpenShift
VMware NSX Container Plug-in 2.3, 2.3.1, 2.3.2 VMware NSX-T Data Center 2.3
VMware NSX-T Data Center 2.3.1
Puede encontrar la documentación técnica más actualizada en el sitio web de VMware:
https://docs.vmware.com/es/
El sitio web de VMware también ofrece las actualizaciones de producto más recientes.
Si tiene comentarios relacionados con esta documentación, envíelos a:
Copyright © 2017–2019 VMware, Inc. Todos los derechos reservados. Información sobre el copyright y marca 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
Contenido
Guía de instalación y administración de NSX-T Container Plug-in para OpenShift 4
1
Descripción general de NSX-T Container Plug-in 5Requisitos de compatibilidad 6 Descripción general de la instalación 6 Actualizar NCP 7
2
Configurar recursos de NSX-T 8Configurar los recursos de NSX-T 8
Crear y configurar un enrutador lógico de nivel 0 11
3
Instalar NCP en un entorno de OpenShift 13Implementar máquinas virtuales de OpenShift 13 Preparar el archivo de hosts de Ansible 13
Instalar NCP y OpenShift mediante un solo playbook 16
Instalar el complemento CNI, OVS y la imagen de Docker de NCP 16 Instalar OpenShift Container Platform 19
Ejecutar NCP y el agente del nodo de NSX. 19 Notas de la instalación 21
4
Instalar NCP en un entorno sin sistema operativo 25Instalar el complemento CNI de NSX-T Data Center 25
Configurar redes de NSX-T Data Center para nodos de OpenShift 25 Instalar el agente del nodo de NSX 26
ConfigMap para ncp.ini in nsx-node-agent-ds.yml 27 Instalar NSX-T Container Plug-in 30
ConfigMap para ncp.ini en ncp-rc.yml 32
5
Equilibrio de carga 38Configuración del equilibrio de carga 38
6
Administrar NSX-T Container Plug-in 45Administrar los bloques de IP desde la GUI de NSX Manager 45 Ver subredes de bloques de IP desde la GUI de NSX Manager 46 Puertos lógicos conectados a CIF 46
Comandos de la CLI 47 Códigos de error 58
NSX-T Container Plug-in para OpenShift
Esta guía describe cómo instalar y administrar NSX-T 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.
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.
Descripción general de NSX-T
Container Plug-in 1
NSX-T Container Plug-in (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.
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 NSX API.
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.
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.
En esta versión, NCP solo admite un clúster de OpenShift.
Este capítulo incluye los siguientes temas:
n Requisitos de compatibilidad
n Descripción general de la instalación
n Actualizar NCP
Requisitos de compatibilidad
NSX-T Container Plug-in (NCP) tiene los siguientes requisitos de compatibilidad.
Productos de software Versión
NSX-T Data Center 2.2, 2.3
Hipervisor para las máquinas virtuales de los hosts del contenedor
n Versión de vSphere admitida
n RHEL KVM 7.4, 7.5 Sistema operativo del host del contenedor RHEL 7.4, 7.5
Plataforma como servicio OpenShift 3.9, 3.10
Open vSwitch del host del contenedor 2.9.1 (incluye NSX-T 2.3 y 2.2)
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.
1 Instale NSX-T Data Center.
2 Crear una zona de transporte superpuesta.
3 Crear un conmutador lógico superpuesto y conectar los nodos al conmutador.
4 Crear un enrutador lógico de nivel 0.
5 Crear bloques de IP para los pods.
6 Crear grupos de IP para la traducción de direcciones de red de origen (Source Network Address Translation, SNAT).
7 Implementar máquinas virtuales de OpenShift.
8 Preparar el archivo de hosts de Ansible.
9 (Opción 1) Instalar NCP y OpenShift mediante un solo playbook.
(Opción 2) Instalar el complemento CNI, OVS (Open vSwitch) y la imagen de Docker de NCP. A
10 Ejecutar NCP y el agente del nodo de NSX.
Los pasos del 2 al 6 no son necesarios si se instala NCP con los playbooks provistos. Consulte Instalar NCP y OpenShift mediante un solo playbook y Instalar el complemento CNI, OVS y la imagen de Docker de NCP.
Actualizar NCP
Realice los siguientes pasos para actualizar NCP a la versión 2.3.0.
1 Actualice el paquete RPM de CNI, el DaemonSet del agente de nodo de NSX y el ReplicationController de NCP.
2 (Opcional) Actualice NSX-T Data Center a la versión 2.3.
NCP 2.3.0 admite NSX-T 2.2, pero también puede actualizar a NSX-T Data Center 2.3.
Configurar recursos de NSX-T 2
Se deben crear recursos de NSX-T Data Center para proporcionar redes a nodos de OpenShift. Puede configurar estos recursos de forma manual usando la GUI de NSX Manager o automatizar el proceso utilizando un playbook de Ansible.
Esta sección describe cómo se crean los recursos de NSX-T de forma manual. Para automatizar el proceso, consulte Instalar el complemento CNI, OVS y la imagen de Docker de NCP.
Este capítulo incluye los siguientes temas:
n Configurar los recursos de NSX-T
n Crear y configurar un enrutador lógico de nivel 0
Configurar los recursos de NSX-T
Los recursos de NSX-T Data Center que necesita configurar incluyen una zona de transporte de
superposición, un enrutador lógico de nivel 0, un conmutador lógico para conectar las máquinas virtuales del nodo, bloques de IP para los nodos de Kubernetes y un grupo de IP para SNAT.
Los recursos de NSX-T Data Center se configuran usando los UUID o los nombres en el archivo de configuración ncp.ini.
Zona de transporte superpuesta
Inicie sesión en NSX Manager y vaya a Tejido > Zonas de transporte. Encuentre la zona de transporte superpuesta que se usa para las redes de los contenedores o cree una nueva.
Especifique una zona de transporte superpuesta de un clúster configurando la opción overlay_tz en la sección [nsx_v3] de ncp.ini. Este paso es opcional. Si no se configura overlay_tz, NCP recuperará automáticamente el identificador de zona de transporte superpuesta del enrutador de nivel 0.
Enrutamiento lógico de nivel 0
Inicie sesión en NSX Manager y desplácese hasta Redes > Enrutamiento > Enrutadores. Encuentre el enrutador que se usa para las redes de los contenedores o cree uno nuevo.
Especifique un enrutador lógico de nivel 0 de un clúster configurando la opción tier0_router en la sección [nsx_v3] de ncp.ini.
Nota El enrutador se debe crear en modo activo-en espera.
Conmutador lógico
Las vNIC que usan el nodo para el tráfico de datos deben estar conectadas a un conmutador lógico superpuesto. No es obligatorio que la interfaz de administración del nodo esté conectada a
NSX-T Data Center, aunque hacerlo facilitaría la configuración. Para crear un conmutador lógico, inicie sesión en NSX Manager y desplácese hasta Redes > Conmutación > Conmutadores. En el
conmutador, cree puertos lógicos y asocie las vNIC del nodo a ellos. Los puertos lógicos deben tener las siguientes etiquetas:
n etiqueta: <cluster_name>, ámbito: ncp/cluster
n etiqueta: <node_name>, ámbito: ncp/node_name
El valor de <cluster_name> debe coincidir con el valor de la opción cluster de la sección [coe] de ncp.ini.
Bloques de IP para los pods de Kubernetes
Inicie sesión en NSX Manager y desplácese hasta Redes > IPAM para crear uno o varios bloques de IP.
Especifique el bloque de IP en formato CIDR
Especifique bloques de IP de pods de Kubernetes configurando la opción container_ip_blocks en la sección [nsx_v3] de ncp.ini.
También puede crear bloques de IP específicamente para espacios de nombres que no sean SNAT.
Especifique bloques de IP que no sean SNAT configurando 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.
Nota Cuando cree un bloque de IP, el prefijo no debe tener una longitud superior al valor del parámetro subnet_prefix en el archivo de configuración de NCP ncp.ini.
Grupo de IP de SNAT
El grupo de IP se emplea para asignar las direcciones IP que se usarán para traducir las IP de los pods mediante reglas SNAT y para exponer las controladoras de entrada a través de las reglas SNAT/DNAT, igual que las IP flotantes de OpenStack. Estas direcciones IP también se denominan "IP externas".
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.
Inicie sesión en NSX Manager y desplácese hasta Inventario > Grupos > Grupos de direcciones IP para crear un grupo o buscar uno existente.
Especifique grupos de IP para SNAT configurando la opción external_ip_pools en la sección [nsx_v3] de ncp.ini.
También puede configurar SNAT para un determinado servicio agregando una anotación en el servicio.
Por ejemplo,
apiVersion: v1 kind: Service metadata:
name: svc-example annotations:
ncp/snat_pool: <external IP pool ID or name>
selector:
app: example ...
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. Tenga en cuenta lo siguiente:
n El grupo de direcciones IP que ncp/snat_pool especifica ya debe existir en NSX-T Data Center antes de configurar el servicio. A partir de NCP 2.3.1, el grupo de direcciones IP debe tener la etiqueta {"ncp/owner": cluster:<cluster>}.
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.
Puede especificar el espacio de nombres al que es posible asignar direcciones IP del grupo de direcciones IP de SNAT agregando la siguiente etiqueta al grupo de direcciones IP.
n En el ámbito ncp/owner, la etiqueta debe ser ns:<namespace_UUID>.
Puede obtener el UUID de espacio de nombres con uno de los siguientes comandos:
oc get ns -o yaml
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 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 o se reinicie NCP.
n La etiqueta de propietario de espacio de nombres es opcional. Sin esta etiqueta, se pueden asignar direcciones IP del grupo de direcciones IP de SNAT a cualquier espacio de nombres.
(Opcional) Secciones del 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, inicie sesión en NSX Manager, desplácese hasta 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.
Crear y configurar un enrutador lógico de nivel 0
El enrutador lógico de nivel 0 conecta los nodos Kubernetes a redes externas.
Procedimiento
1 Desde un explorador, inicie sesión en NSX Manager mediante https://dirección-ip-nsx-manager.
2 Desplácese hasta Redes > Enrutamiento > Enrutadores y haga clic en Agregar > Enrutador de nivel 0.
3 Introduzca un nombre y, si lo desea, una descripción.
4 Seleccione un clúster de Edge ya creado en el menú desplegable para respaldar este enrutador lógico de nivel 0.
5 Seleccione un modo de alta disponibilidad.
Seleccione activo-en espera.
6 Haga clic en Guardar.
El nuevo enrutador lógico aparecerá en forma de vínculo.
7 Haga clic en el vínculo del enrutador lógico.
8 Haga clic en Enrutamiento > Redistribución de rutas.
9 Haga clic en Agregar para agregar un nuevo criterio de redistribución.
Para los orígenes, en una topología enrutada (no NAT), seleccione NSX estático. En una topología NAT, seleccione NAT de nivel 0.
10 Haga clic en Guardar.
11 Haga clic en el enrutador recién creado.
12 Haga clic en Configuración > Puertos del enrutador.
13 Haga clic en Agregar para agregar un puerto de enlace ascendente.
14 Seleccione un nodo de transporte.
15 Seleccione el conmutador lógico que creó previamente.
16 Especifique una dirección IP de la red externa.
17 Haga clic en Guardar.
El nuevo enrutador lógico aparecerá en forma de vínculo.
Instalar NCP en un entorno de
OpenShift 3
Este capítulo describe cómo instalar y configurar NSX-T Container Plug-in (NCP) y OpenShift.
Este capítulo incluye los siguientes temas:
n Implementar máquinas virtuales de OpenShift
n Preparar el archivo de hosts de Ansible
n Instalar NCP y OpenShift mediante un solo playbook
n Instalar el complemento CNI, OVS y la imagen de Docker de NCP
n Instalar OpenShift Container Platform
n Ejecutar NCP y el agente del nodo de NSX.
n Notas de la instalación
Implementar máquinas virtuales de OpenShift
Antes de instalar NSX-T Container Plug-in, OpenShift debe estar instalado. Debe implementar, al menos, una máquina virtual principal.
Para obtener más información, consulte https://docs.openshift.com.
Pasos siguientes
Prepare el archivo de hosts de Ansible. Consulte Preparar el archivo de hosts de Ansible.
Preparar el archivo de hosts de Ansible
El archivo de hosts de Ansible define los nodos del clúster de OpenShift.
Procedimiento
1 Clone el repositorio GitHub de NCP en https://github.com/vmware/nsx-integration-for-openshift. El archivo hosts está en el directorio ansible openshift-nsx. El archivo hosts se debe conservar en el directorio openshift-ansible-nsx. En algunos playbooks se da por hecho que esta es la ruta del archivo hosts.
2 En las secciones [principales] y [nodos], especifique los nombres de host y las direcciones IP de las máquinas virtuales de OpenShift. Por ejemplo,
[masters]
admin.rhel.osmaster ansible_ssh_host=101.101.101.4
[single_master]
admin.rhel.osmaster ansible_ssh_host=101.101.101.4
[nodes]
admin.rhel.osmaster ansible_ssh_host=101.101.101.4 openshift_ip=101.101.101.4 openshift_schedulable=true openshift_hostname=admin.rhel.osmaster
admin.rhel.osnode ansible_ssh_host=101.101.101.5 openshift_ip=101.101.101.5 openshift_hostname=admin.rhel.osnode
[etcd]
[OSEv3:children]
masters nodes etcd
Tenga en cuenta que openshift_ip identifica la IP interna del clúster y es necesario establecer su configuración si la interfaz que se va a usar no es la predeterminada. Las funciones de ncp-related usan la variable single_master desde el nodo principal para realizar algunas tareas solo una vez, como, por ejemplo, la configuración de los recursos del plano de administración de
NSX-T Data Center.
3 Configure el acceso SSH para que se pueda acceder a todos los nodos sin contraseña desde el nodo en el que se ejecuta la función Ansible (suele ser el nodo principal):
ssh-keygen
ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]
4 Actualice la sección [OSEv3:vars]. Puede encontrar información sobre todos los parámetros en la documentación de OpenShift Container Platform para una instalación avanzada (busque "instalación avanzada" en https://docs.openshift.com). Por ejemplo,
# Set the default route fqdn
openshift_master_default_subdomain=apps.corp.local
os_sdn_network_plugin_name=cni openshift_use_openshift_sdn=false openshift_node_sdn_mtu=1500
# If ansible_ssh_user is not root, ansible_become must be set to true ansible_become=true
openshift_master_default_subdomain
This is the default subdomain used in the OpenShift routes for External LB
Set to 'cni' for the NSX Integration
openshift_use_openshift_sdn
Set to false to disable the built-in OpenShift SDN solution
openshift_hosted_manage_router
Set to false to disable creation of router during installation. The router has to be manually started after NCP and nsx-node-agent are running.
openshift_hosted_manage_registry
Set to false to disable creation of registry during installation. The registry has to be manually started after NCP and nsx-node-agent are running.
deployment_type
Set to openshift-enterprise
openshift_hosted_manage_registry
Set to false to disable auto creation of registry
openshift_hosted_manage_router
Set to false to disable auto creation of router
openshift_enable_service_catalog
Set to false to disable service_catalog
(For OpenShift 3.9 only) skip_sanity_checks Set to true
(For OpenShift 3.9 only) openshift_web_console_install Set to false
5 Compruebe que tenga conectividad en todos los hosts:
ansible OSEv3 -i /PATH/TO/HOSTS/hosts -m ping
El resultado debe ser similar al siguiente. Si no es así, solucione el problema de conectividad.
openshift-node1 | SUCCESS => { "changed": false,
"ping": "pong"
}
openshift-master | SUCCESS => { "changed": false,
"ping": "pong"
}
Pasos siguientes
Instale el complemento CNI y OVS. Consulte Instalar el complemento CNI, OVS y la imagen de Docker de NCP.
Instalar NCP y OpenShift mediante un solo playbook
NCP y OpenShift se pueden instalar mediante un solo playbook o realizando la instalación en pasos independientes.
El playbook de Ansible único install.yaml lleva a cabo las siguientes tareas:
n Preparación de NCP
n Instalación de OpenShift
n Instalación de NCP
Si lo prefiere, puede instalar NCP y OpenShift siguiendo las instrucciones de las secciones Instalar el complemento CNI, OVS y la imagen de Docker de NCP y Instalar OpenShift Container Platform.
Antes de ejecutar el playbook install.yaml, configure los parámetros obligatorios y opcionales para las funciones de playbook ncp_prep y ncp. Estos parámetros se describen en Instalar el complemento CNI, OVS y la imagen de Docker de NCP.
El siguiente comando ejecuta el playbook:
ansible-playbook -i /PATH/TO/HOSTS/hosts install.yaml
Instalar el complemento CNI, OVS y la imagen de Docker de NCP
El complemento de la interfaz de red del contenedor (Container Network Interface, CNI), Open vSwitch (OVS) y la imagen de Docker de NCP se deben instalar en los nodos de OpenShift. La instalación se realiza ejecutando un playbook de Ansible.
Nota Este paso no es necesario si NCP y OpenShift se instalan mediante un solo playbook. Consulte Instalar NCP y OpenShift mediante un solo playbook.
El playbook contiene instrucciones para configurar los recursos de NSX-T de los nodos. También puede configurar los recursos de NSX-T Data Center de forma manual, como se describe en
Capítulo 2Configurar recursos de NSX-T. El parámetro perform_nsx_config indica si desea configurar los recursos cuando se ejecuta el playbook.
Procedimiento
1 Actualice los valores de los parámetros roles/ncp_prep/default/main.yaml y
roles/nsx_config/default/main.yaml, incluidas las URL desde donde se pueden descargar el RPM del complemento CNI y el RPM del módulo kernel correspondiente. Además, uplink_port es el nombre de la VNIC del puerto de enlace ascendente de la máquina virtual del nodo. El resto de las variables corresponden a la configuración del plano de administración de NSX-T Data Center.
Estos son los parámetros que se deben especificar:
n perform_nsx_config: si se realiza la configuración de los recursos. Configúrela como falso si la configuración se establecerá de forma manual y no se ejecutará el script nsx_config.
n nsx_manager_ip: la IP de NSX Manager
n nsx_edge_cluster_name: el nombre del clúster de Edge que usará el enrutador de nivel 0
n nsx_transport_zone_name: nombre de la zona de transporte superpuesta
n os_node_name_list: lista de nombres de nodo separados por comas Por ejemplo, nodo1, nodo2, nodo3
n subnet_cidr: dirección CIDR para el administrador de IP que se asignará a br-int en el nodo
n vc_host: dirección IP de vCenter Server
n vc_user: nombre de usuario del administrador de vCenter Server
n vc_password: contraseña del administrador de vCenter Server
n vms: lista de nombres de máquinas virtuales separados por comas. El orden debe coincidir con os_node_name_list.
Los siguientes parámetros tienen valores predeterminados. Se pueden modificar como sea necesario.
n nsx_t0_router_name: nombre del enrutador lógico de nivel 0 del clúster. Valor predeterminado:
t0
n pod_ipblock_name: nombre del bloque de IP de los pods. Valor predeterminado: podIPBlock
n pod_ipblock_cidr: dirección CIDR de este bloque de IP. Valor predeterminado:
172.20.0.0/16
n snat_ippool_name: nombre del bloque de IP para SNAT. Valor predeterminado: externalIP
n snat_ippool_cidr: dirección CIDR de este bloque de IP. Valor predeterminado:
172.30.0.0/16
n start_range: la dirección IP de inicio de CIDR especificada para este grupo de IP. Valor predeterminado: 172.30.0.1
n end_range: la dirección IP final de CIDR especificada para este grupo de IP. Valor predeterminado: 172.30.255.254
n os_cluster_name: nombre del clúster de OpenShift. Valor predeterminado: occl-one
n nsx_node_ls_name: nombre del conmutador lógico conectado a los nodos. Valor predeterminado: node_ls
n nsx_node_lr_name: nombre del enrutador lógico del conmutador node_ls. Valor predeterminado: node_lr
El playbook nsx-config permite crear únicamente un grupo de IP y un bloque de IP. En caso de querer más, deberá crearlos manualmente.
2 Cambie al directorio openshift-ansible-nsx y ejecute la función ncp_prep.
ansible-playbook -i /PATH/TO/HOSTS/hosts ncp_prep.yaml
El playbook contiene instrucciones para realizar las siguientes acciones:
n Descargar el archivo de instalación del complemento CNI.
El nombre de archivo es nsx-cni-1.0.0.0.0.xxxxxxx-1.x86_64.rpm, donde xxxxxxx es el número de compilación.
n Instalar el archivo de instalación del complemento CNI.
El complemento se instala en /opt/cni/bin. El archivo de configuración de CNI 10.net.conf se copia a /etc/cni/net.d. El rpm también instalará el archivo de
configuración /etc/cni/net.d/99-loopback.conf del complemento de bucle invertido.
n Descargar e instalar los archivos de instalación de OVS.
Los archivos son openvswitch-2.9.1.xxxxxxx-1.x86_64.rpm y openvswitch- kmod-2.9.1.xxxxxxx-1.el7.x86_64.rpm, donde xxxxxxx es el número de compilación.
n Cree la instancia br-int si aún no se creó.
# ovs-vsctl add-br br-int
n Agregue la interfaz de red (node-if) que está conectada al conmutador lógico del nodo en br-int.
n Asegúrese de que br-int y node-if link estén activos.
# ip link set br-int up # ip link set <node-if> up
n Actualice el archivo de configuración de red para garantizar que la interfaz de red esté activa después de un reinicio.
n Descargar el archivo tar de NCP y cargar la imagen de Docker desde el archivo tar.
n Descargar el archivo yaml ncp-rbac y cambiar la apiVersion a v1.
n Cree una topología lógica y los recursos relacionados en NSX-T Data Center, y etiquételos para que NCP pueda identificarlos.
n Actualice ncp.ini con la información de recursos de NSX-T Data Center.
Pasos siguientes
Instalar OpenShift Container Platform. Consulte Instalar OpenShift Container Platform.
Instalar OpenShift Container Platform
OpenShift Container Platform (OCP) es un producto plataforma como servicio (PaaS) que integra Docker y Kubernetes.
Nota Este paso no es necesario si NCP y OpenShift se instalan mediante un solo playbook. Consulte Instalar NCP y OpenShift mediante un solo playbook.
Para obtener información sobre cómo instalar OCP, consulte https://docs.openshift.com.
Pasos siguientes
Ejecute NCP y el agente del nodo de NSX. Consulte Ejecutar NCP y el agente del nodo de NSX..
Ejecutar NCP y el agente del nodo de NSX.
Configure y ejecute NCP y el agente del nodo de NSX.
Procedimiento
1 Edite roles/ncp/defaults/main.yaml y especifique la IP del servidor de la API de OpenShift, la IP de NSX Manager y las URL para descargar el archivo yaml ReplicationController de NCP y el archivo yaml nsx-node-agent de DaemonSet.
2 Desde el directorio openshift-ansible-nsx, ejecute la función de ncp:
ansible-playbook -i /PATH/TO/HOSTS/hosts ncp.yaml
La función ncp realiza los siguientes pasos:
n Comprobar si existe un proyecto nsx-system y crear uno si no es así.
oc new-project nsx-system
n Descargar el archivo yaml ncp-rbac y cambiar la apiVersion a v1.
n Crear la cuenta de servicio para el pod de NCP, crear una función de clúster que especifique los recursos a los que puede acceder el NCP y enlazar la función de clúster con la cuenta de servicio del NCP.
n Crear la cuenta de servicio para el pod nsx-node-agent, crear una función de clúster que especifique los recursos a los que puede acceder el agente del nodo y enlazar la función de clúster con la cuenta de servicio del agente del nodo.
oc apply -f /tmp/ncp-rbac.yml
n Obtener el token asociado a las cuentas de servicio anteriores y almacenarlo en /etc/nsx- ujo/<cuenta_servicio>_token:
secret=`kubectl get serviceaccount ncp-svc-account -o yaml | grep -A1 secrets | tail -n1 | awk {'print $3'}`
kubectl get secret $secret -o yaml | grep 'token:' | awk {'print $2'} | base64 -d > /etc/nsx- ujo/ncp_token
secret=`kubectl get serviceaccount nsx-node-agent-svc-account -o yaml | grep -A1 secrets | tail -n1 | awk {'print $3'}`
kubectl get secret $secret -o yaml | grep 'token:' | awk {'print $2'} | base64 -d > /etc/nsx- ujo/node_agent_token
n Descargar el archivo yaml de SecurityContextConstraint (SCC) ncp-os-scc.yml para NCP y crear la instancia de SCC basada en el archivo yaml.
oc apply -f ncp-os-scc.yml
El archivo yaml de SCC especifica el tipo de SELinux como spc_t para garantizar que NCP/nsx- node-agent tenga permisos de acceso en SELinux. Esto quiere decir lo siguiente:
seLinuxContext:
seLinuxOptions:
type: spc_t
En el archivo yaml de SCC, en seLinuxOptions de seLinuxContext, el nivel de control de acceso basado en etiquetas de SELinux se establece como s0:c0:c1023 para permitir que ncp/node- agent acceda a destinos desde diferentes categorías de archivo.
n Agregar SCC al usuario que crea los pods de agente de nodo de NCP y NSX. Por ejemplo, para agregar SCC al usuario predeterminado en el proyecto actual:
oc adm policy add-scc-to-user ncp-scc -z default
n Agregar SCC a las cuentas de servicio de agente de nodo de NCP y NSX:
oc adm policy add-scc-to-user ncp-scc -z ncp-svc-account
oc adm policy add-scc-to-user ncp-scc -z nsx-node-agent-svc-account
n Descargar los archivos yaml para ReplicationController (RC) de NCP y DaemonSet (DS) de nsx- node-agent, y actualizar ConfigMap.
n Descargar y cargar la imagen de NCP (nsx-node-agent usa la misma imagen).
n Configurar la cuenta del servicio y establezca el SecurityContextConstraint necesario para NCP y nsx_node_agent.
n Crear el ReplicationController de NCP y el DaemonSet de nsx-node-agent.
Nota NCP abre conexiones HTTP persistentes con el servidor de API de Kubernetes para inspeccionar los eventos de ciclo de vida de los recursos de Kubernetes. Si un error del servidor de API o un error de red provoca que las conexiones TCP de NCP queden obsoletas, debe reiniciar NCP para que se puedan restablecer las conexiones con el servidor de API. De lo contrario, NCP no detectará los nuevos eventos.
Notas de la instalación
Antes de configurar OpenShift y NCP, tenga en cuenta la siguiente información.
n Un pod no puede tener más de 11 etiquetas y un espacio de nombres no debe tener más de 12.
n NCP excluirá las etiquetas que se agregan para el uso interno de OpenShift, por ejemplo, una etiqueta con el prefijo openshift.io en la clave. Por lo tanto, los usuarios no verán las etiquetas creadas de los recursos de NSX relacionados. A continuación presentamos una lista de prefijos de etiquetas que usa OpenShift. No debe usar ninguna clave de etiqueta que comience por uno de los siguientes valores:
openshift.io pod-template
n Los nodos necesitarán acceder a los pods, por ejemplo, para realizar comprobaciones de estado de Kubelet. Asegúrese de que la interfaz de administración del host pueda acceder a la red de pods.
n 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, si SCC está restringida y es anyuid, no se otorga NET_ADMIN. Tenga en cuenta que existen ciertas SCC que habilitan explícitamente NET_ADMIN o ejecutan el pod en modo privilegiado. Además, en los contenedores en los que no confía, cree una SCC independiente, basada, por ejemplo, en una SCC anyuid, con la función NET_RAW eliminada. Esto se puede hacer agregando NET_RAW a la lista "requiredDropCapabilities" de la definición de SCC.
n Permita el acceso raíz a los pods y los contenedores (solo para hacer pruebas). Los comandos que aparecen a continuación requerirán acceso raíz en todos los pods del proyecto oc en el que tiene la sesión iniciada en este momento.
oc new-project test-project oc project test-project
oc adm policy add-scc-to-user anyuid -z default
n Configure (agregue) el registro de OpenShift.
oc login -u system:admin -n default
oc adm registry --service-account=registry --config=/etc/origin/master/admin.kubeconfig
n Eliminar el registro de OpenShift
oc login -u system:admin -n default
oc delete svc/docker-registry dc/docker-registry
n No existe ninguna regla del firewall IPtables que permita solicitudes DNS desde los contenedores de puente de Docker predeterminados al proceso dnsmasq del nodo. Debe abrirse manualmente.
Edite /etc/sysconfig/iptables y agregue las siguientes reglas en la parte inferior del archivo, antes de COMMIT:
-A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT -A OS_FIREWALL_ALLOW -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT COMMIT
n Reinicie iptables, docker y origin-node (se reinician kube-proxy y kubelet).
systemctl restart iptables systemctl restart docker systemctl restart origin-node
n Para que OpenShift funcione, es necesario que el registro docker interno de OpenShift pueda usar protocolos que no sean TLS. Normalmente, el instalador OpenShift Ansible debe agregar esto automáticamente, pero parece que en estos momentos no está funcionando.
Edite /etc/sysconfig/docker y agregue:
INSECURE_REGISTRY='--insecure-registry 172.30.0.0/16'
n Reinicie Docker.
systemctl restart docker
n La compatibilidad de NCP para las directivas de red es la misma que la compatibilidad que proporciona Kubernetes y depende de la versión de Kubernetes que utilice OpenShift.
n En OpenShift 3.9, las cláusulas de reglas en la directiva de red pueden contener como máximo un selector de namespaceSelector, podSelector y ipBlock.
n El servidor de la API de Kubernetes no realiza una validación de una especificación de directiva de red. Es posible crear una directiva de red que no sea válida. NCP rechazará dicha directiva de red.
Aunque actualice la directiva de red para que sea válida, NCP no la procesará. Debe eliminar la directiva de red y volver a crear una con una especificación válida.
n Determinadas versiones de Kubernetes tienen un problema relacionado con subPath (consulte https://github.com/kubernetes/kubernetes/issues/61076). Si la versión de OpenShift no contiene una solución para este problema, se producirá un error en la creación del pod NCP y aparecerá el mensaje CreateContainerConfigError: no se pudo preparar subruta de acceso para volumeMount. Puede solucionar este problema si elimina el uso de subPath desde el archivo yaml NCP. Específicamente, elimine la línea que contenga subPath: ncp.ini y reemplace la
configuración de volumes con lo siguiente:
volumes:
- name: config-volume
# ConfigMap nsx-ncp-config is expected to supply ncp.ini configMap:
name: nsx-ncp-config items:
- key: ncp.ini path: ncp.ini
Un efecto secundario de este cambio es que el directorio /etc/nsx-ujo completo se vuelve de solo lectura. Como resultado, la conexión con NSX-T mediante certificado y clave privada no funcionará, ya que NCP no podrá crear un archivo temporal en /etc/nsx-ujo para mover el certificado y la clave privada a un solo archivo.
n Si ejecuta el clúster de OpenShift 3.10 o va a actualizar a este, tenga en cuenta lo siguiente:
n Debe especificar la configuración de grupos de nodos específicos del clúster de OpenShift 3.10.
Debe facilitarse la configuración del mapa de configuración de nodos en el archivo de hosts de inventario.
n Todos los hosts definidos en el grupo [nodes] del archivo de hosts de inventario se deben asignar a un nombre de grupo de nodos.
n La actualización del clúster de OpenShift a partir de un playbook de Ansible puede provocar la pérdida de la red. Asegúrese de agregar la revisión (https://github.com/openshift/openshift- ansible/pull/8016/files#diff-2386e21861da3f95091dbb27d72ca366) en el repositorio openshift- ansible para quitar la detención o la desinstalación de paquetes de Open vSwitch.
n A partir de OpenShift 3.10, kube-proxy se mueve del servicio openshift-node a DaemonSet. Ya no se inicia de forma predeterminada. Realice los siguientes pasos para iniciar kube-proxy de forma manual (se asume que se clonó el repositorio openshift-ansible):
n Vaya al directorio openshift-ansible y en [defaults] defina lo siguiente:
library = roles/lib_utils/library/
n Cree un archivo create_proxy.yaml en el directorio de playbooks con las siguientes entradas:
- import_playbook: byo/openshift_facts.yml - hosts: masters
run_once: True roles:
- kube_proxy_and_dns
n Ejecute el playbook:
ansible-playbook -i hosts playbooks/create_proxy.yaml
Verá mensajes de error que indican errores en algunas operaciones. Puede ignorar estos mensajes. Puede comprobar el resultado ejecutando el comando oc get po --all- namespaces.
Instalar NCP en un entorno sin
sistema operativo 4
Los pasos para instalar NSX-T Container Plug-in (NCP) en un entorno sin sistema operativo son similares a los pasos para instalar NCP en un entorno que lo tiene. En esta sección se describen los pasos que son diferentes.
Este capítulo incluye los siguientes temas:
n Instalar el complemento CNI de NSX-T Data Center
n Configurar redes de NSX-T Data Center para nodos de OpenShift
n Instalar el agente del nodo de NSX
n ConfigMap para ncp.ini in nsx-node-agent-ds.yml
n Instalar NSX-T Container Plug-in
n ConfigMap para ncp.ini en ncp-rc.yml
Instalar el complemento CNI de NSX-T Data Center
El complemento CNI de NSX-T Data Center debe instalarse en los nodos de OpenShift.
Procedimiento
1 Descargue el archivo de instalación adecuado para la distribución de Linux.
El nombre de archivo es nsx-cni-1.0.0.0.0.xxxxxxx-1.x86_64.rpm, donde xxxxxxx es el número de compilación.
2 Instale el archivo rpm que descargó en el paso 1.
El complemento se instala en /opt/cni/bin. El archivo de configuración de CNI 10.net.conf se copia a /etc/cni/net.d. El rpm también instalará el archivo de
configuración /etc/cni/net.d/99-loopback.conf del complemento de bucle invertido.
Configurar redes de NSX-T Data Center para nodos de OpenShift
Esta sección describe cómo configurar las redes de NSX-T Data Center para los nodos principales y de cálculo de OpenShift.
Cada nodo se debe registrar con NSX Manager como el tipo de sistema operativo RHEL Container. La interfaz de administración del nodo puede utilizarse para unirse al clúster de OpenShift y puede estar en el tejido de NSX-T Data Center o no. Las demás interfaces ofrecen redes para los pods y deben estar en el tejido de NSX-T Data Center.
El nodo de transporte correspondiente debe tener las siguientes etiquetas:
{'ncp/node_name': '<node_name>'}
{'ncp/cluster': '<cluster_name>'}
Para identificar el nodo de transporte de un nodo de OpenShift, desplácese a Tejido > Nodos en la interfaz gráfica de usuario de NSX Manager.
Si el nombre del nodo de OpenShift cambia, debe actualizar la etiqueta ncp/node_name y reiniciar NCP.
Puede usar el siguiente comando para obtener los nombres del nodo:
oc get nodes
Si agrega un nodo a un clúster mientras NCP se está ejecutando, debe agregar las etiquetas al nodo de transporte antes de ejecutar el comando oc cluster add. 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 nodo de transporte.
n Reinicie NCP.
Instalar el agente del nodo de NSX
El agente del nodo de NSX es un DaemonSet en el que cada pod ejecuta dos contenedores. Uno de los contenedores ejecuta el agente del nodo de NSX, cuya mayor responsabilidad es administrar las interfaces de red de los contenedores. Interactúa con el complemento CNI y el servidor de la API de Kubernetes. El otro contenedor ejecuta kube-proxy de NSX, cuya única responsabilidad es implementar la abstracción del servicio de Kubernetes traduciendo las IP de los clústeres en IP de pods. Implementa la misma funcionalidad que el kube-proxy ascendente.
Procedimiento
1 Descargue la imagen Docker de NCP.
El nombre de archivo es nsx-ncp-xxxxxxx.tar, donde xxxxxxx es el número de compilación.
2 Descargue la plantilla yaml de DaemonSet del agente del nodo de NSX.
El nombre de archivo es nsx-node-agent-ds.yml. Puede editar este archivo o usarlo como ejemplo para su propio archivo de plantilla.
3 Cargue la imagen Docker de NCP al registro de imágenes.
docker load -i <tar file>
4 Edite nsx-node-agent-ds.yml.
Cambie el nombre de la imagen a la que se cargó.
Realice los siguientes cambios:
[coe]
node_type = 'BAREMETAL' ...
[nsx_node_agent]
ovs_bridge = 'nsx-managed'
Quite la marca de comentario de las siguientes líneas:
securityContext:
capabilities:
add:
- NET_ADMIN - SYS_ADMIN - SYS_PTRACE - DAC_READ_SEARCH # For BMC usecase - DAC_OVERRIDE volumeMounts:
…
# mount nestdb-sock for baremetal node - name: nestdb-sock
mountPath: /var/run/vmware/nestdb/nestdb-server.sock volumes:
…
# volume for baremetal node - name: nestdb-sock
hostPath:
path: /var/run/vmware/nestdb/nestdb-server.sock type: Socket
Nota En el archivo yaml, es necesario especificar que el ConfigMap que se generó para ncp.ini debe estar montado como un volumen ReadOnly. El archivo descargado yaml ya tiene esta especificación y no se debe cambiar.
5 Cree el DaemonSet del agente del nodo de NSX con el siguiente comando.
oc apply -f nsx-node-agent-ds.yml
ConfigMap para ncp.ini in nsx-node-agent-ds.yml
El archivo de yaml de ejemplo nsx-node-agent-ds.yml contiene un ConfigMap para el archivo de configuración ncp.ini del agente del nodo de NSX. Esta sección centrada en ConfigMap contiene parámetros que puede especificar para personalizar la instalación del agente del nodo.
El ejemplo nsx-node-agent-ds.yml que descargó tiene la siguiente información ncp.ini:
# ConfigMap for ncp.ini apiVersion: v1
kind: ConfigMap metadata:
name: nsx-node-agent-config labels:
version: v1 data:
ncp.ini: | [DEFAULT]
# Set to True to enable logging to stderr #use_stderr = True
# Set to True to send logs to the syslog daemon #use_syslog = False
# Enabler debug-level logging for the root logger. If set to True, the # root logger debug level will be DEBUG, otherwise it will be INFO.
#debug = True
# The log file path must be set to something like '/var/log/nsx-ujo/'. By # default, logging to file is disabled.
#log_dir = None
# Name of log file to send logging output to. If log_dir is set but log_file is # not, the binary name will be used, i.e., ncp.log, nsx_node_agent.log and # nsx_kube_proxy.log.
#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 [coe]
#
# Common options for Container Orchestrators #
# Container orchestrator adaptor to plug in # Options: kubernetes (default), openshift, pcf.
#adaptor = kubernetes
# Specify cluster for adaptor. It is a prefix of NSX resources name to # distinguish multiple clusters who are using the same NSX.
# This is also used as the tag of IP blocks for cluster to allocate # IP addresses. Different clusters should have different IP blocks.
#cluster = k8scluster
# Log level for the NCP operations. If set, overrides the level specified # for the root logger. Possible values are NOTSET, DEBUG, INFO, WARNING, # ERROR, CRITICAL
#loglevel=None
# Log level for the NSX API client operations. If set, overrides the level # specified for the root logger. Possible values are NOTSET, DEBUG, INFO, # WARNING, ERROR, CRITICAL
nsxlib_loglevel=INFO
# Once enabled, all projects in this cluster will be mapped to a NAT # topology in NSX backend
#enable_snat = True
# The type of container node. Possible values are HOSTVM, BAREMETAL.
node_type = BAREMETAL
[ha]
#
# NCP High Availability configuration options #
# 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 be less than this period. This # is done to ensure that the master instance will either confirm # liveness or fail before the timeout.
#master_timeout = 9
# 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 = 3
# Timeout duration in seconds for update to election resource. If the # update request does not complete before the timeout it will be
# aborted. Used for master heartbeats to ensure that the update finishes # or is aborted before the master timeout occurs.
#update_timeout = 3
[k8s]
#
# From kubernetes #
# IP address of the Kubernetes API Server. If not set, will try to # read and use the Kubernetes Service IP from environment variable # KUBERNETES_SERVICE_HOST.
#apiserver_host_ip = <ip_address>
# Port of the Kubernetes API Server.
# Set to 6443 for https. If not set, will try to
# read and use the Kubernetes Service port from environment # variable KUBERNETES_SERVICE_PORT.
#apiserver_host_port = <port>
# Specify a CA bundle file to use in verifying the Kubernetes API server # certificate. (string value)
#ca_file = <None>
ca_file = /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
# Full path of the Token file to use for authenticating with the k8s API server.
#client_token_file = <None>
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 certificate file to use for authenticating # with the k8s API server. It must be specified together with # "client_cert_file"
#client_private_key_file = <None>
# Log level for the kubernetes adaptor. If set, overrides the level specified # for the root logger. Possible values are NOTSET, DEBUG, INFO, WARNING, # ERROR, CRITICAL
#loglevel=None
[nsx_node_agent]
#
# Configuration for nsx_node_agent #
# Needs to mount node /proc to container if nsx_node_agent runs in a container.
# By default node /proc will be mounted to /host/proc, the prefix is /host.
# It should be the same setting with mounted path in the daemonset yaml file.
# Set the path to '' if nsx_node_agent is running as a process in minion node.
#proc_mount_path_prefix = /host
# The OVS bridge to configure container interface.
#ovs_bridge = br-int
[nsx_kube_proxy]
#
# Configuration for nsx_kube_proxy #
# The OVS uplink OpenFlow port where to apply the NAT rules to.
# If not specified, the port that gets assigned ofport=1 is used.
#ovs_uplink_port = <None>
Instalar NSX-T Container Plug-in
NSX-T Container Plug-in (NCP) se envía como una imagen de Docker. NCP debe ejecutarse en un nodo para los servicios de la infraestructura. No se recomienda ejecutar NCP en el nodo principal.
Procedimiento
1 Descargue la imagen Docker de NCP.
El nombre de archivo es nsx-ncp-xxxxxxx.tar, donde xxxxxxx es el número de compilación.
2 Descargue la plantilla yaml ReplicationController de NCP.
El nombre de archivo es ncp-rc.yml. Puede editar este archivo o usarlo como ejemplo para su propio archivo de plantilla.
3 Cargue la imagen Docker de NCP al registro de imágenes.
docker load -i <tar file>
4 Edite ncp-rc.yml.
Establezca el tipo de nodo como nativo.
[coe]
node_type = ‘BAREMETAL’
Cambie el nombre de la imagen a la que se cargó.
Especifique el parámetro nsx_api_managers. Esta versión admite un único clúster de nodo de Kubernetes y una única instancia de NSX Manager. Por ejemplo:
nsx_api_managers = 192.168.1.180
(Opcional) Especifique el parámetro ca_file en la sección [nsx_v3]. 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.
Especifique los parámetros nsx_api_cert_file y nsx_api_private_key_file para la autenticación con NSX-T Data Center.
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---
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---
Especifique el parámetro ingress_mode = nat si el controlador de entrada está configurado para ejecutarse en modo NAT.
De forma predeterminada, se utiliza el prefijo 24 para todas las subredes asignadas desde los bloques de IP para los conmutadores lógicos del pod. Para usar un tamaño de subred diferente, actualice la opción subnet_prefix en la sección [nsx_v3].
Nota En el archivo yaml, debe especificar que el ConfigMap que se generó para ncp.ini esté montado como un volumen ReadOnly. El archivo descargado yaml ya tiene esta especificación y no se debe cambiar.
5 Cree ReplicationController de NCP.
kubectl create -f ncp-rc.yml
Nota NCP abre conexiones HTTP persistentes con el servidor de API de Kubernetes para inspeccionar los eventos de ciclo de vida de los recursos de Kubernetes. Si un error del servidor de API o un error de red provoca que las conexiones TCP de NCP queden obsoletas, debe reiniciar NCP para que se puedan restablecer las conexiones con el servidor de API. De lo contrario, NCP no detectará los nuevos eventos.
Durante una actualización gradual de ReplicationController de NCP, no reinicie el host del contenedor. Si el host se reinicia por algún motivo, es posible que aparezcan dos pods de NCP en ejecución después del reinicio. En tal caso, realice las siguientes acciones:
n Elimine uno de los pods de NCP. No importa cuál. Por ejemplo,
oc delete pods <NCP pod name> -n nsx-system
n Elimine el espacio de nombres nsx-system. Por ejemplo,
oc delete -f ncp-rc.yml -n nsx-system
ConfigMap para ncp.ini en ncp-rc.yml
El archivo YAML de ejemplo ncp-rc.yml contiene un ConfigMap para el archivo de configuración ncp.ini. Esta sección centrada en ConfigMap contiene parámetros que debe especificar antes de instalar NCP, como se describe en la sección anterior.
El ejemplo ncp-rc.yml que descargó tiene la siguiente información ncp.ini:
# ConfigMap for ncp.ini apiVersion: v1
kind: ConfigMap metadata:
name: nsx-ncp-config labels:
version: v1 data:
ncp.ini: |
# Set to True to enable logging to stderr #use_stderr = True
# Set to True to send logs to the syslog daemon #use_syslog = False
# Enabler debug-level logging for the root logger. If set to True, the # root logger debug level will be DEBUG, otherwise it will be INFO.
#debug = True
# The log file path must be set to something like '/var/log/nsx-ujo/'. By # default, logging to file is disabled.
#log_dir = None
# Name of log file to send logging output to. If log_dir is set but log_file is # not, the binary name will be used, i.e., ncp.log, nsx_node_agent.log and # nsx_kube_proxy.log.
#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 [coe]
#
# Common options for Container Orchestrators #
# Container orchestrator adaptor to plug in # Options: kubernetes (default), openshift, pcf.
#adaptor = kubernetes
# Specify cluster for adaptor. It is a prefix of NSX resources name to # distinguish multiple clusters who are using the same NSX.
# This is also used as the tag of IP blocks for cluster to allocate # IP addresses. Different clusters should have different IP blocks.
#cluster = k8scluster
# Log level for the NCP operations. If set, overrides the level specified # for the root logger. Possible values are NOTSET, DEBUG, INFO, WARNING, # ERROR, CRITICAL
#loglevel=None
# Log level for the NSX API client operations. If set, overrides the level # specified for the root logger. Possible values are NOTSET, DEBUG, INFO, # WARNING, ERROR, CRITICAL
nsxlib_loglevel=INFO
# Once enabled, all projects in this cluster will be mapped to a NAT # topology in NSX backend
#enable_snat = True
# The type of container node. Possible values are HOSTVM, BAREMETAL.
node_type = BAREMETAL
[ha]
#
# NCP High Availability configuration options #
# 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 be less than this period. This # is done to ensure that the master instance will either confirm # liveness or fail before the timeout.
#master_timeout = 9
# 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 = 3
# Timeout duration in seconds for update to election resource. If the # update request does not complete before the timeout it will be
# aborted. Used for master heartbeats to ensure that the update finishes # or is aborted before the master timeout occurs.
#update_timeout = 3
[k8s]
#
# From kubernetes #
# IP address of the Kubernetes API Server. If not set, will try to # read and use the Kubernetes Service IP from environment variable # KUBERNETES_SERVICE_HOST.
#apiserver_host_ip = <ip_address>
# Port of the Kubernetes API Server.
# Set to 6443 for https. If not set, will try to
# read and use the Kubernetes Service port from environment # variable KUBERNETES_SERVICE_PORT.
#apiserver_host_port = <port>
# Specify a CA bundle file to use in verifying the Kubernetes API server # certificate. (string value)
#ca_file = <None>
ca_file = /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
# Full path of the Token file to use for authenticating with the k8s API server.
#client_token_file = <None>
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 certificate file to use for authenticating # with the k8s API server. It must be specified together with
# "client_cert_file"
#client_private_key_file = <None>
# Log level for the kubernetes adaptor. If set, overrides the level specified # for the root logger. Possible values are NOTSET, DEBUG, INFO, WARNING, # ERROR, CRITICAL
#loglevel=None
# Specify how ingress controllers are expected to be deployed. Possible values:
# hostnetwork or nat. NSX will create NAT rules only in the second case.
#ingress_mode = hostnetwork
[nsx_v3]
#
# From nsx #
# IP address of one or more NSX managers separated by commas. The IP address # should be of the form (list value):
# <ip_address1>[:<port1>],<ip_address2>[:<port2>],...
# HTTPS will be used for communication with NSX. If port is not provided, # port 443 will be used.
#nsx_api_managers = <ip_address>
# If true, the NSX Manager server certificate is not verified. If false the CA # bundle specified via "ca_file" will be used or if unsest the default system # root CAs will be used. (boolean value)
#insecure = False
# 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 system root CAs will be # used to verify the server certificate. (list value)
#ca_file = <None>
# Path to NSX client certificate file. If specified, the nsx_api_user and # nsx_api_passsword options will be ignored. This option 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_passsword options will be ignored. This option must be specified # along with "nsx_api_cert_file" option.
#nsx_api_private_key_file = <None>
# The time in seconds before aborting a HTTP connection to a NSX manager.
# (integer value) #http_timeout = 10
# The time in seconds before aborting a HTTP read response from a NSX manager.
# (integer value) #http_read_timeout = 180
# Maximum number of times to retry a HTTP connection. (integer value) #http_retries = 3
