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.3.2 auf v1.4.0

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.

Für Air-Gapped-Umgebungen siehe Bereiten Sie ein Air-Gapped-Upgrade vor.

Verhindern Sie die Beschädigung von virtuellen Maschinen-Images während der Upgrades

Stellen Sie vor dem Start des Upgrades sicher, dass die BackingImage CRD auf die SUSE Storage v1.7.2 Version aktualisiert ist.

Das Überspringen des CRD-Updates kann zu einer Beschädigung des Backing-Images führen, wie in Problem #10644 beschrieben.

Führen Sie die folgenden Schritte aus, bevor Sie mit dem Upgrade beginnen.

  1. Patchen Sie das SUSE Virtualization ManagedChart-Objekt, um verwandte Fehler und Warnungen zu vermeiden.

    kubectl patch managedchart harvester \
    -n fleet-local \
    --type='json' \
    -p='[
      {
        "op":"add",
        "path":"/spec/diff/comparePatches/-",
        "value": {
          "apiVersion":"apiextensions.k8s.io/v1",
          "jsonPointers":["/spec","/metadata/annotations", "/metadata/labels", "/status"],
          "kind":"CustomResourceDefinition",
          "name":"backingimages.longhorn.io"
        }
      }
    ]'
  2. Wenden Sie die SUSE Storage v1.7.2 BackingImage CRD an.

    apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    metadata:
      annotations:
        controller-gen.kubebuilder.io/version: v0.15.0
      labels:
        app.kubernetes.io/name: longhorn
        app.kubernetes.io/instance: longhorn
        app.kubernetes.io/version: v1.7.2
        longhorn-manager: ""
      name: backingimages.longhorn.io
    spec:
      conversion:
        strategy: Webhook
        webhook:
          clientConfig:
            service:
              name: longhorn-conversion-webhook
              namespace: longhorn-system
              path: /v1/webhook/conversion
              port: 9501
          conversionReviewVersions:
          - v1beta2
          - v1beta1
      group: longhorn.io
      names:
        kind: BackingImage
        listKind: BackingImageList
        plural: backingimages
        shortNames:
        - lhbi
        singular: backingimage
      scope: Namespaced
      versions:
      - additionalPrinterColumns:
        - description: The backing image name
          jsonPath: .spec.image
          name: Image
          type: string
        - jsonPath: .metadata.creationTimestamp
          name: Age
          type: date
        name: v1beta1
        schema:
          openAPIV3Schema:
            description: BackingImage is where Longhorn stores backing image object.
            properties:
              apiVersion:
                description: |-
                  APIVersion defines the versioned schema of this representation of an object.
                  Servers should convert recognized schemas to the latest internal value, and
                  may reject unrecognized values.
                  More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
                type: string
              kind:
                description: |-
                  Kind is a string value representing the REST resource this object represents.
                  Servers may infer this from the endpoint the client submits requests to.
                  Cannot be updated.
                  In CamelCase.
                  More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
                type: string
              metadata:
                type: object
              spec:
                x-kubernetes-preserve-unknown-fields: true
              status:
                x-kubernetes-preserve-unknown-fields: true
            type: object
        served: true
        storage: false
        subresources:
          status: {}
      - additionalPrinterColumns:
        - description: The system generated UUID
          jsonPath: .status.uuid
          name: UUID
          type: string
        - description: The source of the backing image file data
          jsonPath: .spec.sourceType
          name: SourceType
          type: string
        - description: The backing image file size in each disk
          jsonPath: .status.size
          name: Size
          type: string
        - description: The virtual size of the image (may be larger than file size)
          jsonPath: .status.virtualSize
          name: VirtualSize
          type: string
        - jsonPath: .metadata.creationTimestamp
          name: Age
          type: date
        name: v1beta2
        schema:
          openAPIV3Schema:
            description: BackingImage is where Longhorn stores backing image object.
            properties:
              apiVersion:
                description: |-
                  APIVersion defines the versioned schema of this representation of an object.
                  Servers should convert recognized schemas to the latest internal value, and
                  may reject unrecognized values.
                  More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
                type: string
              kind:
                description: |-
                  Kind is a string value representing the REST resource this object represents.
                  Servers may infer this from the endpoint the client submits requests to.
                  Cannot be updated.
                  In CamelCase.
                  More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
                type: string
              metadata:
                type: object
              spec:
                description: BackingImageSpec defines the desired state of the Longhorn
                  backing image
                properties:
                  checksum:
                    type: string
                  diskFileSpecMap:
                    additionalProperties:
                      properties:
                        evictionRequested:
                          type: boolean
                      type: object
                    type: object
                  diskSelector:
                    items:
                      type: string
                    type: array
                  disks:
                    additionalProperties:
                      type: string
                    description: Deprecated. We are now using DiskFileSpecMap to assign
                      different spec to the file on different disks.
                    type: object
                  minNumberOfCopies:
                    type: integer
                  nodeSelector:
                    items:
                      type: string
                    type: array
                  secret:
                    type: string
                  secretNamespace:
                    type: string
                  sourceParameters:
                    additionalProperties:
                      type: string
                    type: object
                  sourceType:
                    enum:
                    - download
                    - upload
                    - export-from-volume
                    - restore
                    - clone
                    type: string
                type: object
              status:
                description: BackingImageStatus defines the observed state of the Longhorn
                  backing image status
                properties:
                  checksum:
                    type: string
                  diskFileStatusMap:
                    additionalProperties:
                      properties:
                        lastStateTransitionTime:
                          type: string
                        message:
                          type: string
                        progress:
                          type: integer
                        state:
                          type: string
                      type: object
                    nullable: true
                    type: object
                  diskLastRefAtMap:
                    additionalProperties:
                      type: string
                    nullable: true
                    type: object
                  ownerID:
                    type: string
                  size:
                    format: int64
                    type: integer
                  uuid:
                    type: string
                  virtualSize:
                    description: Virtual size of image, which may be larger than physical
                      size. Will be zero until known (e.g. while a backing image is uploading)
                    format: int64
                    type: integer
                type: object
            type: object
        served: true
        storage: true
        subresources:
          status: {}

