Avant d'installer OpenShift 4, vous devez mettre à jour certains fichiers de configuration NCP.

Les fichiers YAML sont inclus dans le fichier de téléchargement NCP à partir de download.vmware.com. Vous pouvez aller à https://github.com/vmware/nsx-container-plugin-operator/releases, trouver la version d'operator correspondante (par exemple, v3.1.1) et télécharger openshift4.tar.gz.

Les fichiers suivants se trouvent dans le dossier nsx-container-plugin-operator/deploy :
  • configmap.yaml – Mettez à jour ce fichier avec les informations de NSX.
  • operator.yaml – Spécifiez l'emplacement de l'image NCP dans ce fichier.
  • namespace.yaml – Spécification d'espace de noms pour l'operator. Ne modifiez pas ce fichier.
  • role_binding.yaml - Spécification de liaison de rôle pour l'operator. Ne modifiez pas ce fichier.
  • role.yaml - Spécification de rôle pour l'operator. Ne modifiez pas ce fichier.
  • service_account.yaml - La spécification du compte de service pour l'operator. Ne modifiez pas ce fichier.
  • lb-secret.yaml - Secret pour le certificat d'équilibrage de charge NSX par défaut.
  • nsx-secret.yaml - Secret pour l'authentification basée sur un certificat sur NSX. Cette option est utilisée au lieu de nsx_api_user et nsx_api_password dans configmap.yaml.
  • operator.nsx.vmware.com_ncpinstalls_crd.yaml - Définition de ressource de client appartenant à l'operator.
  • operator.nsx.vmware.com_v1_ncpinstall_cr.yaml - Ressource de client appartenant à l'operator.
L'exemple suivant configmap.yaml montre une configuration de base. Pour plus d'options, consultez configmap.yaml dans le dossier deploy. Vous devez spécifier des valeurs pour les paramètres suivants en fonction de votre environnement :
  • cluster
  • 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>
Dans operator.yaml, vous devez spécifier l'emplacement de l'image NCP dans la section 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}"

Pour l'image d'operator, spécifiez la version de NCP qui devra être installée. Par exemple, pour NCP 3.1.1, l'image d'operator est vmware/nsx-container-plugin-operator:v3.1.1.

Notez que l'extraction directe de dockerhub n'est pas recommandée dans un environnement de production en raison de sa stratégie de limitation de débit. Une fois que dockerhub est extrait, l'image peut être poussée vers un registre local, probablement le même que celui contenant les images NCP.

Vous pouvez également utiliser le fichier image operator inclus dans le fichier de téléchargement NCP à partir de download.vmware.com et l'importer dans un registre local. Cette image est la même que celle publiée sur le dockerhub de VMware.

Pour définir la valeur MTU pour CNI, modifiez le paramètre mtu dans la section [nsx-node-agent] de l'operator ConfigMap. L'operator déclenche une recréation des espaces nsx-ncp-boostrap pour garantir que les fichiers de configuration CNI sont correctement mis à jour sur tous les nœuds. Vous devez également mettre à jour le MTU du nœud en conséquence. Une incompatibilité entre le nœud et le MTU de l'espace peut entraîner des problèmes de communication de l'espace de nœud, affectant, par exemple, des sondes de réactivité et de disponibilité TCP.

Pour mettre à jour le MTU sur une interface sur un nœud, vous pouvez exécuter la commande ovs-vsctl set Interface <interface-name> mtu_request=<mtu-value>, où interface-name peut être une interface OVS ou une interface physique dans le conteneur nsx-ovs qui s'exécute dans l'espace nsx-node-agent. Par exemple, oc -n nsx-system exec -it nsx-node-agent-dqqm9 -c nsx-ovs -- ovs-vsctl set Interface ens192 mtu_request=9000.

Remarque : l'activation de HA dans l'Operator ConfigMap créera un seul espace NCP, car le paramètre ncpReplicas est défini sur 1 par défaut. Pour que 3 espaces NCP soient créés, vous pouvez le changer sur 3. Une fois le cluster installé, vous pouvez modifier le nombre de réplicas NCP à l'aide de la commande oc edit ncpinstalls ncp-install -n nsx-system.

Voici un exemple de operator.nsx.vmware.com_v1_ncpinstall_cr.yaml. Le paramètre addNodeTag doit être défini sur false si un nœud dispose de plusieurs interfaces réseau. 
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>

Configuration de l'authentification basée sur un certificat pour NSX à l'aide de l'identité de principal

Dans un environnement de production, il est recommandé de ne pas exposer les informations d'identification de l'administrateur dans configmap.yaml avec les paramètres nsx_api_user et nsx_api_password. Les étapes suivantes décrivent comment créer une identité de principal et autoriser NCP à utiliser un certificat pour l'authentification.

  1. Générez un certificat et une clé.
  2. Dans NSX Manager, accédez à Système > Utilisateurs et rôles et cliquez sur Ajouter > Identité de principal disposant d'un rôle. Ajoutez une identité de principal et collez le certificat généré à l'étape 1.
  3. Ajoutez les valeurs crt et key codées en base64 dans nsx-secret.yaml.
  4. Définissez l'emplacement des fichiers de certificat et de clé dans configmap.yaml sous la section [nsx_v3] :
    nsx_api_cert_file = /etc/nsx-ujo/nsx-cert/tls.crt
nsx_api_private_key_file = /etc/nsx-ujo/nsx-cert/tls.key

Remarque : la modification de la méthode d'authentification sur un cluster déjà démarré n'est pas prise en charge.

(Facultatif) Configuration du certificat par défaut de l'équilibreur de charge NSX

Un équilibreur de charge NSX peut implémenter des objets de route OpenShift HTTPS et décharger le HAProxy OCP. Pour cela, un certificat par défaut est requis. Procédez comme suit pour configurer le certificat par défaut :

  1. Ajoutez les valeurs crt et key codées en base64 dans lb-secret.yaml.
  2. Définissez l'emplacement des fichiers de certificat et de clé dans configmap.yaml sous la section [nsx_v3] :
    lb_default_cert_path = /etc/nsx-ujo/lb-cert/tls.crt
lb_priv_key_path = /etc/nsx-ujo/lb-cert/tls.key

(Facultatif) Configuration de l'authentification basée sur un certificat pour des instances de NSX Manager

Si vous définissez insecure = False dans le ConfigMap, vous devez spécifier les empreintes numériques des trois gestionnaires dans le cluster NSX Manager. La procédure suivante en est un exemple.

Copiez les certificats des trois instances de NSX Manager dans un fichier :

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

Modifiez le ConfigMap et ajoutez les empreintes dans la section [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