Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Upgrade von v1.4.1 oder v1.4.2 auf v1.4.3

Allgemeine Informationen

Ein Upgrade-Button erscheint auf dem Dashboard-Bildschirm, wann immer eine neue SUSE Virtualization Version verfügbar wird, auf die Sie upgraden können. Für weitere Informationen siehe Starten eines Upgrades.

SUSE Virtualization v1.4.2 und v1.4.3 verwenden die gleiche Minor-Version von SUSE® Rancher Prime: RKE2 (v1.31). Dies ermöglicht es Ihnen, direkt von v1.4.1 auf v1.4.3 zu upgraden.

Für Air-Gapped-Umgebungen siehe Vorbereiten eines Air-Gapped-Upgrades.

Bekannte Probleme

1. Air-Gapped-Upgrade bleibt mit einem ImagePullBackOff-Fehler in den Fluentd- und Fluent Bit-Pods hängen.

Das Upgrade kann zu Beginn des Prozesses hängen bleiben, wie an 0 % Fortschritt und an Elementen, die im Upgrade-Dialog der SUSE Virtualization UI als Ausstehend markiert sind, zu erkennen ist.

upgrade dialog with empty status

Insbesondere können die Fluentd- und Fluent Bit-Pods im ImagePullBackOff-Status hängen bleiben. Um den Status der Pods zu überprüfen, führen Sie die folgenden Befehle aus:

$ kubectl -n harvester-system get upgrades -l harvesterhci.io/latestUpgrade=true
NAME                 AGE
hvst-upgrade-x2hz8   7m14s

$ kubectl -n harvester-system get upgradelogs -l harvesterhci.io/upgrade=hvst-upgrade-x2hz8
NAME                            UPGRADE
hvst-upgrade-x2hz8-upgradelog   hvst-upgrade-x2hz8

$ kubectl -n harvester-system get pods -l harvesterhci.io/upgradeLog=hvst-upgrade-x2hz8-upgradelog
NAME                                                        READY   STATUS             RESTARTS   AGE
hvst-upgrade-x2hz8-upgradelog-downloader-6cdb864dd9-6bw98   1/1     Running            0          7m7s
hvst-upgrade-x2hz8-upgradelog-infra-fluentbit-2nq7q         0/1     ImagePullBackOff   0          7m42s
hvst-upgrade-x2hz8-upgradelog-infra-fluentbit-697wf         0/1     ImagePullBackOff   0          7m42s
hvst-upgrade-x2hz8-upgradelog-infra-fluentbit-kd8kl         0/1     ImagePullBackOff   0          7m42s
hvst-upgrade-x2hz8-upgradelog-infra-fluentd-0               0/2     ImagePullBackOff   0          7m42s

Dies tritt auf, weil die folgenden Container-Images weder in den Cluster-Knoten vorab geladen noch aus dem Internet heruntergeladen wurden:

  • ghcr.io/kube-logging/fluentd:v1.15-ruby3

  • ghcr.io/kube-logging/config-reloader:v0.0.5

  • fluent/fluent-bit:2.1.8

Um das Problem zu beheben, führen Sie eine der folgenden Aktionen aus:

  • Aktualisieren Sie die Logging-CR, um die Images zu verwenden, die bereits in den Cluster-Knoten vorab geladen sind. Führen Sie dazu die folgenden Befehle gegen den Cluster aus:

    # Get the Logging CR names
OPERATOR_LOGGING_NAME=$(kubectl get loggings -l app.kubernetes.io/name=rancher-logging -o jsonpath="{.items[0].metadata.name}")
INFRA_LOGGING_NAME=$(kubectl get loggings -l harvesterhci.io/upgradeLogComponent=infra -o jsonpath="{.items[0].metadata.name}")

# Gather image info from operator's Logging CR
FLUENTD_IMAGE_REPO=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentd.image.repository}")
FLUENTD_IMAGE_TAG=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentd.image.tag}")

FLUENTBIT_IMAGE_REPO=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentbit.image.repository}")
FLUENTBIT_IMAGE_TAG=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentbit.image.tag}")

