Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

Actualiza de v1.4.2 o v1.4.3 a v1.5.0

Información general

Un botón de Actualizar versión aparece en la pantalla del Tablero siempre que una nueva versión SUSE Virtualization a la que puedes actualizar esté disponible. Para más información, consulta Iniciar una actualización de versión.

Puedes actualizar directamente de v1.4.2 a v1.5.0 porque SUSE Virtualization permite un máximo de una actualización de versión menor para los componentes subyacentes. SUSE Virtualization v1.4.2 y v1.4.3 utilizan la misma versión menor de SUSE® Rancher Prime: RKE2 (v1.31), mientras que SUSE Virtualization v1.5.0 utiliza la siguiente versión menor (v1.32).

Para información sobre cómo actualizar versión SUSE Virtualization en entornos aislados, consulta Preparar una actualización de versión en entornos aislados.

Actualiza la extensión de Harvester UI en SUSE Rancher Prime v2.11.0

Debes usar v1.5.0 de la extensión Harvester UI para importar clústeres SUSE Virtualization v1.5.0 en Rancher v2.11.0.

En la interfaz de Rancher, ve a local → Apps → Repositorios.
Localiza el repositorio llamado harvester, y luego selecciona ⋮ → Actualizar.

Este repositorio tiene las siguientes propiedades:
- URL: https://github.com/harvester/harvester-ui-extension
- Rama: gh-pages
Ve a la pantalla de Extensiones.
Localiza la extensión llamada Harvester, y luego haz clic en Actualizar.
Selecciona la versión 1.5.0, y luego haz clic en Actualizar.
Permite un tiempo para que la extensión se actualice, y luego actualiza la pantalla.

Problemas conocidos

1. El estado de la URL de gestión es "NotReady" durante la actualización.

La consola SUSE Virtualization en algunos nodos puede mostrar Status: NotReady mientras la actualización está en progreso.

El estado correcto se muestra después de que la actualización a v1.5.0 se completa.

Problema relacionado: #7963

2. La actualización en entorno aislado se ha atascado con el error `ImagePullBackOff` en los pods de Fluentd y Fluent Bit.

La actualización puede quedar atascada al principio del proceso, como indica el 0% de progreso y los elementos marcados como Pendiente en el diálogo de Actualizar versión de la interfaz de usuario SUSE Virtualization.

Específicamente, los pods de Fluentd y Fluent Bit pueden quedar atascados en el estado ImagePullBackOff. Para comprobar el estado de los pods, ejecuta los siguientes comandos:

$ 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

Esto ocurre porque las siguientes imágenes de contenedor no están precargadas en los nodos del clúster ni se han descargado de internet:

ghcr.io/kube-logging/fluentd:v1.15-ruby3
ghcr.io/kube-logging/config-reloader:v0.0.5
fluent/fluent-bit:2.1.8

Para solucionar el problema, realiza cualquiera de las siguientes acciones:

Actualiza el CR de Logging para utilizar las imágenes que ya están precargadas en los nodos del clúster. Para hacer esto, ejecuta los siguientes comandos en el clúster:

# 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\"}}]"

El estado de los pods de Fluentd y Fluent Bit debería cambiar a Running en un momento y el proceso de actualización debería continuar después de que se actualice el CR de Logging. Si el estado del pod de Fluentd sigue siendo ImagePullBackOff, puedes eliminar el pod para forzar su reinicio.

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

En un ordenador con acceso a internet, descarga las imágenes de contenedor requeridas y luego expórtalas a un archivo TAR. A continuación, transfiere el archivo TAR a los nodos del clúster y luego importa las imágenes ejecutando los siguientes comandos en cada nodo:
```
# 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
```
El proceso de actualización debería continuar después de que las imágenes estén precargadas.
- (No recomendado) Reinicia el proceso de actualización con el registro deshabilitado. Asegúrate de que la casilla Habilitar registro en el diálogo de Actualización no esté seleccionada.

Problema relacionado: #7955

3. Actualización atascada esperando el CR del paquete `mcc-harvester`

Cuando actualizas desde una versión antigua de SUSE Virtualization (como v1.0.x, v1.1.x y v1.2.x), el proceso de actualización puede quedar atascado esperando que el CR del paquete mcc-harvester esté listo.

> kubectl get bundles -n fleet-local
NAME                                          BUNDLEDEPLOYMENTS-READY   STATUS
mcc-harvester                                 0/1                       Modified(1) [Cluster fleet-local/local]; kubevirt.kubevirt.io harvester-system/kubevirt modified {"spec":{"configuration":{"vmStateStorageClass":"vmstate-persistence"}}}

La causa raíz es que los últimos CRD de dependency_charts no se aplicaron, lo que ocurrió porque Helm no gestiona los CRD para SUSE Virtualization. Para permitir que la actualización continúe, ejecuta el siguiente script:

kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/kubevirt-operator/crds/crd-kubevirt.yaml

kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/csi-snapshotter/crds/volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/csi-snapshotter/crds/volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/csi-snapshotter/crds/volumesnapshots.yaml

kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/whereabouts/crds/whereabouts.cni.cncf.io_ippools.yaml
kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/whereabouts/crds/whereabouts.cni.cncf.io_overlappingrangeipreservations.yaml

Después de cinco minutos, comprueba el estado en el CR del paquete mcc-harvester de bundle.fleet.cattle.io/v1alpha1. Si el mismo error sigue apareciendo, debes volver a sincronizar el CR del paquete utilizando el siguiente script:

#!/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
}

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

También debes asegurarte de que el cdi CRD exista.

> kubectl get bundle -n fleet-local
NAMESPACE     NAME                                          BUNDLEDEPLOYMENTS-READY   STATUS
fleet-local   mcc-harvester                                 0/1                       Modified(1) [Cluster fleet-local/local]; cdi.cdi.kubevirt.io cdi missing

Si el cdi CRD existe, ejecuta el script patch_fleet_bundle para volver a sincronizar el CR del paquete mcc-harvester. De lo contrario, ejecuta el siguiente script para crear el cdi CRD:

kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/cdi/crds/cdi.yaml

Problema relacionado: #8163

4. Las máquinas virtuales que utilizan volúmenes RWX migrables se reinician inesperadamente

Las máquinas virtuales que utilizan volúmenes RWX migrables se reinician inesperadamente cuando se reinician los pods del plugin CSI. Este problema afecta a SUSE Virtualization v1.4.x, v1.5.0 y v1.5.1.

La solución alternativa es desactivar la configuración Eliminar automáticamente el pod de carga de trabajo cuando el volumen se desconecta inesperadamente en la interfaz de usuario SUSE Storage antes de iniciar la actualización. Debes habilitar la configuración nuevamente una vez que se complete la actualización.

El problema se solucionará en SUSE Storage v1.8.3, v1.9.1 y versiones posteriores. SUSE Virtualization v1.6.0 incluirá SUSE Storage v1.9.1.

Problemas relacionados: #8534 y #11158