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

Resultados

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:

  • Elimine uno de los pods de NCP. No importa cuál. Por ejemplo,

    oc delete pods <NCP pod name> -n nsx-system
  • Elimine el espacio de nombres nsx-system. Por ejemplo,

    oc delete -f ncp-rc.yml -n nsx-system