Solução de problemas do cluster do High Availability

Esta tabela lista sintomas comuns do cluster e as respectivas soluções.
Sintoma
Resolução
A conectividade SSH falha entre a estação de trabalho Windows e um nó Ubuntu.
Corrija as credenciais SSH ou a configuração de rede para que a estação de trabalho possa acessar cada nó.
O acesso à interface do usuário da Web está bloqueado porque o cluster e o projeto implementado usam portas diferentes.
Alinhe a porta do MecanismoDeApresentaçãoDaWeb do projeto com a porta Web configurada do cluster, por padrão, 80 para HTTP ou 443 para HTTPS.
O banco de dados para de aceitar gravações.
Esse problema ocorre quando dois dos três nós falham e o banco de dados perde o quórum.
Restaure pelo menos um nó com falha para estabelecer o quórum e retomar as gravações.
Faltam dados persistentes após a desinstalação do cluster.
A desinstalação do cluster remove o armazenamento persistente.
Recupere os dados somente de um backup criado antes da desinstalação.
O painel do cluster exibe um status que parece desatualizado ou inesperado.
Atualize o painel.
Se o status ainda parecer incorreto, verifique Diagnósticos e os logs exportados para confirmar o status real do pod e do nó.
A implementação de um projeto grande que excede o limite de memória do tempo de execução faz com que a implementação seja reportada como bem-sucedida no Studio, mas o tempo de execução seja encerrado imediatamente, com poucas informações registradas no log.
  1. Para fazer backup dos valores atuais do Helm e do histórico de revisões, execute:
    helm get values ftoptix -n ftoptix > pre-change-values-backup.yaml && helm history ftoptix -n ftoptix
  2. Para confirmar se a RAM do nó é suficiente para o novo limite de memória, execute:
    kubectl describe node <node-name> | grep -A2 "Capacity:"
  3. Para aplicar a substituição, execute:
    helm upgrade ftoptix <chart-path> -n ftoptix --reuse-values --set resources.runtime.requests.memory=<value> --set resources.runtime.limits.memory=<value>
  4. Para verificar se os pods adotaram o novo limite e estão íntegros, execute:
    kubectl rollout status statefulset/ftoptix-core-ha-runtime -n ftoptix
                      kubectl get pods -n ftoptix
                      kubectl describe pod ftoptix-core-ha-runtime-0 -n ftoptix | grep -A2 "Limits:"
  5. Para confirmar a alteração, implemente o projeto novamente, confirme se o tempo de execução atinge o estado em execução ou ativo e confirme se a interface do usuário Web está acessível.
O Kubernetes retorna 401 Unauthorized, a obtenção da identidade do tempo de execução falha, o tempo de execução entra no modo de demonstração, a autorização do servidor de atualização falha de forma intermitente ou os pods do tempo de execução não se recuperam conforme esperado.
Esses sintomas geralmente resultam de uma diferença de horário entre os nós do cluster.
Configure todos os nós para usar as mesmas fontes NTP aprovadas, restaure a sincronização de horário, confirme se os relógios diferem em no máximo 1 segundo e tente executar novamente a operação que apresentou falha.
Não continue o provisionamento se algum nó não estiver sincronizado ou apresentar uma diferença de 5 segundos ou mais.
Dê sua opinião
Tem dúvidas ou comentários sobre esta documentação? Por favor, envie seu comentário aqui.
Normal