|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
Fazer upgrade da v1.4.1 ou v1.4.2 para v1.4.3
Informações gerais
Um botão Upgrade aparece na tela Dashboard sempre que uma nova versão SUSE Virtualization para a qual você pode fazer upgrade se torna disponível. Para mais informações, veja Iniciar um upgrade.
As versões SUSE Virtualization v1.4.2 e v1.4.3 usam a mesma versão menor de SUSE® Rancher Prime: RKE2 (v1.31). Isso permite que você faça upgrade diretamente da v1.4.1 para a v1.4.3.
Para ambientes air-gapped, veja Preparar um upgrade air-gapped.
Problemas conhecidos
1. Upgrade air-gapped travado com erro ImagePullBackOff nos pods do Fluentd e do Fluent Bit
O upgrade pode ficar travado no início do processo, conforme indicado por 0% de progresso e itens marcados como Pendente na caixa de diálogo Upgrade da interface do usuário SUSE Virtualization.
Especificamente, os pods do Fluentd e do Fluent Bit podem ficar travados no status ImagePullBackOff. Para verificar o status dos pods, execute os seguintes 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 7m42sIsso ocorre porque as seguintes imagens de contêiner não estão pré-carregadas nos nós do cluster nem foram baixadas da 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 corrigir o problema, execute qualquer uma das seguintes ações:
-
Atualize o CR de Logging para usar as imagens que já estão pré-carregadas nos nós do cluster. Para fazer isso, execute os seguintes comandos contra o cluster:
# 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\"}}]"O status dos pods do Fluentd e do Fluent Bit deve mudar para
Runningem breve, e o processo de upgrade deve continuar após o CR de Logging ser atualizado. Se o status do pod do Fluentd ainda estiverImagePullBackOff, você pode excluir o pod para forçá-lo a reiniciar.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 -
Em um computador com acesso à internet, baixe as imagens de contêiner necessárias e, em seguida, exporte-as para um arquivo TAR. Em seguida, transfira o arquivo TAR para os nós do cluster e importe as imagens executando os seguintes comandos em cada nó:
# 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.tarO processo de upgrade deve continuar após as imagens serem pré-carregadas.
-
(Não recomendado) Reinicie o processo de upgrade com o registro desativado. Certifique-se de que a caixa de seleção Ativar Registro na caixa de diálogo Upgrade não esteja selecionada.
-
Problema relacionado: #7955
2. Volumes excessivos
Na versão SUSE Virtualization v1.4.3, que utiliza a versão SUSE Storage v1.7.3, volumes excessivos (por exemplo, 999999 Gi de tamanho) são marcados como Não Pronto e não podem ser excluídos.
Para solucionar esse problema, siga estas etapas:
-
Remova temporariamente a regra do webhook PVC.
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 -
Aguarde a exclusão do PVC relacionado.
-
Restaure a regra do webhook PVC para reabilitar a validação.
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"}}]'
O problema será resolvido na versão SUSE Storage v1.8.2, que provavelmente será incluída na versão SUSE Virtualization v1.5.1.
3. Usuários não-root em clusters de convidados incapazes de acessar volumes RWX
Usuários não-root em clusters de convidados encontram erros inesperados de "Permissão negada" ao acessar volumes RWX. Isso é causado por um problema de regressão na versão nfs-ganesha v6.0+, que afeta a versão v1.7.3 da imagem longhorn-share-manager.
Você pode resolver o problema substituindo longhorn-share-manager:v1.7.3 pela imagem corrigida longhorn-share-manager:v1.7.3-hotfix-1.
|
Não use a imagem corrigida se você não for afetado pelo problema. |
-
Edite o DaemonSet
longhorn-managerexecutando o seguinte comando:kubectl -n longhorn-system edit daemonset/longhorn-manager -
No campo
spec.containers.command, altere o--share-manager-imageparalonghornio/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 ... -
Uma vez que a atualização seja aplicada, reinicie as cargas de trabalho que estão usando volumes RWX.
|
Se você estiver usando a imagem corrigida e quiser fazer upgrade para SUSE Virtualization v1.5.x, deve editar o DaemonSet |
4. Máquinas virtuais que usam volumes RWX migráveis reiniciam inesperadamente
Máquinas virtuais que usam volumes RWX migráveis reiniciam inesperadamente quando os pods do plugin CSI são reiniciados. Esse problema afeta SUSE Virtualization v1.4.x, v1.5.0 e v1.5.1.
A solução alternativa é desativar a configuração Excluir Automaticamente o Pod de Trabalho Quando o Volume for Desconectado Inesperadamente no SUSE Storage UI antes de iniciar o upgrade. Você deve habilitar a configuração novamente assim que o upgrade for concluído.
O problema será corrigido na versão SUSE Storage v1.8.3, v1.9.1 e versões posteriores. SUSE Virtualization v1.6.0 incluirá SUSE Storage v1.9.1.