Detector de problema de nó do CCE
Introdução
O detector de problemas de nó do CCE (NPD) é um complemento que monitora eventos anormais de nós de cluster e se conecta a uma plataforma de monitoramento de terceiros. É um daemon em execução em cada nó. Ele coleta problemas de nó de diferentes daemons e os reporta ao servidor da API. O complemento NPD pode ser executado como um daemon ou DaemonSet.
Para obter mais informações, consulte node-problem-detector.
Restrições
- Ao usar esse complemento, não formate ou particione discos de nó.
- Cada processo de NPD ocupa 30 m de CPU e 100 MB de memória.
Permissões
Para monitorar os logs do kernel, o complemento NPD precisa ler o host /dev/kmsg. Portanto, o modo privilegiado deve ser ativado. Para mais detalhes, veja privileged.
Além disso, o CCE mitiga os riscos de acordo com o princípio do privilégio mínimo. Apenas os seguintes privilégios estão disponíveis para a execução do NPD:
- cap_dac_read_search: permissão para acessar /run/log/journal.
- cap_sys_admin: permissão para acessar /dev/kmsg.
Instalar o complemento
- Efetue logon no console do CCE e clique no nome do cluster para acessar o console do cluster. Escolha Add-ons no painel de navegação, encontre CCE Node Problem Detector na direita, e clique em Install.
- Na página Install Add-on, configure as especificações.
Tabela 1 Configuração do NPD Parâmetro
Descrição
Add-on Specifications
As especificações podem ser Custom.
Instances
Se você selecionar Custom, poderá ajustar o número de pods conforme necessário.
Containers
Se você selecionar Custom, poderá ajustar as especificações do contêiner conforme necessário.
- Configure os parâmetros do complemento.
Somente as versões v1.16.0 e posteriores suportam as configurações.
Tabela 2 Parâmetros do NPD Parâmetro
Descrição
common.image.pullPolicy
Uma política de extração de imagens. O valor padrão é IfNotPresent.
feature_gates
Um portão de recurso
npc.maxTaintedNode
O número máximo de nós que o NPC pode adicionar manchas quando uma única falha ocorre em vários nós para minimizar o impacto
O valor pode estar no formato int ou percentual.
npc.nodeAffinity
Afinidade do nó do controlador
- Configure as políticas de agendamento para o complemento.
- As políticas de agendamento não entram em vigor em instâncias complementares do tipo DaemonSet.
- Ao configurar a implementação de várias AZs ou a afinidade de nó, verifique se há nós que atendem à política de agendamento e se os recursos são suficientes no cluster. Caso contrário, o complemento não pode ser executado.
Tabela 3 Configurações para programação de complementos Parâmetro
Descrição
Multi-AZ Deployment
- Preferred: os pods de Implementação do complemento serão agendados preferencialmente para nós em diferentes AZs. Se todos os nós no cluster forem implementados na mesma AZ, os pods serão agendados para essa AZ.
- Forcible: os pods de Implementação do complemento serão forçosamente agendados para nós em diferentes AZs. Se houver menos AZs do que pods, os pods extras não funcionarão.
Node Affinity
- Incompatibility: a afinidade de nó está desabilitada para o complemento.
- Node Affinity: especifique os nós em que o complemento é implementado. Se você não especificar os nós, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão.
- Specified Node Pool Scheduling: especifique o pool de nós em que o complemento é implementado. Se você não especificar o pool de nós, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão.
- Custom Policies: insira os rótulos dos nós em que o complemento será implementado para políticas de agendamento mais flexíveis. Se você não especificar rótulos de nó, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão.
Se várias políticas de afinidade personalizadas estiverem configuradas, certifique-se de que existem nós que atendam a todas as políticas de afinidade no cluster. Caso contrário, o complemento não pode ser executado.
Taints and Tolerations
O uso de manchas e tolerâncias permite (não forçosamente) que Implementação do complemento seja agendada para um nó com as manchas correspondentes e controla as políticas de despejo de Implementação depois que o nó onde a Implementação está localizada é contaminado.
O complemento adiciona a política de tolerância padrão para as manchas node.kubernetes.io/not-ready e node.kubernetes.io/unreachable, respectivamente. A janela de tempo de tolerância é 60s.
Para mais detalhes, consulte Manchas e tolerâncias.
- Clique em Install.
Componentes
|
Componente |
Descrição |
Tipo de recurso |
|---|---|---|
|
node-problem-controller |
Isolar falhas basicamente com base em resultados de detecção de falhas. |
Implementação |
|
node-problem-detector |
Detectar falhas de nó. |
DaemonSet |
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 5 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 7 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 8 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:
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:
Alternativamente, você pode executar o seguinte comando:
iostat -xmt 1
- Limite padrão:
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 9 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 10 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%
Isolamento de falha do Node-problem-controller
O isolamento de falhas é suportado apenas por complementos de 1.16.0 e versões posteriores.
Por padrão, se vários nós se tornarem defeituosos, o NPC adiciona manchas a até 10% dos nós. Você pode definir npc.maxTaintedNode para aumentar o limite.
O plug-in NPD de código aberto fornece detecção de falhas, mas não isolamento de falhas. O CCE aprimora o controlador de problemas de nó (NPC) baseado no NPD de código aberto. Esse componente é implementado com base no node controller do Kubernetes. Para falhas relatadas pelo NPD, o NPC adiciona automaticamente manchas aos nós para isolamento de falhas de nó.
|
Parâmetro |
Descrição |
Padrão |
|---|---|---|
|
npc.enable |
Se ativar o NPC Este parâmetro não é suportado em versões 1.18.0 ou posteriores. |
true |
|
npc.maxTaintedNode |
O número máximo de nós que o NPC pode adicionar manchas quando uma única falha ocorre em vários nós para minimizar o impacto. O formato int e o formato percentual são suportados. |
10% Intervalo de valores:
|
|
npc.nodeAffinity |
Afinidade do nó do controlador |
N/D |
Exibir eventos do NPD
Os eventos relatados pelo complemento NPD podem ser consultados na página Nodes.
- Efetue logon no console do CCE.
- Clique no nome do cluster para acessar o console do cluster. Escolha Nodes no painel de navegação.
- Localize a linha que contém o nó de destino e clique em View Events.
Figura 1 Exibir eventos do nó
Você pode obter eventos na página exibida.
Alarmes de AOM
Para itens de verificação de NPD relacionados ao status, você pode configurar o Application Operations Management (AOM) para converter status anormais em alarmes de AOM e notificá-lo via mensagem SMS ou e-mail.
- Efetue logon no console do AOM.
- No painel de navegação, escolha Alarm Center > Alarm Rules e clique em Create Alarm Rule.
- Defina uma regra de alarme.
- Rule Type: selecione Threshold alarm.
- Monitored Object: selecione Command input.
- Digite ` sum(problem_gauge{clusterName="test"}) by (podIP,type)` na caixa de texto.
- Alarm Condition: acionar um alarme importante se o valor médio for maior ou igual a 1 por um tempo consecutivo em um período de monitoramento.
- (Opcional) Alarm notification: para ser notificado de alarmes por e-mail ou mensagem SMS, configure as regras de ação para a regra de alarme. Se nenhuma regra de ação estiver disponível, você poderá criar uma.
Coletar métricas de Prometheus
O pod do daemon de NPD expõe dados métricos do Prometheus na porta 19901. Por padrão, o pod de NPD é adicionado com a anotação metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"prometheus","path":"/metrics","port":"19901","names":""}]'. Você pode criar um coletor de Prometheus para identificar e obter métricas de NPD do http://{{NpdPodIP}}:{{NpdPodPort}}/metrics.
Se a versão do complemento NPD for anterior a 1.16.5, a porta exposta das métricas do Prometheus é 20257.
Atualmente, os dados da métrica incluem problem_counter e problem_gauge, como mostrado abaixo.
# HELP problem_counter Number of times a specific type of problem have occurred.
# TYPE problem_counter counter
problem_counter{reason="DockerHung"} 0
problem_counter{reason="DockerStart"} 0
problem_counter{reason="EmptyDirVolumeGroupStatusError"} 0
...
# HELP problem_gauge Whether a specific type of problem is affecting the node or not.
# TYPE problem_gauge gauge
problem_gauge{reason="CNIIsDown",type="CNIProblem"} 0
problem_gauge{reason="CNIIsUp",type="CNIProblem"} 0
problem_gauge{reason="CRIIsDown",type="CRIProblem"} 0
problem_gauge{reason="CRIIsUp",type="CRIProblem"} 0
..