CONFIG_RELOADER_IMAGE_REPO=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentd.configReloaderImage.repository}")
CONFIG_RELOADER_IMAGE_TAG=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentd.configReloaderImage.tag}")

# Patch the Logging CR
kubectl patch logging $INFRA_LOGGING_NAME --type=json -p="[{\"op\":\"replace\",\"path\":\"/spec/fluentbit/image\",\"value\":{\"repository\":\"$FLUENTBIT_IMAGE_REPO\",\"tag\":\"$FLUENTBIT_IMAGE_TAG\"}}]"
kubectl patch logging $INFRA_LOGGING_NAME --type=json -p="[{\"op\":\"replace\",\"path\":\"/spec/fluentd/image\",\"value\":{\"repository\":\"$FLUENTD_IMAGE_REPO\",\"tag\":\"$FLUENTD_IMAGE_TAG\"}}]"
kubectl patch logging $INFRA_LOGGING_NAME --type=json -p="[{\"op\":\"replace\",\"path\":\"/spec/fluentd/configReloaderImage\",\"value\":{\"repository\":\"$CONFIG_RELOADER_IMAGE_REPO\",\"tag\":\"$CONFIG_RELOADER_IMAGE_TAG\"}}]"

    Der Status der Fluentd- und Fluent Bit-Pods sollte sich in Kürze auf Running ändern und der Upgrade-Prozess sollte fortgesetzt werden, nachdem die Logging-CR aktualisiert wurde. Wenn der Status des Fluentd-Pods weiterhin ImagePullBackOff ist, können Sie den Pod löschen, um ihn zum Neustart zu zwingen.

    UPGRADE_NAME=$(kubectl -n harvester-system get upgrades -l harvesterhci.io/latestUpgrade=true -o jsonpath='{.items[0].metadata.name}')
UPGRADELOG_NAME=$(kubectl -n harvester-system get upgradelogs -l harvesterhci.io/upgrade=$UPGRADE_NAME -o jsonpath='{.items[0].metadata.name}')

kubectl -n harvester-system delete pods -l harvesterhci.io/upgradeLog=$UPGRADELOG_NAME,harvesterhci.io/upgradeLogComponent=aggregator

  • Auf einem Computer mit Internetzugang ziehen Sie die erforderlichen Container-Images und exportieren Sie sie dann in eine TAR-Datei. Übertragen Sie als Nächstes die TAR-Datei auf die Cluster-Knoten und importieren Sie die Images, indem Sie die folgenden Befehle auf jedem Knoten ausführen:

    # Pull down the three container images
docker pull ghcr.io/kube-logging/fluentd:v1.15-ruby3
docker pull ghcr.io/kube-logging/config-reloader:v0.0.5
docker pull fluent/fluent-bit:2.1.8

# Export the images to a tar file
docker save \
  ghcr.io/kube-logging/fluentd:v1.15-ruby3 \
  ghcr.io/kube-logging/config-reloader:v0.0.5 \
  fluent/fluent-bit:2.1.8 > upgradelog-images.tar

# After transferring the tar file to the cluster nodes, import the images (need to be run on each node)
ctr -n k8s.io images import upgradelog-images.tar

    Der Upgrade-Prozess sollte fortgesetzt werden, nachdem die Images vorab geladen wurden.

    • (Nicht empfohlen) Starten Sie den Upgrade-Prozess mit deaktiviertem Logging neu. Stellen Sie sicher, dass das Logging aktivieren Kontrollkästchen im Upgrade Dialog nicht ausgewählt ist.

Verwandtes Problem: #7955

2. Überdimensionierte Volumes

In SUSE Virtualization v1.4.3, das SUSE Storage v1.7.3 verwendet, werden überdimensionierte Volumes (zum Beispiel 999999 Gi groß) als Nicht bereit markiert und können nicht gelöscht werden.

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

  1. Entfernen Sie vorübergehend die PVC-Webhook-Regel.

    RULE_INDEX=$(kubectl get \
  validatingwebhookconfiguration longhorn-webhook-validator -o json \
  | jq '.webhooks[0].rules | map(.resources[0] == "persistentvolumeclaims") | index(true)')

