NSX Container Plug-in (NCP) wird als Docker-Image bereitgestellt. NCP (NSX Container-Plug-In) sollte auf einem Knoten für Infrastrukturdienste ausgeführt werden. Die NCP-Ausführung auf dem Master-Knoten wird nicht empfohlen.

Prozedur

  1. Laden Sie das NCP-Docker-Image herunter.
    Der Dateiname lautet nsx-ncp-xxxxxxx.tar, wobei xxxxxxx der Build-Nummer entspricht.
  2. Laden Sie die YAML-Vorlage für NCP ReplicationController herunter.
    Der Dateiname lautet ncp-rc.yml. Sie können diese Datei bearbeiten oder als Beispiel für Ihre eigene Vorlagendatei verwenden.
  3. Laden Sie das NCP-Docker-Image in Ihre Image-Registrierung.
        docker load -i <tar file>
  4. (Optional) Laden Sie die YAML-Vorlage für die benutzerdefinierte Ressourcendefinition des NSXError-Objekts herunter.
    Der Dateiname lautet nsx-error-crd.yaml.
  5. (Optional) Erstellen Sie die benutzerdefinierte Ressource.
        kubectl create -f nsx-error-crd.yaml
  6. Bearbeiten Sie ncp-rc.yml.
    Ändern Sie den Image-Namen in den Namen der geladenen Datei.

    Geben Sie den nsx_api_managers-Parameter an. Sie können die IP-Adresse eines einzelnen NSX Managers, die IP-Adressen (getrennt durch Komma) der drei NSX Manager in einem NSX Manager-Cluster oder die virtuelle IP-Adresse eines NSX Manager-Clusters angeben. Beispiel:

        nsx_api_managers = 192.168.1.180
    or
        nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183

    (Optional) Geben Sie den Parameter ca_file im Abschnitt [nsx_v3] an. Der Wert sollte einer CA-Paketdatei entsprechen, die beim Überprüfen des NSX Manager-Serverzertifikats verwendet wird. Wenn Sie keine Festlegung treffen, werden die System-Root-CAs verwendet. Wenn Sie eine IP-Adresse für nsx_api_managers angeben, geben Sie eine Zertifizierungsstellendatei an. Wenn Sie drei IP-Adressen für nsx_api_managers angeben, können Sie eine oder drei Zertifizierungsstellendatei(en) angeben. Wenn Sie eine Zertifizierungsstellendatei angeben, wird sie für alle drei Manager verwendet. Wenn Sie drei Zertifizierungsstellendateien angeben, wird jede davon für die entsprechende IP-Adresse in nsx_api_managers verwendet. Beispiel:

        ca_file = ca_file_for_all_mgrs
    or
        ca_file = ca_file_for_mgr1,ca_file_for_mgr2,ca_file_for_mgr3

    Geben Sie die Parameter nsx_api_cert_file und nsx_api_private_key_file für die Authentifizierung mit NSX-T Data Center an.

    nsx_api_cert_file ist der vollständige Pfad zu einer Client-Zertifikatdatei im PEM-Format. Der Inhalt dieser Datei sollte wie folgt aussehen:

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

    „nsx_api_private_key_file“ ist der vollständige Pfad zu einer privaten Client-Schlüsseldatei im PEM-Format. Der Inhalt dieser Datei sollte wie folgt aussehen:

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

    Geben Sie den Parameter ingress_mode = nat an, wenn der Ingress-Controller für die Ausführung im NAT-Modus konfiguriert ist.

    Standardmäßig wird das Subnetzpräfix 24 für alle Subnetze verwendet, die von den IP-Blöcken für die logischen Pod-Switches zugeordnet sind. Wenn Sie eine andere Subnetzgröße verwenden möchten, aktualisieren Sie die subnet_prefix-Option im Abschnitt [nsx_v3].

    HA (Hochverfügbarkeit) ist automatisch aktiviert. Sie können HA mit der folgenden Spezifikation deaktivieren:
    [ha]
    enable = False
    (Optional) Aktivieren Sie Fehlerberichterstellung mithilfe von NSXError in ncp.ini. Diese Einstellung ist standardmäßig deaktiviert.
    [nsx_v3]
    enable_nsx_err_crd = True
    Hinweis: In der YAML-Datei müssen Sie angeben, dass das für ncp.ini generierte ConfigMap-Objekt als ReadOnly-Volume bereitgestellt wird. Die heruntergeladene YAML-Datei weist bereits diese Spezifikation auf, die nicht geändert werden sollte.
  7. Erstellen Sie den NCP ReplicationController.
        kubectl create -f ncp-rc.yml

Ergebnisse

Hinweis: NCP öffnet dauerhafte HTTP-Verbindungen zum Kubernetes-API-Server, um Lebenszyklusereignisse von Kubernetes-Ressourcen zu überwachen. Wenn ein API-Serverausfall oder ein Netzwerkausfall dazu führt, dass TCP-Verbindungen von NCP verfallen, müssen Sie NCP neu starten, sodass es die Verbindungen zum API-Server wiederherstellen kann. Andernfalls verpasst NCP die neuen Ereignisse.
Während eines fortlaufenden Updates des NCP ReplicationController werden möglicherweise nach dem rollierenden Update zwei NCP-Pods angezeigt, die ausgeführt werden:
  • Während des rollierenden Updates starten Sie den Container-Host neu.
  • Das rollierende Update schlägt zu Beginn fehl, weil das neue Image auf keinem Kubernetes-Knoten vorhanden ist. Laden Sie das Image herunter und führen Sie das rollierende Update erneut aus, und es verläuft erfolgreich.
Wenn Sie zwei NCP-Pods angezeigt bekommen, die ausgeführt werden, gehen Sie wie folgt vor:
  • Löschen Sie einen der NCP-Pods. Dabei spielt es keine Rolle, welchen der beiden Pods Sie löschen. Beispiel:
    kubectl delete pods <NCP pod name> -n nsx-system
  • Löschen Sie den NCP ReplicationController. Beispiel:
    kubectl delete -f ncp-rc.yml -n nsx-system