Solução de problemas
Use os ponteiros fornecidos aqui para solucionar problemas que você pode encontrar ao instalar e usar o Astra Trident.
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 .
|
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çãokubectl -n trident describe deployment trident
ekubectl -n trident describe pod trident--**
pode fornecer informações adicionais. A obtenção de logs do kubelet (por exemplo, viajournalctl -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 pesquisandolevel=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 detorc
. - 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, incluadebugTraceFlags: {“api”:true, “method”:true,}
para obter chamadas de API e transversais de método nos logs do Trident. Os backends existentes podem terdebugTraceFlags
sido configurados com umtridentctl 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 serpcbind
está em execução. Você pode verificar o statusrpcbind
do serviço executando umsystemctl 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 usandotridentctl 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 aotrident-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
tridentctl uninstall
comando para remover o Trident. Baixe o desejado "Versão Trident" e instale usando otridentctl 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êmassociated 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çãokubectl 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.