NSX-T 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. Modifiez ncp-rc.yml.

    Définissez le type de nœud sur bare metal.

    [coe]
    node_type = ‘BAREMETAL’

    Changez le nom de l'image pour celui qui a été chargé.

    Spécifiez le paramètre nsx_api_managers. Cette version prend en charge un seul cluster de nœuds Kubernetes et une seule instance de NSX Manager. Par exemple :

        nsx_api_managers = 192.168.1.180

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

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

    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.

  5. 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 tournante de NCP ReplicationController, ne redémarrez pas l'hôte de conteneur. Si l'hôte est redémarré pour une raison quelconque, vous pouvez voir deux espaces NCP en cours d'exécution après le redémarrage. Dans ce cas, procédez comme suit :

  • Supprimez l'un des espaces NCP. Vous pouvez supprimer l'un ou l'autre indifféremment. Par exemple,

    oc delete pods <NCP pod name> -n nsx-system
  • Supprimez l'espace de noms nsx-system. Par exemple,

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