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

    Legen Sie den Knotentyp auf „Bare Metal“ fest.

    [coe]
    node_type = ‘BAREMETAL’

    Ändern Sie den Image-Namen in den Namen der geladenen Datei.

    Geben Sie den nsx_api_managers-Parameter an. Diese Version unterstützt ein einzelnes Kubernetes-Knotencluster und eine einzelne NSX Manager-Instanz. Beispiel:

        nsx_api_managers = 192.168.1.180

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

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

    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.

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

Starten Sie während eines parallelen Updates des NCP ReplicationController den Container-Host nicht neu. Wenn der Host aus irgendeinem Grund neu gestartet wird, werden nach dem Neustart möglicherweise zwei NCP-Pods ausgeführt. In diesem Fall 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:

    oc delete pods <NCP pod name> -n nsx-system
  • Löschen Sie den Namespace nsx-system. Beispiel:

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