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.

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 a "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ê 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ê quiser fazer o downgrade para uma versão anterior do Trident, primeiro execute o tridentctl uninstall comando para remover o Trident. Baixe o desejado "Versão Trident" e instale usando o tridentctl install comando.

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.