In diesem Abschnitt wird beschrieben, wie in einer Kubernetes-Umgebung ein Upgrade von NCP auf 2.4.0 vorgenommen wird.

Prozedur

  1. Führen Sie das Upgrade von NCP ReplicationController mit dem folgenden Befehl durch (ersetzen Sie <image> durch den tatsächlichen Namen des Image).
    kubectl rolling-update nsx-ncp -n nsx-system --image=<image>
  2. Führen Sie das Upgrade des daemonSet des NSX-Knotenagent mit den folgenden Befehlen durch (ersetzen Sie <image> durch den tatsächlichen Namen des Image).
    kubectl set image ds nsx-node-agent -n nsx-system nsx-node-agent=<image>
    kubectl set image ds nsx-node-agent -n nsx-system nsx-kube-proxy=<images>
    kubectl rollout status ds/nsx-node-agent -nnsx-system
  3. Führen Sie das Upgrade des CNI DEB/RPM-Pakets auf 2.4.0 mit dem folgenden Befehl durch (ersetzen Sie <cni deb> und <cni rpm> durch den tatsächlichen Namen des Pakets).
    Unter Ubuntu:

    dkpg -i <cni deb>

    Unter RHEL oder CentOS:

    rpm -U <cni rpm>

  4. (Optional) Führen Sie ein Upgrade von NSX-T Data Center auf 2.4 durch.
    Wenn der Hypervisor ESXi ist, führen Sie vor dem Upgrade auf NSX-T Data Center ein Upgrade von ESXi von 6.5 auf mindestens 6.5p03 oder von 6.7 auf mindestens 6.7ep6 durch.
  5. (Optional) Führen Sie ein Upgrade des Hypervisors durch (KVM oder Bare-Metal-Container).
  6. (Optional) Führen Sie ein Upgrade des Container-Hosts durch (RHEL, Ubuntu oder CentOS).
  7. (Optional) Führen Sie ein Upgrade von Kubernetes durch.
  8. (Optional) Führen Sie ein Upgrade von OVS durch.
    Bei einem Bare-Metal-Container wird mit dem Upgrade von NSX-T Data Center auch ein Upgrade von OVS durchgeführt, sodass dieser Schritt nicht notwendig ist.

    Während dieses Schritts können vorübergehend Kommunikationsfehler zwischen nsx-kube-proxy und nsx-node-agent auftreten. Dies ist das erwartete Verhalten und weist nicht auf ein Problem hin.