Política de detecção de falhas de nó

Pré-requisitos

O complemento Detector de problema de nó do CCE foi instalado no cluster.

Ativar a detecção de falhas de nó

1. Efetue logon no console do CCE e clique no nome do cluster para acessar o console do cluster.
2. No painel de navegação à esquerda, escolha Nodes. Verifique se o complemento npd foi instalado no cluster ou se o complemento foi atualizado para a versão mais recente. Depois que o complemento npd for instalado, você poderá usar a função de detecção de falhas.

   

3. Se o complemento npd estiver sendo executado corretamente, clique em Node Fault Detection Policy para exibir os itens atuais de detecção de falhas. Para obter detalhes sobre a lista de itens de verificação do npd, consulte Itens de verificação de NPD.
4. Se o resultado da verificação do nó atual for anormal, uma mensagem será exibida na lista de nós, indicando que a métrica é anormal.

   

5. Você pode clicar em Abnormal metrics e corrigir a falha conforme solicitado.

   

Itens de verificação personalizados

1. Efetue logon no console do CCE e clique no nome do cluster para acessar o console do cluster.
2. Escolha Node Management à esquerda e clique em Node Fault Detection Policy.
3. Na página exibida, visualize os itens de verificação atuais. Clique em Edit na coluna Operation e edite as verificações.
   Atualmente, as seguintes configurações são suportadas:

   • Enable/Disable: ativar ou desativar um item de verificação.
   • Target Node: por padrão, verifique os itens executados em todos os nós. Você pode alterar o limite de falhas com base em cenários especiais. Por exemplo, a verificação de recuperação de interrupção do ECS de preço à vista é executada apenas no nó do ECS de preço à vista.

     

   • Trigger Threshold: os limites padrão correspondem a cenários de falha comuns. Você pode personalizar e modificar os limites de falha conforme necessário. Por exemplo, altere o limite para disparar a exaustão da tabela de rastreamento de conexão de 90% para 80%.

     

   • Check Period: o período de verificação padrão é de 30 segundos. Você pode modificar esse parâmetro conforme necessário.

     

   • Troubleshooting Strategy: após ocorrer uma falha, você pode selecionar as estratégias listadas na tabela a seguir.

     Tabela 1 Estratégias de solução de problemas

     Estratégia de solução de problemas	Efeito
     Exceção de solicitação	Os eventos do Kubernetes são relatados.
     Desativação de agendamento	Os eventos do Kubernetes são relatados e a mancha do NoSchedule é adicionada ao nó.
     Evicção de carga de nós	Os eventos do Kubernetes são relatados e a mancha do NoExecute é adicionada ao nó. Essa operação eliminará cargas de trabalho no nó e interromperá os serviços. Tenha cuidado ao realizar esta operação.

Itens de verificação de NPD

Os itens de verificação são suportados apenas em 1.16.0 e versões posteriores.

Verifique os itens de cobertura de eventos e status.

• Relacionados a eventos

  Para itens de verificação relacionados a eventos, quando ocorre um problema, o NPD relata um evento para o servidor da API. O tipo de evento pode ser Normal (evento normal) ou Warning (evento anormal).

  Tabela 2 Itens de verificação relacionados a eventos

  Item de verificação	Função	Descrição
  OOMKilling	Ouvir os logs do kernel e verifique se os eventos OOM ocorrem e são relatados. Cenário típico: quando o uso de memória de um processo em um contêiner excede o limite, a OOM é acionada e o processo é encerrado.	Evento de aviso Objeto de escuta: /dev/kmsg Regra de correspondência: "Killed process \\d+ (.+) total-vm:\\d+kB, anon-rss:\\d+kB, file-rss:\\d+kB.*"
  TaskHung	Ouvir os logs do kernel e verifique se os eventos taskHung ocorrem e são relatados. Cenário típico: a suspensão de I/O de disco causa a suspensão do processo.	Evento de aviso Objeto de escuta: /dev/kmsg Regra de correspondência: "task \\S+:\\w+ blocked for more than \\w+ seconds\\."
  ReadonlyFilesystem	Verificar se o erro Remount root filesystem read-only ocorre no kernel do sistema ouvindo os logs do kernel. Cenário típico: um usuário separa um disco de dados de um nó por engano no ECS, e as aplicações gravam dados continuamente no ponto de montagem do disco de dados. Como resultado, ocorre um erro de I/O no kernel e o disco é montado novamente como um disco de somente leitura. NOTA: Se o rootfs dos node pods for do tipo mapeador de dispositivos, ocorrerá um erro no thin pool se um disco de dados for desanexado. Isso afetará o NPD e o NPD não poderá detectar falhas de nó.	Evento de aviso Objeto de escuta: /dev/kmsg Regra de correspondência: Remounting filesystem read-only

