Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Solução de problemas

Colaboradores

Use os ponteiros fornecidos aqui para solucionar problemas que você pode encontrar ao instalar e usar o Astra Trident.

Observação Para obter ajuda com o Astra Trident, crie um pacote de suporte usando tridentctl logs -a -n trident e envie para `NetApp Support <Getting Help>`o .
Dica Para obter uma lista abrangente de artigos de solução de problemas, consulte "Base de Conhecimento NetApp (login necessário)" . Você também encontrará informações sobre a solução de problemas relacionados ao Astra "aqui".

Resolução de problemas gerais

  • Se o pod Trident não aparecer corretamente (por exemplo, quando o pod Trident está preso ContainerCreating na fase com menos de dois contêineres prontos), em execução kubectl -n trident describe deployment trident e kubectl -n trident describe pod trident--** pode fornecer informações adicionais. A obtenção de logs do kubelet (por exemplo, via journalctl -xeu kubelet) também pode ser útil.

  • Se não houver informações suficientes nos logs do Trident, você pode tentar ativar o modo de depuração para o Trident passando o -d sinalizador para o parâmetro de instalação com base na opção de instalação.

    Em seguida, confirme se a depuração é definida usando ./tridentctl logs -n trident e pesquisando level=debug msg no log.

    Instalado com Operador
    kubectl patch torc trident -n <namespace> --type=merge -p '{"spec":{"debug":true}}'

    Isso reiniciará todos os pods do Trident, o que pode levar vários segundos. Você pode verificar isso observando a coluna 'IDADE' na saída do kubectl get pod -n trident.

    Para Astra Trident 20,07 e 20,10 utilização tprov em vez de torc .

    Instalado com Helm
    helm upgrade <name> trident-operator-21.07.1-custom.tgz --set tridentDebug=true`
    Instalado com tridentctl
    ./tridentctl uninstall -n trident
    ./tridentctl install -d -n trident
  • Você também pode obter logs de depuração para cada back-end, incluindo debugTraceFlags na sua definição de back-end. Por exemplo, inclua debugTraceFlags: {“api”:true, “method”:true,} para obter chamadas de API e transversais de método nos logs do Trident. Os backends existentes podem ter debugTraceFlags sido configurados com um tridentctl backend update.

  • Ao usar o RedHat CoreOS, certifique-se de que iscsid está habilitado nos nós de trabalho e iniciado por padrão. Isso pode ser feito usando OpenShift MachineConfigs ou modificando os modelos de ignição.

  • Um problema comum que você pode encontrar ao usar o Trident com "Azure NetApp Files" é quando os segredos do locatário e do cliente vêm de um Registro de aplicativo com permissões insuficientes. Para obter uma lista completa dos requisitos do Trident, consulte "Azure NetApp Files" Configuração.

  • Se houver problemas com a montagem de um PV em um recipiente, certifique-se de que rpcbind está instalado e funcionando. Use o gerenciador de pacotes necessário para o sistema operacional do host e verifique se rpcbind está em execução. Você pode verificar o status rpcbind do serviço executando um systemctl status rpcbind ou seu equivalente.

  • Se um back-end do Trident relatar que ele está failed no estado apesar de ter trabalhado antes, provavelmente será causado pela alteração das credenciais do SVM/administrador associadas ao back-end. Atualizar as informações de back-end usando tridentctl update backend ou saltando o pod Trident corrigirá esse problema.

  • Se você estiver atualizando seu cluster Kubernetes e/ou Trident para usar snapshots de volume beta, certifique-se de que todos os CRS de snapshot alfa existentes sejam completamente removidos. Em seguida, você pode usar o tridentctl obliviate alpha-snapshot-crd comando para excluir CRDs de snapshot alfa. "este blog"Consulte para compreender as etapas envolvidas na migração de snapshots alfa.

  • Se você encontrar problemas de permissão ao instalar o Trident com Docker como o runtime do contentor, tente a instalação do Trident com o --in cluster=false sinalizador. Isso não usará um pod do instalador e evitará problemas de permissão vistos devido ao trident-installer usuário.

  • Utilize o uninstall parameter <Uninstalling Trident> para limpar após uma falha de funcionamento. Por padrão, o script não remove os CRDs que foram criados pelo Trident, tornando seguro desinstalar e instalar novamente mesmo em uma implantação em execução.

  • Se você estiver procurando fazer o downgrade para uma versão anterior do Trident, primeiro execute o tridenctl uninstall comando para remover o Trident. Baixe o desejado "Versão Trident" e instale usando o tridentctl install comando. Considere apenas um downgrade se não houver novos PVS criados e se não houver alterações em PVs/backends/classes de armazenamento já existentes. Como o Trident agora usa CRDs para manter o estado, todas as entidades de armazenamento criadas (backends, classes de armazenamento, PVS e instantâneos de volume) têm associated CRD objects <Kubernetes CustomResourceDefinition Objects> em vez de dados gravados no PV que foram usados pela versão instalada anterior do Trident. PVS recém-criados não serão utilizáveis ao voltar para uma versão anterior. Alterações feitas em objetos, como backends, PVS, classes de armazenamento e snapshots de volume (criados/atualizados/excluídos) não serão visíveis para o Trident quando desclassificados. O PV que foi usado pela versão anterior do Trident instalado ainda será visível para o Trident. Voltar para uma versão anterior não interromperá o acesso para PVS que já foram criados usando a versão mais antiga, a menos que tenham sido atualizados.

  • Para remover completamente o Trident, execute o tridentctl obliviate crd comando. Isso removerá todos os objetos CRD e desdefinirá as CRDs. O Trident não gerenciará mais nenhum PVS que já tenha provisionado.

    Observação Depois disso, o Trident precisará ser reconfigurado do zero.
  • Após uma instalação bem-sucedida, se um PVC estiver preso na Pending fase, a execução kubectl describe pvc pode fornecer informações adicionais sobre por que a Trident não conseguiu fornecer um PV para este PVC.

Solução de problemas de uma implantação de Trident mal sucedida usando o operador

Se você estiver implantando o Trident usando o operador, o status das TridentOrchestrator alterações será alterado de Installing para Installed. Se você observar o Failed status e o operador não conseguir se recuperar sozinho, você deve verificar os logs do operador executando o seguinte comando:

tridentctl logs -l trident-operator

Arrastar os logs do contentor do operador Trident pode apontar para onde está o problema. Por exemplo, um desses problemas poderia ser a incapacidade de extrair as imagens de contentor necessárias de Registros upstream em um ambiente com airgapped.

Para entender por que a instalação do Trident não foi bem-sucedida, você deve dar uma olhada no TridentOrchestrator status.

kubectl describe torc trident-2
Name:         trident-2
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  trident.netapp.io/v1
Kind:         TridentOrchestrator
...
Status:
  Current Installation Params:
    IPv6:
    Autosupport Hostname:
    Autosupport Image:
    Autosupport Proxy:
    Autosupport Serial Number:
    Debug:
    Image Pull Secrets:         <nil>
    Image Registry:
    k8sTimeout:
    Kubelet Dir:
    Log Format:
    Silence Autosupport:
    Trident Image:
  Message:                      Trident is bound to another CR 'trident'
  Namespace:                    trident-2
  Status:                       Error
  Version:
Events:
  Type     Reason  Age                From                        Message
  ----     ------  ----               ----                        -------
  Warning  Error   16s (x2 over 16s)  trident-operator.netapp.io  Trident is bound to another CR 'trident'

Este erro indica que já existe um TridentOrchestrator que foi usado para instalar o Trident. Como cada cluster do Kubernetes pode ter apenas uma instância do Trident, o operador garante que, a qualquer momento, só exista uma ativa TridentOrchestrator que possa criar.

Além disso, observar o status dos pods do Trident geralmente pode indicar se algo não está certo.

kubectl get pods -n trident

NAME                                READY   STATUS             RESTARTS   AGE
trident-csi-4p5kq                   1/2     ImagePullBackOff   0          5m18s
trident-csi-6f45bfd8b6-vfrkw        4/5     ImagePullBackOff   0          5m19s
trident-csi-9q5xc                   1/2     ImagePullBackOff   0          5m18s
trident-csi-9v95z                   1/2     ImagePullBackOff   0          5m18s
trident-operator-766f7b8658-ldzsv   1/1     Running            0          8m17s

Você pode ver claramente que os pods não são capazes de inicializar completamente porque uma ou mais imagens de contentor não foram obtidas.

Para resolver o problema, você deve editar o TridentOrchestrator CR. Alternativamente, você pode excluir TridentOrchestrator e criar um novo com a definição modificada e precisa.

Solução de problemas de uma implantação do Trident mal sucedida usando tridentctl

Para ajudar a descobrir o que deu errado, você pode executar o instalador novamente usando o -d argumento, que irá ativar o modo de depuração e ajudá-lo a entender qual é o problema:

./tridentctl install -n trident -d

Depois de resolver o problema, você pode limpar a instalação da seguinte forma e, em seguida, executar o tridentctl install comando novamente:

./tridentctl uninstall -n trident
INFO Deleted Trident deployment.
INFO Deleted cluster role binding.
INFO Deleted cluster role.
INFO Deleted service account.
INFO Removed Trident user from security context constraint.
INFO Trident uninstallation succeeded.