NSX 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. (opcional) Descargue la plantilla yaml para la definición del recurso personalizado del objeto NSXError.
    El nombre del archivo es nsx-error-crd.yaml.
  5. (opcional) Cree el recurso personalizado.
        kubectl create -f nsx-error-crd.yaml
  6. Edite ncp-rc.yml.
    Cambie el nombre de la imagen a la que se cargó.

    Especifique el parámetro nsx_api_managers. Puede especificar la dirección IP de un único NSX Manager, las direcciones IP (separadas por comas) de los tres NSX Managers en un clúster de NSX Manager, o la dirección IP virtual de un clúster de NSX Manager. Por ejemplo:

        nsx_api_managers = 192.168.1.180
    or
        nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183

    (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. Si especifica una dirección IP para nsx_api_managers, especifique un archivo de CA. Si especifica tres direcciones IP para nsx_api_managers, puede especificar uno o tres archivos de CA. Si especifica un archivo de CA, se utilizará para los tres administradores. Si especifica tres archivos de CA, cada uno se utilizará para la dirección IP correspondiente en nsx_api_managers. Por ejemplo,

        ca_file = ca_file_for_all_mgrs
    or
        ca_file = ca_file_for_mgr1,ca_file_for_mgr2,ca_file_for_mgr3

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

    HA (alta disponibilidad) está habilitada de forma predeterminada. Puede deshabilitar HA con la siguiente especificación:
    [ha]
    enable = False
    (Opcional) Habilita la creación de informes de errores mediante NSXError en ncp.ini. Este ajuste está deshabilitado de forma predeterminada.
    [nsx_v3]
    enable_nsx_err_crd = True
    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.
  7. 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, puede que aparezcan dos pods de NCP que se ejecutan tras la actualización gradual en las siguientes situaciones:
  • Se reinicia el host de contenedor durante la actualización gradual.
  • Inicialmente se produce un error en la actualización gradual debido a que la nueva imagen no existe en un nodo de Kubernetes. Se descarga la imagen, vuelve a ejecutarse la actualización gradual y esta se realiza correctamente.
Haga lo siguiente si se muestran dos pods de NCP en ejecución:
  • Elimine uno de los pods de NCP. No importa cuál. Por ejemplo,
    kubectl delete pods <NCP pod name> -n nsx-system
  • Elimine ReplicationController de NCP. Por ejemplo,
    kubectl delete -f ncp-rc.yml -n nsx-system