Bekannte Probleme

1. Upgrade hängt im "Pre-draining" Zustand fest

Eine virtuelle Maschine mit einer Container-Disk kann aufgrund einer Einschränkung der Live-Migrationsfunktion nicht migriert werden. Dies führt dazu, dass der Upgrade-Prozess im "Pre-draining" Zustand festhängt.

Stoppen Sie die virtuellen Maschinen manuell, um den Upgrade-Prozess fortzusetzen.

Verwandtes Problem: #7005

2. Upgrade hängt beim Warten auf das Bundle fest

Dieses Problem wird durch eine Wettlaufbedingung verursacht, wenn der SUSE® Rancher Prime: Continuous Delivery Agent (fleet-agent) neu bereitgestellt wird. Die folgenden Fehlermeldungen zeigen an, dass das Problem besteht.

> kubectl get bundles -n fleet-local
NAME                                          BUNDLEDEPLOYMENTS-READY   STATUS
mcc-harvester                                 0/1                       ErrApplied(1) [Cluster fleet-local/local: encountered 2 deletion errors. First is: admission webhook "validator.harvesterhci.io" denied the request: Internal error occurred: no route match found for DELETE /v1, Kind=Secret harvester-system/sh.helm.release.v1.harvester.v2]
mcc-harvester-crd                             0/1                       ErrApplied(1) [Cluster fleet-local/local: admission webhook "validator.harvesterhci.io" denied the request: Internal error occurred: no route match found for DELETE /v1, Kind=Secret harvester-system/sh.helm.release.v1.harvester-crd.v1]

Sie können das folgende Skript ausführen, um das Problem zu beheben.

#!/bin/bash

patch_fleet_bundle() {
  local bundleName=$1
  local generation=$(kubectl get -n fleet-local bundle ${bundleName} -o jsonpath='{.spec.forceSyncGeneration}')
  local new_generation=$((generation+1))
  patch_manifest="$(mktemp)"
  cat > "$patch_manifest" <<EOF
{
  "spec": {
    "forceSyncGeneration": $new_generation
  }
}
EOF
  echo "patch bundle to new generation: $new_generation"
  kubectl patch -n fleet-local bundle ${bundleName}  --type=merge --patch-file $patch_manifest
  rm -f $patch_manifest
}

