O que fazer se um cluster estiver disponível, mas alguns nós não estiverem disponíveis?
Se o status do cluster estiver disponível, mas alguns nós do cluster não estiverem disponíveis, execute as seguintes operações para corrigir a falha:
Mecanismo para detectar indisponibilidade de nó
O Kubernetes fornece o mecanismo de pulsação para ajudá-lo a determinar a disponibilidade do nó. Para obter detalhes sobre o mecanismo e o intervalo, consulte Pulsações.
Localização de falha
Os métodos de solução de problemas são classificados com base na probabilidade de ocorrência das possíveis causas. É aconselhável verificar as possíveis causas de alta probabilidade para baixa probabilidade para localizar rapidamente a causa do problema.
Se a falha persistir após uma possível causa ser corrigida, verifique outras possíveis causas.
- Item de verificação 1: se o nó está sobrecarregado
- Item de verificação 2: se o ECS está excluído ou com defeito
- Item de verificação 3: se você pode fazer logon no ECS
- Item de verificação 4: se o grupo de segurança é modificado
- Item de verificação 5: se as regras de grupo de segurança contêm a política de grupo de segurança para a comunicação entre o nó principal e o nó de trabalho
- Item de verificação 6: se o disco é anormal
- Item de verificação 7: se os componentes internos são normais
- Item de verificação 8: se o endereço do DNS está correto
- Item de verificação 9: se o disco vdb no nó é excluído
- Item de verificação 10: se o serviço de Docker é normal
Item de verificação 1: se o nó está sobrecarregado
Sintoma
A conexão de nó no cluster é anormal. Vários nós relatam erros de gravação, mas os serviços não são afetados.
Localização de falha
- Efetue logon no console do CCE e clique no cluster. No painel de navegação, escolha Nodes. Clique em Monitor na linha do nó indisponível.
- Na parte superior da página exibida, clique em View More para acessar o console do AOM e exibir registros de monitoramento históricos.
Um uso muito alto de CPU ou memória do nó resultará em uma alta latência de rede ou sistema de disparo OOM. Portanto, o nó é exibido como indisponível.
Solução
- É aconselhável migrar serviços para reduzir as cargas de trabalho no nó e definir o limite superior de recursos para as cargas de trabalho.
- Limpe dados nos nós CCE no cluster.
- Limite as cotas de CPU e memória de cada contêiner.
- Adicione mais nós ao cluster.
- Você também pode reiniciar o nó no console do ECS.
- Adicione nós para implementar contêineres com uso intenso de memória separadamente.
- Redefina o nó. Para obter detalhes, consulte Redefinição de um nó.
Depois que o nó se torna disponível, a carga de trabalho é restaurada.
Item de verificação 2: se o ECS está excluído ou com defeito
- Verifique se o cluster está disponível.
Faça logon no console do CCE e verifique se o cluster está disponível.
- Se o cluster não estiver disponível, por exemplo, ocorrer um erro, consulte Como corrigir a falha quando o status do cluster está Unavailable?.
- Se o cluster estiver em execução, mas alguns nós no cluster não estiverem disponíveis, vá para 2.
- Faça logon no console do ECS e visualize o status do ECS.
- Se o status do ECS for Deleted, volte para o console do CCE, exclua o nó correspondente da lista de nós do cluster e crie outro.
- Se o status do ECS for Stopped ou Frozen, restaure o ECS primeiro. Demora cerca de 3 minutos para restaurar o ECS.
- Se o ECS estiver Faulty, reinicie o ECS para corrigir a falha.
- Se o status do ECS for Running, efetue logon no ECS para localizar a falha de acordo com Item de verificação 7: se os componentes internos são normais.
Item de verificação 3: se você pode fazer logon no ECS
- Efetue logon no console do ECS.
- Verifique se o nome do nó exibido na página é o mesmo da VM e se a senha ou chave pode ser usada para efetuar logon no nó.
Figura 2 Verificar o nome do nó exibido na página
Figura 3 Verificar o nome do nó na VM e se o nó pode ser conectado
Se os nomes de nó forem inconsistentes e a senha e a chave não puderem ser usadas para efetuar logon no nó, ocorreram problemas no Cloud-Init quando um ECS foi criado. Nesse caso, reinicie o nó e envie um tíquete de serviço ao pessoal do ECS para localizar a causa raiz.
Item de verificação 4: se o grupo de segurança é modificado
Faça logon no console da VPC. No painel de navegação, escolha Access Control > Security Groups e localize o grupo de segurança do nó principal do cluster.
O nome deste grupo de segurança está no formato de nome de cluster-cce-control-ID. Você pode procurar o grupo de segurança pelo cluster name.
Verifique se as regras no grupo de segurança foram modificadas. Para mais detalhes, consulte Configuração de regras do grupo de segurança do cluster.
Item de verificação 5: se as regras de grupo de segurança contêm a política de grupo de segurança para a comunicação entre o nó principal e o nó de trabalho
Verifique se existe tal política de grupo de segurança.
Quando um nó é adicionado a um cluster existente, se um bloco CIDR estendido for adicionado à VPC correspondente à sub-rede e a sub-rede for um bloco CIDR estendido, será necessário adicionar as três regras de grupo de segurança a seguir ao grupo de segurança do nó principal (o nome do grupo está no formato de nome do cluster-cce-control-número aleatório). Essas regras garantem que os nós adicionados ao cluster estejam disponíveis. (Essa etapa não é necessária se um bloco CIDR estendido tiver sido adicionado à VPC durante a criação do cluster.)
Para obter detalhes sobre segurança, consulte Configuração de regras do grupo de segurança do cluster.
Item de verificação 6: se o disco é anormal
Um disco de dados de 100 GB dedicado para o Docker é anexado ao novo nó. Se o disco de dados for desinstalado ou danificado, o serviço de Docker se tornará anormal e o nó ficará indisponível.
Clique no nome do nó para verificar se o disco de dados montado no nó foi desinstalado. Se o disco for desinstalado, monte um disco de dados no nó novamente e reinicie o nó. Em seguida, o nó pode ser recuperado.
Item de verificação 7: se os componentes internos são normais
- Faça logon no ECS onde o nó indisponível está localizado.
- Execute o seguinte comando para verificar se os componentes de PaaS são normais:
systemctl status kubelet
Se o comando for executado com sucesso, o status de cada componente é exibido como active, conforme mostrado na figura a seguir.
Se o status do componente não estiver active, execute os seguintes comandos (usando o componente canal com defeito como exemplo):
Execute systemctl restart canal para reiniciar o componente.
Depois de reiniciar o componente, execute systemctl status canal para verificar o status.
- Se o comando de reinicialização não for executado, execute o seguinte comando para verificar o status de execução do processo monitrc:
ps -ef | grep monitrc
Se o processo monitrc existir, execute o seguinte comando para eliminar esse processo. O processo monitrc será reiniciado automaticamente após ser eliminado.
kill -s 9 `ps -ef | grep monitrc | grep -v grep | awk '{print $2}'`
Item de verificação 8: se o endereço do DNS está correto
- Depois de fazer logon no nó, verifique se alguma falha de resolução de nome de domínio foi registrada no arquivo /var/log/cloud-init-output.log.
cat /var/log/cloud-init-output.log | grep resolv
Se a saída do comando contiver as seguintes informações, o nome de domínio não poderá ser resolvido:
Could not resolve host: test.obs.ap-southeast-1.myhuaweicloud.com; Unknown error
- No nó, faça ping o nome de domínio que não pode ser resolvido na etapa anterior para verificar se o nome de domínio pode ser resolvido no nó.
ping test.obs.ap-southeast-1.myhuaweicloud.com
- Caso contrário, o DNS não pode resolver o endereço IP. Verifique se o endereço do DNS no arquivo /etc/resolv.conf é o mesmo configurado na sub-rede da VPC. Na maioria dos casos, o endereço do DNS no arquivo está configurado incorretamente. Como resultado, o nome de domínio não pode ser resolvido. Corrija a configuração do DNS da sub-rede da VPC e redefina o nó.
- Se sim, a configuração do endereço do DNS está correta. Verifique se há outras falhas.
Item de verificação 9: se o disco vdb no nó é excluído
Se o disco vdb num nó for excluído, pode consultar este tópico para restaurar o nó.
Item de verificação 10: se o serviço de Docker é normal
- Execute o seguinte comando para verificar se o serviço de Docker está em execução:
systemctl status docker
Se o comando falhar ou o status do serviço de Docker não estiver ativo, localize a causa ou entre em contato com o suporte técnico, se necessário.
- Execute o seguinte comando para verificar o número de contêineres no nó:
docker ps -a | wc -l
Se o comando for suspenso, a execução do comando demorar muito tempo ou se houver mais de 1000 contêineres anormais, verifique se as cargas de trabalho são repetidamente criadas e excluídas. Se um grande número de contêineres é frequentemente criado e excluído, um grande número de contêineres anormais pode ocorrer e não pode ser limpo em tempo hábil.
Nesse caso, interrompa a criação e exclusão repetidas da carga de trabalho ou use mais nós para compartilhar a carga de trabalho. Geralmente, os nós serão restaurados após um período de tempo. Se necessário, execute o comando docker rm {container_id} para limpar manualmente os contêineres anormais.