• Status-related

  Para itens de verificação relacionados ao status, quando ocorre um problema, o NPD relata um evento para o servidor da API e altera o status do nó de forma síncrona. Esta função pode ser usada em conjunto com o isolamento de falhas do Node-problem-controller para isolar nós.

  Se o período de verificação não for especificado nos seguintes itens de verificação, o período padrão será de 30 segundos.

  Tabela 3 Verificar componentes do sistema

  Item de verificação	Função	Descrição
  Erro no componente de rede do contêiner CNIProblem	Verificar o status dos componentes da CNI (componentes da rede do contêiner).	Nenhuma
  Erro no componente de tempo de execução do contêiner CRIProblem	Verificar o status do Docker e do contêiner dos componentes de CRI (componentes de tempo de execução do contêiner).	Objeto de verificar: Docker ou containerd
  Reinícios frequentes do Kubelet FrequentKubeletRestart	Retroceder periodicamente os logs do sistema para verificar se o componente importante de Kubelet reinicia com frequência.	Limite padrão: 10 reinícios em 10 minutos Se o Kubelet for reiniciado 10 vezes em 10 minutos, isso indica que o sistema é reiniciado com frequência e um alarme de falha é gerado. Objeto de escuta: logs no diretório /run/log/journal NOTA: Os sistemas operacionais Ubuntu e HCE 2.0 não suportam os itens de verificação anteriores devido a formatos de log incompatíveis.
  Reinícios frequentes do Docker FrequentDockerRestart	Retroceder periodicamente os logs do sistema para verificar se o tempo de execução do contêiner Docker é reiniciado com frequência.
  Reinícios frequentes do containerd FrequentContainerdRestart	Retroceder periodicamente os logs do sistema para verificar se o tempo de execução do contêiner containerd reinicia com frequência.
  erro de kubelet KubeletProblem	Verificar o status do componente importante de Kubelet.	Nenhuma
  erro de kube-proxy KubeProxyProblem	Verificar o status do componente importante de kube-proxy.	Nenhuma

  Tabela 4 Verificar métricas do sistema

  Item de verificação	Função	Descrição
  Tabela conntrack cheia ConntrackFullProblem	Verificar se a tabela conntrack está cheia.	Limite padrão: 90% Utilização: nf_conntrack_count Valor máximo: nf_conntrack_max
  Recursos de disco insuficientes DiskProblem	Verificar o uso do disco do sistema e dos discos de dados do CCE (incluindo o disco lógico de CRI e o disco lógico de kubelet) no nó.	Limite padrão: 90% Origem: df -h Atualmente, discos de dados adicionais não são suportados.
  Manipuladores de arquivo insuficientes FDProblem	Verificar se os manipuladores do arquivo FD estão esgotados.	Limite padrão: 90% Utilização: o primeiro valor em /proc/sys/fs/file-nr Valor máximo: o terceiro valor em /proc/sys/fs/file-nr
  Memória de nó insuficiente MemoryProblem	Verificar se a memória está gasta.	Limite padrão: 80% Uso: MemTotal-MemAvailable em /proc/meminfo Valor máximo: MemTotal em /proc/meminfo
  Recursos de processo insuficientes PIDProblem	Verificar se os recursos do processo PID estão esgotados.	Limite padrão: 90% Utilização: nr_threads in /proc/loadavg Valor máximo: menor valor entre /proc/sys/kernel/pid_max e /proc/sys/kernel/threads-max.

  Tabela 5 Verificar o armazenamento

  Item de verificação	Função	Descrição
  Disco de somente leitura DiskReadonly	Execute periodicamente testes de gravação no disco do sistema e nos discos de dados do CCE (incluindo o disco lógico de CRI e o disco lógico de Kubelet) do nó para verificar a disponibilidade dos discos importantes.	Caminhos de detecção: /mnt/paas/kubernetes/kubelet/ /var/lib/docker/ /var/lib/containerd/ /var/paas/sys/log/cceaddon-npd/ O arquivo temporário npd-disk-write-ping é gerado no caminho de detecção. Atualmente, discos de dados adicionais não são suportados.
  Erro do pool de armazenamento emptyDir EmptyDirVolumeGroupStatusError	Verificar se o grupo de volume efêmero no nó é normal. Impacto: o pod que depende do pool de armazenamento não pode gravar dados no volume temporário. O volume temporário é montado novamente como um sistema de arquivos somente leitura pelo kernel devido a um erro de I/O. Cenário típico: ao criar um nó, um usuário configura dois discos de dados como um pool de armazenamento de volume temporário. O usuário exclui alguns discos de dados por engano. Como resultado, o pool de armazenamento se torna anormal.	Período da detecção: 30s Origem: vgs -o vg_name, vg_attr Princípio: verifique se o VG (storage pool) está no estado P. Se sim, alguns PVs (discos de dados) são perdidos. Agendamento conjunto: o agendador pode identificar automaticamente um erro de pool de armazenamento PV e impedir que pods que dependem do pool de armazenamento sejam gendados para o nó. Cenário excepcional: o complemento NPD não pode detectar a perda de todos os PVs (discos de dados), resultando na perda de VGs (pools de armazenamento). Nesse caso, o kubelet isola automaticamente o nó, detecta a perda de VGs (pools de armazenamento) e atualiza os recursos correspondentes em nodestatus.allocatable para 0. Isso impede que os pods que dependem do pool de armazenamento sejam agendados para o nó. O dano de um único PV não pode ser detectado por este item de verificação, mas pelo item de verificação ReadonlyFilesystem.
  Erro do pool de armazenamento PV LocalPvVolumeGroupStatusError	Verificar o grupo PV no nó. Impacto: os pods que dependem do pool de armazenamento não podem gravar dados no volume persistente. O volume persistente é remontado como um sistema de arquivos somente leitura pelo kernel devido a um erro de I/O. Cenário típico: ao criar um nó, um usuário configura dois discos de dados como um pool de armazenamento de volume persistente. Alguns discos de dados são apagados por engano.
  Erro do ponto de montagem MountPointProblem	Verificar o ponto de montagem no nó. Definição excepcional: você não pode acessar o ponto de montagem executando o comando cd. Cenário típico: Network File System (NFS), por exemplo, obsfs e s3fs é montado em um nó. Quando a conexão é anormal devido a exceções de servidor do NFS de rede ou de par, todos os processos que acessam o ponto de montagem são suspensos. Por exemplo, durante uma atualização de cluster, um kubelet é reiniciado e todos os pontos de montagem são verificados. Se o ponto de montagem anormal for detectado, a atualização falhará.	Alternativamente, você pode executar o seguinte comando: for dir in `df -h | grep -v "Mounted on" | awk "{print \\$NF}"`;do cd $dir; done && echo "ok"
  I/O de disco suspensa DiskHung	Verificar se a suspensão de I/O ocorre em todos os discos no nó, ou seja, se as operações de leitura e gravação de I/O não são respondidas. Definição de suspensão de I/O: o sistema não responde a solicitações de I/O de disco e alguns processos estão no estado D. Cenário típico: os discos não podem responder devido a drivers de disco rígido do sistema operacional anormais ou falhas graves na rede subjacente.	Objeto de verificar: todos os discos de dados Origem: /proc/diskstat Alternativamente, você pode executar o seguinte comando: iostat -xmt 1 Limite: Uso médio: ioutil >= 0,99 Comprimento médio da fila de I/O: avgqu-sz >= 1 Volume médio de transferência de I/O: iops (w/s) + ioth (wMB/s) <= 1 NOTA: Em alguns sistemas operacionais, nenhum dado é alterado durante a I/O. Nesse caso, calcule o uso do tempo de I/O da CPU. O valor de iowait deve ser maior que 0,8.
  I/O de disco lenta DiskSlow	Verificar se todos os discos no nó têm I/Os lentas, ou seja, se as I/Os respondem lentamente. Cenário típico: os discos EVS têm I/Os lentas devido à flutuação da rede.	Objeto de verificar: todos os discos de dados Origem: /proc/diskstat Alternativamente, você pode executar o seguinte comando: iostat -xmt 1 Limite padrão: Latência média de I/O: await >= 5000 ms NOTA: Se as solicitações de I/O não forem respondidas e os dados await não forem atualizados, esse item de verificação será inválido.

  Tabela 6 Outros itens de verificação

  Item de verificação	Função	Descrição
  NTP anormal NTPProblem	Verificar se o serviço de sincronização de relógio de nó ntpd ou chronyd está sendo executado corretamente e se um desvio de tempo do sistema é causado.	Limite de deslocamento de relógio padrão: 8000 ms
  Erro no processo D ProcessD	Verificar se há um processo D no nó.	Limite padrão: 10 processos anormais detectados por três vezes consecutivas Origem: /proc/{PID}/stat Como alternativa, você pode executar o comando ps aux. Cenário excepcional: o item de verificação ProcessD ignora os processos D residentes (heartbeat e update) dos quais o driver SDI no nó do BMS depende.
  Erro de processo Z ProcessZ	Verificar se o nó tem processos no estado Z.
  Erro de ResolvConf ResolvConfFileProblem	Verificar se o arquivo ResolvConf foi perdido. Verificar se o arquivo ResolvConf está normal. Definição excepcional: nenhum servidor de resolução de nome de domínio upstream (nameserver) está incluído.	Objeto: /etc/resolv.conf
  Evento agendado existente ScheduledEvent	Verificar se existem eventos de migração ao vivo agendados no nó. Um evento de plano de migração ao vivo geralmente é acionado por uma falha de hardware e é um método de retificação automática de falhas na camada IaaS. Cenário típico: o host está defeituoso. Por exemplo, o ventilador está danificado ou o disco tem setores defeituosos. Como resultado, a migração ao vivo é acionada para VMs.	Origem: http://169.254.169.254/meta-data/latest/events/scheduled Este item de verificação é um recurso Alpha e está desativado por padrão.

  O componente de kubelet tem os seguintes itens de verificação padrão, que têm bugs ou defeitos. Você pode corrigi-los atualizando o cluster ou usando o NPD.

  Tabela 7 Itens de verificação padrão do kubelet

  Item de verificação	Função	Descrição
  Recursos de PID insuficientes. PIDPressure	Verificar se os PIDs são suficientes.	Intervalo: 10 segundos Limite: 90% Defeito: na versão 1.23.1 da comunidade e versões anteriores, este item de verificação torna-se inválido quando mais de 65535 PIDs são usados. Para obter detalhes, consulte issue 107107. Na versão 1.24 da comunidade e versões anteriores, thread-max não é considerado neste item de verificação.
  Memória insuficiente MemoryPressure	Verificar se a memória alocável para os contêineres é suficiente.	Intervalo: 10 segundos Limite: máx. 100 MiB Alocável = memória total de um nó – memória reservada de um nó Defeito: esse item de verificação verifica apenas a memória consumida pelos contêineres e não considera a consumida por outros elementos no nó.
  Recursos de disco insuficientes DiskPressure	Verificar o uso do disco e o uso de inodes dos discos do kubelet e do Docker.	Intervalo: 10 segundos Limite: 90%