echo "removing harvester validating webhook"
kubectl delete validatingwebhookconfiguration harvester-validator

for bundle in mcc-harvester-crd mcc-harvester
do
  patch_fleet_bundle ${bundle}
done

echo "removing longhorn services"
kubectl delete svc longhorn-engine-manager -n longhorn-system --ignore-not-found=true
kubectl delete svc longhorn-replica-manager -n longhorn-system --ignore-not-found=true

3. Upgrade bleibt beim Warten auf SUSE® Rancher Prime: Continuous Delivery hängen

Beim Upgrade von v1.3.2 auf v1.4.0 kann der Upgrade-Prozess beim Warten darauf, dass SUSE® Rancher Prime: Continuous Delivery bereit ist, hängen bleiben. Dieses Problem wird durch eine Wettlaufbedingung verursacht, wenn SUSE Rancher Prime neu bereitgestellt wird.

Überprüfen Sie die SUSE Virtualization-Protokolle und die SUSE® Rancher Prime: Continuous Delivery-Historie auf die folgenden Indikatoren:

  • Das Manifest-Pod bleibt im deployed-Status hängen.

  • Das Upgrade ist ausstehend mit einer Chart-Version, die bereitgestellt wurde.

Beispiel:

> kubectl logs -n harvester-system -l harvesterhci.io/upgradeComponent=manifest
wait helm release cattle-fleet-system fleet fleet-104.0.2+up0.10.2 0.10.2 deployed

> helm history -n cattle-fleet-system fleet
REVISION    UPDATED                     STATUS             CHART                    APP VERSION    DESCRIPTION
26          Tue Dec 10 03:09:13 2024    superseded         fleet-103.1.5+up0.9.5    0.9.5          Upgrade complete
27          Sun Dec 15 09:26:54 2024    superseded         fleet-103.1.5+up0.9.5    0.9.5          Upgrade complete
28          Sun Dec 15 09:27:03 2024    superseded         fleet-103.1.5+up0.9.5    0.9.5          Upgrade complete
29          Mon Dec 16 05:57:03 2024    deployed           fleet-103.1.5+up0.9.5    0.9.5          Upgrade complete
30          Mon Dec 16 05:57:13 2024    pending-upgrade    fleet-103.1.5+up0.9.5    0.9.5          Preparing upgrade

Sie können den folgenden Befehl ausführen, um das Problem zu beheben.

helm rollback fleet -n cattle-fleet-system <last-deployed-revision>

4. Upgrade startet unerwartet neu, nachdem die Schaltfläche "Ignorieren" angeklickt wurde

Wenn Sie Rancher verwenden, um SUSE Virtualization zu upgraden, zeigt die Rancher-Benutzeroberfläche einen Dialog mit einer Schaltfläche mit der Bezeichnung "Ignorieren" an. Das Klicken auf diese Schaltfläche kann zu den folgenden Problemen führen:

  • Der status-Abschnitt des harvesterhci.io/v1beta1/upgrade CR wird gelöscht, was den Verlust aller wichtigen Informationen über das Upgrade zur Folge hat.

  • Der Upgrade-Prozess startet unerwartet neu.

Dieses Problem betrifft Rancher v2.10.x, das v1.0.2, v1.0.3 und v1.0.4 der Harvester UI Extension verwendet. Alle SUSE Virtualization UI-Versionen sind nicht betroffen. Das Problem ist in der Harvester UI Extension v1.0.5 und v1.5.0 behoben.

Um dieses Problem zu vermeiden, führen Sie eine der folgenden Maßnahmen aus:

  • Verwenden Sie die SUSE Virtualization Benutzeroberfläche für Upgrades. Das Klicken auf die Schaltfläche "Ignorieren" in der SUSE Virtualization Benutzeroberfläche führt nicht zu unerwartetem Verhalten.

  • Anstatt die Schaltfläche in der Rancher Benutzeroberfläche zu klicken, führen Sie den folgenden Befehl gegen den Cluster aus:

    kubectl -n harvester-system label upgrades -l harvesterhci.io/latestUpgrade=true harvesterhci.io/read-message=true

Verwandtes Problem: #7791

5. 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 in der SUSE Storage Benutzeroberfläche 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