Antes de instalar OpenShift 4, debe actualizar algunos archivos de configuración de NCP.

Los archivos YAML se incluyen en el archivo de descarga de NCP disponible en download.vmware.com. Puede ir a https://github.com/vmware/nsx-container-plugin-operator/releases, buscar la versión del Operator correspondiente (por ejemplo, v3.1.1) y descargar openshift4.tar.gz.

Los siguientes archivos se encuentran en la carpeta nsx-container-plugin-operator/deploy:
  • configmap.yaml: actualice este archivo con la información de NSX-T.
  • operator.yaml: especifique la ubicación de la imagen de NCP en este archivo.
  • namespace.yaml: especificación del espacio de nombres para el Operator. No edite el archivo.
  • role_binding.yaml: la especificación de enlace de función del Operator. No edite el archivo.
  • role.yaml: la especificación de rol para el Operator. No edite el archivo.
  • service_account.yaml: la especificación de la cuenta de servicio del Operator. No edite el archivo.
  • lb-secret.yaml: secreto para el certificado de equilibrador de carga de NSX-T predeterminado.
  • nsx-secret.yaml: secreto para la autenticación basada en certificados en NSX-T. Se utiliza en lugar de nsx_api_user y nsx_api_password en configmap.yaml.
  • operator.nsx.vmware.com_ncpinstalls_crd.yaml: definición de recursos del cliente propiedad del Operator.
  • operator.nsx.vmware.com_v1_ncpinstall_cr.yaml: recurso de cliente propiedad del Operator.
En el siguiente archivo configmap.yaml de ejemplo, se muestra una configuración básica. Consulte configmap.yaml en la carpeta implementar para ver más opciones. Debe especificar los valores de los siguientes parámetros de acuerdo con su entorno:
  • clúster
  • nsx_api_managers
  • nsx_api_user
  • nsx_api_password
  • external_ip_pools
  • tier0_gateway
  • overlay_tz
  • edge_cluster
  • apiserver_host_ip
  • apiserver_host_port
kind: ConfigMap 
metadata: 
  name: nsx-ncp-operator-config 
  namespace: nsx-system-operator 
data: 
  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 

    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>
En operator.yaml, debe especificar la ubicación de la imagen de NCP en la sección env. 
kind: Deployment
metadata: 
  name: nsx-ncp-operator 
  namespace: nsx-system-operator 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      name: nsx-ncp-operator 
  template: 
    metadata: 
      labels: 
        name: nsx-ncp-operator 
    spec: 
      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}"

Para la imagen del Operator, especifique la versión de NCP que se deberá instalar. Por ejemplo, para NCP 3.1.1, la imagen del Operator es vmware/nsx-container-plugin-operator:v3.1.1.

Tenga en cuenta que no se recomienda extraer dockerhub directamente en un entorno de producción debido a su política de limitación de velocidad. Una vez que se haya extraído la imagen de dockerhub, esta se puede insertar en un registro local, posiblemente el mismo en el que hay imágenes de NCP disponibles.

Como alternativa, puede usar el archivo de imagen del Operator incluido en el archivo de descarga de NCP disponible en download.vmware.com e importarlo a un registro local. Esta imagen es la misma que la publicada en el dockerhub de VMware.

Para establecer el valor de MTU para CNI, modifique el parámetro mtu en la sección [nsx-node-agent] de ConfigMap del Operator. El Operator activará el recreo de los pods de nsx-ncp-boostrap para garantizar que los archivos de configuración CNI se actualicen correctamente en todos los nodos. También debe actualizar la MTU del nodo según corresponda. Un error de coincidencia entre el nodo y la MTU del pod puede causar problemas en la comunicación nodo-pod, lo que afecta a, por ejemplo, los sondeos de disponibilidad y la ejecución de TCP.

Para actualizar la MTU en una interfaz de un nodo, puede ejecutar el comando ovs-vsctl set Interface <interface-name> mtu_request=<mtu-value>, donde interface-name puede ser una interfaz OVS o una interfaz física en el contenedor nsx-ovs que se ejecuta en el pod nsx-node-agent. Por ejemplo, oc -n nsx-system exec -it nsx-node-agent-dqqm9 -c nsx-ovs -- ovs-vsctl set Interface ens192 mtu_request=9000.

