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 "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.

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.