if [ -n "$RULE_INDEX" -a "$RULE_INDEX" != "null" ]; then
  kubectl patch validatingwebhookconfiguration longhorn-webhook-validator \
    --type='json' \
    -p="[{'op': 'remove', 'path': '/webhooks/0/rules/$RULE_INDEX'}]"
fi

  2. Warten Sie, bis das zugehörige PVC gelöscht wird.

  3. Stellen Sie die PVC-Webhook-Regel wieder her, um die Validierung wieder zu aktivieren.

    kubectl patch validatingwebhookconfiguration longhorn-webhook-validator \
  --type='json' \
  -p='[{"op": "add", "path": "/webhooks/0/rules/-", "value": {"apiGroups":[""],"apiVersions":["v1"],"operations":["UPDATE"],"resources":["persistentvolumeclaims"],"scope":"Namespaced"}}]'

Das Problem wird in SUSE Storage v1.8.2 behoben, das wahrscheinlich in SUSE Virtualization v1.5.1 enthalten sein wird.

Verwandte Probleme: #8096 und #10741

3. Nicht-Root-Benutzer in Gast-Clustern können nicht auf RWX-Volumes zugreifen

Nicht-Root-Benutzer in Gast-Clustern stoßen auf unerwartete "Berechtigung verweigert"-Fehler beim Zugriff auf RWX-Volumes. Dies wird durch ein Regression-Problem in nfs-ganesha v6.0+ verursacht, das v1.7.3 des longhorn-share-manager Images betrifft.

Sie können das Problem lösen, indem Sie longhorn-share-manager:v1.7.3 durch das Hotfix-Image longhorn-share-manager:v1.7.3-hotfix-1 ersetzen.

Verwenden Sie das Hotfix-Image nicht, wenn Sie nicht von dem Problem betroffen sind.

  1. Bearbeiten Sie das longhorn-manager DaemonSet, indem Sie den folgenden Befehl ausführen:

      kubectl -n longhorn-system edit daemonset/longhorn-manager

  2. Ändern Sie im spec.containers.command-Feld das --share-manager-image in longhornio/longhorn-share-manager:v1.7.3-hotfix-1.

      ...
    spec:
      containers:
      - command:
        - longhorn-manager
        - -d
        - daemon
        - --engine-image
        - longhornio/longhorn-engine:v1.7.3
        - --instance-manager-image
        - longhornio/longhorn-instance-manager:v1.7.3
        - --share-manager-image
        - longhornio/longhorn-share-manager:v1.7.3-hotfix-1
        - --backing-image-manager-image
        - longhornio/backing-image-manager:v1.7.3
        - --support-bundle-manager-image
        - longhornio/support-bundle-kit:v0.0.51
        - --manager-image
        - longhornio/longhorn-manager:v1.7.3
        - --service-account
        - longhorn-service-account
        - --upgrade-version-check
  ...

  3. Sobald das Update angewendet wurde, starten Sie die Workloads neu, die RWX-Volumes verwenden.

Wenn Sie das Hotfix-Image verwenden und SUSE Virtualization v1.5.x upgraden möchten, müssen Sie das longhorn-manager DaemonSet bearbeiten und zum longhorn-share-manager:v1.7.3-Image zurückkehren, bevor Sie das Upgrade starten.

Verwandte Probleme: 8354 und 10621

4. Virtuelle Maschinen, die migrierbare RWX-Volumes verwenden, starten unerwartet neu.

Virtuelle Maschinen, die migrierbare RWX-Volumes verwenden, starten unerwartet neu, wenn die CSI-Plugin-Pods neu gestartet werden. Dieses Problem betrifft SUSE Virtualization v1.4.x, v1.5.0 und v1.5.1.

Die Lösung besteht darin, die Einstellung Automatisch Arbeitslast-Pod löschen, wenn das Volume unerwartet getrennt wird im SUSE Storage UI vor dem Start des Upgrades zu deaktivieren. Sie müssen die Einstellung erneut aktivieren, sobald das Upgrade abgeschlossen ist.

Das Problem wird in SUSE Storage v1.8.3, v1.9.1 und späteren Versionen behoben. SUSE Virtualization v1.6.0 wird SUSE Storage v1.9.1 enthalten.

Verwandte Probleme: #8534 und #11158