Nota: si se habilita HA en el ConfigMap del Operator, se creará un único pod de NCP, ya que el parámetro ncpReplicas se establece en 1 de forma predeterminada. Para que se creen 3 pods de NCP, puede cambiarlo a 3. Una vez instalado el clúster, puede cambiar el número de réplicas de NCP con el comando oc edit ncpinstalls ncp-install -n nsx-system.

A continuación se muestra un ejemplo de operator.nsx.vmware.com_v1_ncpinstall_cr.yaml. El parámetro addNodeTag debe establecerse en false si un nodo tiene varias interfaces de red. 
apiVersion: operator.nsx.vmware.com/v1
kind: NcpInstall
metadata:
  name: ncp-install
  namespace: nsx-system-operator
spec:
  ncpReplicas: 1
  # Note that if one node has multiple attached VirtualNetworkInterfaces, this function is not supported and should be set to false
  addNodeTag: true
  nsx-ncp:
    # Uncomment below to add user-defined nodeSelector for NCP Deployment
    #nodeSelector:
      #<node_label_key>: <node_label_value>
    tolerations:
      # Please don't modify below default tolerations for NCP Deployment
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node.kubernetes.io/network-unavailable
        effect: NoSchedule
      # Uncomment below to add user-defined tolerations for NCP Deployment
      #<toleration_specification>
      
  nsx-node-agent:
    tolerations:
      # Please don't modify below default tolerations
      # for nsx-ncp-bootstrap and nsx-node-agent DaemonSet
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node.kubernetes.io/not-ready
        effect: NoSchedule
      - key: node.kubernetes.io/unreachable
        effect: NoSchedule
      - operator: Exists
        effect: NoExecute 
      # Uncomment below to add user-defined tolerations for nsx-ncp-bootstrap and nsx-node-agent DaemonSet
      #<toleration_specification>

Configurar la autenticación basada en certificados para NSX-T mediante la identidad de entidad de seguridad

En un entorno de producción, se recomienda no exponer credenciales de administrador en configmap.yaml con los parámetros nsx_api_user y nsx_api_password. En los siguientes pasos se describe cómo crear una identidad de entidad de seguridad y permitir que NCP use un certificado para la autenticación.

  1. Genere un certificado y una clave.
  2. En NSX Manager, vaya a Sistema > Usuarios y funciones y haga clic en Agregar > Identidad de entidad de seguridad con función. Agregue una identidad de entidad de seguridad y pegue el certificado generado en el paso 1.
  3. Agregue los valores de clave y crt con codificación base64 en nsx-secret.yaml.
  4. Establezca la ubicación de los archivos de certificado y clave en la sección [nsx_v3] de configmap.yaml:
    nsx_api_cert_file = /etc/nsx-ujo/nsx-cert/tls.crt
nsx_api_private_key_file = /etc/nsx-ujo/nsx-cert/tls.key

Nota: No se admite el cambio del método de autenticación en un clúster que ya está encendida.

(Opcional) Configurar el certificado de equilibrador de carga de NSX-T predeterminado

Un equilibrador de carga de NSX-T puede implementar objetos de ruta HTTPS de OpenShift y descargar la HAProxy de OCP. Para hacer eso se requiere un certificado predeterminado. Siga estos pasos para configurar el certificado predeterminado:

  1. Agregue los valores de clave y crt con codificación base64 en lb-secret.yaml.
  2. Establezca la ubicación del certificado y la clave en configmap.yaml en la sección [nsx_v3]:
    lb_default_cert_path = /etc/nsx-ujo/lb-cert/tls.crt
lb_priv_key_path = /etc/nsx-ujo/lb-cert/tls.key

(Opcional) Configurar la autenticación basada en certificados para las instancias de NSX Manager

Si establece insecure como False en el ConfigMap, deberá especificar las huellas digitales de los tres administradores en el clúster de NSX Manager. El siguiente procedimiento es un ejemplo de cómo hacerlo.

Copie los certificados de las tres instancias de NSX Manager en un archivo:

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
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}'`
NSX2=`openssl x509 -in nsx2.crt -fingerprint -noout|awk -F"=" '{print $2}'`
NSX3=`openssl x509 -in nsx3.crt -fingerprint -noout|awk -F"=" '{print $2}'`
THUMB="$NSX1,$NSX2,$NSX3"
echo $THUMB

Edite el ConfigMap y agregue las huellas digitales en la sección [nsx_v3]:

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