NSX Container Plug-in (NCP) est fourni sous forme d'image Docker. NCP doit s'exécuter sur un nœud des services d'infrastructure. Il n'est pas recommandé d'exécuter NCP sur le nœud maître.

Procédure

  1. Téléchargez l'image Docker de NCP.
    Le nom de fichier est nsx-ncp-xxxxxxx.tar, où xxxxxxx est le numéro de build.
  2. Téléchargez le modèle yaml ReplicationController de NCP.
    Le nom de fichier est ncp-rc.yml. Vous pouvez modifier ce fichier ou l'utiliser comme exemple pour votre propre fichier de modèle.
  3. Chargez l'image Docker de NCP dans votre registre d'images.
        docker load -i <tar file>
  4. (Facultatif) Téléchargez le modèle yaml pour la définition de la ressource personnalisée de l'objet NSXError.
    Le nom de fichier est nsx-error-crd.yaml.
  5. (Facultatif) Créez la ressource personnalisée.
        kubectl create -f nsx-error-crd.yaml
  6. Modifiez ncp-rc.yml.
    Changez le nom de l'image pour celui qui a été chargé.

    Spécifiez le paramètre nsx_api_managers. Vous pouvez spécifier l'adresse IP d'une instance unique de NSX Manager, ou les adresses IP (séparées par des virgules) de trois instances de NSX Manager dans un cluster NSX Manager ou l'adresse IP virtuelle d'un cluster NSX Manager. Par exemple :

        nsx_api_managers = 192.168.1.180
    or
        nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183

    (Facultatif) Spécifiez le paramètre ca_file dans la section [nsx_v3]. La valeur doit être un fichier de bundle d'autorité de certification à utiliser pour la vérification du certificat de serveur NSX Manager. Si aucune valeur n'est définie, les autorités de certification racines du système seront utilisées. Si vous spécifiez une adresse IP pour nsx_api_managers, spécifiez un fichier d'autorité de certification. Si vous spécifiez trois adresses IP pour nsx_api_managers, vous pouvez spécifier un ou trois fichiers d'autorité de certification. Si vous spécifiez un fichier d'autorité de certification, il sera utilisé pour les trois gestionnaires. Si vous spécifiez trois fichiers d'autorité de certification, chacun sera utilisé pour l'adresse IP correspondante dans nsx_api_managers. Par exemple,

        ca_file = ca_file_for_all_mgrs
    or
        ca_file = ca_file_for_mgr1,ca_file_for_mgr2,ca_file_for_mgr3

    Spécifiez les paramètres nsx_api_cert_file et nsx_api_private_key_file pour l'authentification avec NSX-T Data Center.

    nsx_api_cert_file est le chemin d'accès complet vers un fichier de certificat client au format PEM. Le contenu de ce fichier devrait ressembler à ce qui suit :

        -----BEGIN CERTIFICATE-----
        <certificate_data_base64_encoded>
        -----END CERTIFICATE-----

    nsx_api_private_key_file est le chemin d'accès complet vers un fichier de clé privée client au format PEM. Le contenu de ce fichier devrait ressembler à ce qui suit :

        -----BEGIN PRIVATE KEY-----
        <private_key_data_base64_encoded>
        -----END PRIVATE KEY-----

    Spécifiez le paramètre ingress_mode = nat si le contrôleur d'entrée est configuré pour s'exécuter en mode NAT.

    Par défaut, le préfixe de sous-réseau 24 est utilisé pour tous les sous-réseaux alloués à partir des blocs d'adresses IP pour les commutateurs logiques d'espace. Pour utiliser une taille de sous-réseau différente, mettez à jour l'option subnet_prefix dans la section [nsx_v3].

    HA (haute disponibilité) est activée par défaut. Vous pouvez désactiver HA avec la spécification suivante :
    [ha]
    enable = False
    (Facultatif) Activez la génération de rapports d'erreur à l'aide de NSXError dans ncp.ini. Ce paramètre est désactivé par défaut.
    [nsx_v3]
    enable_nsx_err_crd = True
    Note : Dans le fichier yaml, vous devez spécifier que le ConfigMap généré pour ncp.ini doit être monté en tant que volume en lecture seule. Le fichier yaml téléchargé a déjà cette spécification, qui ne doit pas être modifiée.
  7. Créez ReplicationController de NCP.
        kubectl create -f ncp-rc.yml

Résultats

Note : NCP ouvre des connexions HTTP persistantes au serveur Kubernetes API pour surveiller les événements de cycle de vie des ressources Kubernetes. Si une défaillance du serveur API ou une panne de réseau provoque l'obsolescence des connexions TCP de NCP, vous devez redémarrer NCP pour lui permettre de rétablir les connexions au serveur API. Sinon, NCP ratera les nouveaux événements.
Pendant une mise à jour continue du ReplicationController NCP, vous pouvez voir deux espaces NCP en cours d'exécution après la mise à jour continue dans les situations suivantes :
  • Vous redémarrez l'hôte de conteneur au cours de la mise à jour continue.
  • Initialement, la mise à jour continue échoue, car la nouvelle image n'existe pas sur un nœud Kubernetes. Pour réussir la mise à jour, téléchargez l'image et exécutez à nouveau la mise à jour continue.
Si vous voyez deux espaces NCP en cours d'exécution, procédez comme suit :
  • Supprimez l'un des espaces NCP. Vous pouvez supprimer l'un ou l'autre indifféremment. Par exemple,
    kubectl delete pods <NCP pod name> -n nsx-system
  • Supprimez NCP ReplicationController. Par exemple,
    kubectl delete -f ncp-rc.yml -n nsx-system