|
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.2 oder v1.4.3 auf v1.5.1
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 Sie ein Upgrade.
Sie können direkt von v1.4.2 auf v1.5.1 upgraden, da SUSE Virtualization maximal ein kleines Versionsupgrade für zugrunde liegende Komponenten zulässt. SUSE Virtualization v1.4.2 und v1.4.3 verwenden dieselbe kleine Version von SUSE® Rancher Prime: RKE2 (v1.31), während SUSE Virtualization v1.5.0 und v1.5.1 die nächste kleine Version (v1.32) verwenden.
Für Informationen zum Upgrade von SUSE Virtualization in Air-Gapped-Umgebungen siehe Bereiten Sie ein Air-Gapped-Upgrade vor.
Aktualisieren Sie die Harvester UI-Erweiterung auf SUSE Rancher Prime v2.11.0
Sie müssen v1.5.1 der Harvester UI-Erweiterung verwenden, um SUSE Virtualization v1.5.1 Cluster auf Rancher v2.11.0 zu importieren.
-
Gehen Sie zur Rancher UI und dann zu lokalen → Apps → Repositories.
-
Suchen Sie das Repository mit dem Namen harvester und wählen Sie dann ⋮ → Aktualisieren aus.
-
Gehen Sie zum Erweiterungen Bildschirm.
-
Suchen Sie die Erweiterung mit dem Namen Harvester und klicken Sie dann auf Aktualisieren.
-
Wählen Sie die Version 1.5.1 aus und klicken Sie dann auf Aktualisieren.
-
Lassen Sie etwas Zeit für die Aktualisierung der Erweiterung und aktualisieren Sie dann den Bildschirm.
Bekannte Probleme
1. Air-Gapped-Upgrade bleibt mit ImagePullBackOff-Fehler in den Fluentd- und Fluent Bit-Pods hängen.
Das Upgrade kann zu Beginn des Prozesses hängen bleiben, erkennbar an 0 % Fortschritt und an Elementen, die im Upgrade-Dialog als Ausstehend markiert sind.
Insbesondere können 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 7m42sDies tritt auf, weil die folgenden Container-Images weder in den Cluster-Knoten vorab geladen noch aus dem Internet heruntergeladen werden:
-
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 bereits in den Cluster-Knoten vorab geladenen Images zu verwenden. Führen Sie dazu die folgenden Befehle im 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 weiterhinImagePullBackOffist, 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 laden Sie die erforderlichen Container-Images herunter, und exportieren Sie diese 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.tarDer 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 Dialogfeld nicht ausgewählt ist.
-
Verwandtes Problem: #7955
2. 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 Arbeitslast-Pod automatisch 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 sein. SUSE Virtualization v1.6.0 wird SUSE Storage v1.9.1 enthalten.