|
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.2
Allgemeine Informationen
Ein Upgrade-Button erscheint auf dem Dashboard-Bildschirm, sobald eine neue SUSE Virtualization-Version verfügbar ist, auf die Sie upgraden können. Für weitere Informationen siehe Starte ein Upgrade.
Sie können direkt von v1.4.2 auf v1.5.2 upgraden, da SUSE Virtualization maximal ein kleines Versionsupgrade für zugrunde liegende Komponenten zulässt. v1.4.2 und v1.4.3 verwenden die gleiche kleine Version von RKE2 (v1.31), während v1.5.0, v1.5.1 und v1.5.2 die nächste kleine Version (v1.32) verwenden.
Für Informationen zum Upgrade von SUSE Virtualization in Air-Gapped-Umgebungen siehe Bereite ein Air-Gapped-Upgrade vor.
Aktualisieren Sie die Harvester UI-Erweiterung auf SUSE Rancher Prime v2.11.0
Sie müssen v1.5.2 der Harvester UI-Erweiterung verwenden, um SUSE Virtualization v1.5.2 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.
-
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.2 und klicken Sie dann auf Aktualisieren.
-
Lassen Sie etwas Zeit für die Aktualisierung der Erweiterung und aktualisieren Sie dann den Bildschirm.
Bekannte Probleme
Air-Gapped-Upgrade bleibt mit einem ImagePullBackOff-Fehler in den Fluentd- und Fluent Bit-Pods hängen.
Das Upgrade kann zu Beginn des Prozesses ins Stocken geraten, wie 0 % Fortschritt und als Ausstehend markierte Elemente im Upgrade-Dialogfeld der SUSE Virtualization UI anzeigen.
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 am 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 sie dann in eine TAR-Datei. Übertragen Sie als Nächstes die TAR-Datei auf die Cluster-Knoten und importieren Sie die Container-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 Container-Images vorab geladen wurden.
-
(Nicht empfohlen) Starten Sie den Upgrade-Prozess mit deaktiviertem Logging neu. Stellen Sie sicher, dass das Kontrollkästchen Logging aktivieren im Dialogfeld Upgrade nicht ausgewählt ist.
-
Verwandtes Problem: #7955
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 in der 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.