Se um ou alguns nós do trabalhador forem afetados

Se apenas alguns, mas não todos, os nós do trabalhador em seu cluster estiverem em um estado Critical ou NotReady, siga estas etapas para determinar a causa da interrupção e resolver o problema Se os nós do trabalhador afetados forem todos da mesma zona, sub-rede ou VLAN, continue na próxima seção.

1. Obter os detalhes do nó específico.

   oc describe node <node-IP-address>
   

2. Na saída, verifique a seção Condições para determinar se o nó está tendo problemas de memória, disco ou PID. Essas informações podem indicar que o nó está em execução baixo nesse tipo de recurso. Essa situação pode ocorrer por um dos seguintes motivos:

   • Esgotamento de memória ou CPU causado por falta de solicitações e limites adequados em seus pods.
   • Os discos do trabalhador estão cheios, às vezes devido a grandes logs de pod ou saída de pod para o próprio nó.
   • Vazamentos de memória lentos que se acumulam ao longo do tempo, o que pode causar problemas para os trabalhadores que não foram atualizados em mais de um mês
   • Erros e travamentos que afetam o kernel do Linux

3. Se você for capaz de determinar a causa do problema a partir das informações na seção Condições, siga as etapas em Depurando nós do trabalhador para isolar a carga de trabalho do problema

4. Se as etapas anteriores não resolverem o problema, recarregue ou substitua os trabalhadores afetados um por vez.

Se todos os nós do trabalhador em uma única zona, sub-rede ou VLAN forem afetados

Se todos os nós de trabalho em uma zona, sub-rede ou VLAN estiverem em um estado Critical ou NotReady, mas todos os outros nós de trabalho no cluster estiverem funcionando normalmente, pode haver um problema com um componente de rede. Siga as etapas em Se todos os nós do trabalhador em um cluster forem afetados, especialmente as etapas referentes a quaisquer componentes de rede que possam afetar a zona, a sub-rede ou a VLAN, como regras de firewall ou gateway, ACLs ou rotas customizadas ou políticas de rede Calico e Kubernetes.

Se você tiver verificado seus componentes de rede e ainda não puder resolver o problema, reúna seus dados do nó do trabalhador e abra um chamado de suporte

Se todos os nós do trabalhador em um cluster forem afetados

Se todos os nós do trabalhador em seu cluster mostrarem Critical ou NotReady ao mesmo tempo, poderá haver um problema com o cluster apiserver ou com o caminho de rede entre os trabalhadores e o apiserver Siga estas etapas de resolução de problemas para determinar a causa e resolver o problema

Algumas etapas são específicas para uma área especializada, tais como rede ou automação. Consulte o administrador ou a equipe relevante em sua organização antes de concluir estas etapas

1. Verifique se houve alguma mudança recente em seu cluster, ambiente ou conta que possa impactar seus nós do trabalhador Se sim, reverta as mudanças e, em seguida, verifique o status do nó do trabalhador para determinar se as mudanças causaram o problema.

   • Para clusters clássicos, verifique qualquer firewall ou gateway, como Virtual Router Appliance, Vyatta ou Juniper que gerencia o tráfego para trabalhadores do cluster. Procure mudanças ou problemas que possam eliminar ou redirecionar o tráfego de trabalhadores do cluster.
   • Para clusters VPC, verifique se alguma mudança foi feita no grupo de segurança e nas ACLs padrão no VPC ou nos nós do trabalhador Se quaisquer modificações foram feitas, assegure-se de que você esteja permitindo todo o tráfego necessário dos nós do trabalhador do cluster para o cluster mestre, registro de contêiner e outros serviços críticos. Para obter mais informações, consulte Noções básicas sobre redes VPC de cluster seguras por padrão e Criação e gerenciamento de grupos de segurança VPC e Controle de tráfego com ACLs.
   • Para clusters VPC, verifique quaisquer regras de roteamento customizadas para mudanças que possam estar bloqueando o tráfego do cluster apiserver..
   • Verifique quaisquer políticas de rede Calico ou Kubernetes que são aplicadas ao cluster e certifique-se de que elas não bloqueiem o tráfego do nó do trabalhador para o cluster apiservice, registro de contêiner ou outros serviços críticos.

2. Verifique se os aplicativos, a segurança ou os componentes de monitoramento em seu cluster estão sobrecarregando o cluster apiserver com solicitações, o que pode causar interrupções para seus nós do trabalhador

3. Se você incluiu recentemente quaisquer componentes em seu cluster, remova-os. Se você fez mudanças em quaisquer componentes existentes no cluster, reverta as mudanças. Em seguida, verifique o status dos nós do trabalhador para ver se os novos componentes ou mudanças estavam causando o problema.

4. Verifique se há mudanças em quaisquer webhooks de cluster, que podem interromper as solicitações do apiserver ou bloquear a capacidade de um nó do trabalhador de se conectar com o apiserver Verifique se há webhooks que estão rejeitando solicitações. Execute o seguinte comando para obter uma lista de webhooks que estão rejeitando solicitações.

   kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
   

5. Revise a saída dos webhooks que têm o status " rejected="true".

6. Remova e gere novamente quaisquer segredos de extração customizados do Docker, que, se configurados incorretamente, podem evitar que os nós do trabalhador extrai imagens de registros do Docker..

   1. Execute os comandos oc delete secret -n openshift pull-secret e oc delete secret -n openshift-config pull-secret para excluir os segredos de extração customizados do Docker

       oc delete secret -n openshift pull-secret
       ```
       ```sh {: pre}
       oc delete secret -n openshift-config pull-secret
       ```
   1. Aguarde o cluster gerar novamente os segredos de extração customizados do Docker. Quaisquer componentes configurados incorretamente não estão mais presentes nos segredos de extração regenerados
   

7. Verifique o status dos seus nós de trabalho. Se eles estiverem em um estado Normal, inclua de volta quaisquer componentes excluídos e recrie quaisquer mudanças revertidas, uma por uma, até que seja possível determinar qual configuração ou componente causou a interrupção do nó do trabalhador

8. Se o problema ainda não for resolvido, siga as etapas para reunir os dados do nó do trabalhador e abrir um chamado de suporte

Se os nós do trabalhador alternarem entre os estados normal e crítico

Se os nós do trabalhador alternarem entre um estado Normal e Critical ou NotReady, verifique os componentes a seguir para quaisquer problemas ou mudanças recentes que possam interromper os nós do trabalhador.

1. Para clusters clássicos, verifique os firewalls ou os gateways. Se houver um limite de largura da banda ou qualquer tipo de mau funcionamento, resolva o problema Em seguida, verifique os nós do trabalhador novamente

2. Verifique se os aplicativos, a segurança ou os componentes de monitoramento em seu cluster estão sobrecarregando o cluster apiserver com solicitações, o que pode causar interrupções para seus nós do trabalhador

3. Se você incluiu recentemente quaisquer componentes em seu cluster, remova-os. Se você fez mudanças em quaisquer componentes existentes no cluster, reverta as mudanças. Em seguida, verifique o status dos nós do trabalhador para ver se os novos componentes ou mudanças estavam causando o problema.

4. Verifique se há mudanças em quaisquer webhooks de cluster, que podem interromper as solicitações do apiserver ou bloquear a capacidade de um nó do trabalhador de se conectar com o apiserver Verifique se há webhooks que estão rejeitando solicitações. Execute o seguinte comando para obter uma lista de webhooks que estão rejeitando solicitações.

   kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
   

5. Revise a saída dos webhooks que têm o status " rejected="true".

6. Se o problema ainda não for resolvido, siga as etapas para reunir os dados do nó do trabalhador e abrir um chamado de suporte

Antes de Iniciar

Verifique as condições de seus nós do trabalhador e do cluster antes de reunir dados

1. Verifique o nível de CPU e de memória de seus nós Se qualquer nó estiver acima de 80% no uso de CPU ou de memória, considere provisionar mais nós ou reduzir sua carga de trabalho

   oc top node
   

   Exemplo de saída

   NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
   10.001.1.01     640m         16%    6194Mi          47%       
   10.002.2.02     2686m        68%    4024Mi          30%       
   10.003.3.03     2088m        53%    10735Mi         81%  
   

2. Verifique se há mudanças em quaisquer webhooks de cluster, que podem interromper as solicitações do apiserver ou bloquear a capacidade de um nó do trabalhador de se conectar com o apiserver Verifique se há webhooks que estão rejeitando solicitações. Execute o seguinte comando para obter uma lista de webhooks que estão rejeitando solicitações.

   kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
   

3. Revise a saída dos webhooks que têm o status " rejected="true".

Reunindo dados

Siga as etapas para reunir os dados relevantes do nó do trabalhador

1. Obtenha os detalhes de cada nó Salve os detalhes de saída para incluir no chamado de suporte.

   oc describe node <node-ip-address>
   

2. Mostre que não há webhooks mutantes ou de validação incluídos restantes em seu cluster, obtendo os detalhes do webhook Salve a saída de comando para incluir no chamado de suporte. Observe que os seguintes webhooks mutantes podem permanecer e não precisam ser excluídos: alertmanagerconfigs.openshift, managed-storage-validation-webhooks, multus.openshift.io, performance-addon-operator, prometheusrules.openshift.io,snapshot.storage.k8s.io.

   kubectl get mutatingwebhookconfigurations
   

   kubectl get validatingwebhookconfigurations
   

3. Clusters clássicos: acesse o console KVM para um dos trabalhadores afetados. Em seguida, reúna os logs e a saída relevantes..

   1. Siga as etapas para acessar o Console do KVM
   2. Reúna e salve os logs a seguir: Revise os logs para possíveis causas da interrupção do nó do trabalhador, como uma falta de memória ou espaço em disco, o disco entrando no modo somente leitura e outros problemas.
      • /var/log/boot.log
      • /var/log/calico/cni/cni.log
      • /var/log/crio.log
      • /var/log/cron
      • /var/log/messages
      • /var/log/secure
   3. Execute os comandos a seguir e salve a saída para conectar ao chamado de suporte.
      • ps -aux # Processo de execução de dump
      • df -H # Informações de uso do disco de dump
      • vmstat # Informações de uso de memória de dump
      • lshw # Informações de hardware de dump
      • last -Fxn2 shutdown reboot # determinar se a última reinicialização foi normal ou não
      • mount | grep -i "(ro" # para descartar o problema de somente leitura do disco NOTA: tmpfs estar ro é bom
      • touch /this # para descartar problema de leitura de disco

4. Clusters de VPC: Colete o uso de recursos dos nós de trabalho usando o comando kubectl top, como no exemplo a seguir.

   kubectl top nodes
   

   O exemplo de saída mostra o uso da CPU em milicores (m) e o uso da memória em megabytes (Mi).

   NAME          CPU(cores)    CPU%   MEMORY(bytes)   MEMORY%
   k8s-node-1      250m              12%    800Mi                         40%
   k8s-node-2      180m               9%     600Mi                         30%
   k8s-node-3      250m               22%    700Mi                        50%
   

   NOME

   O nome do nó.

   CPU (núcleos)

   O uso atual da CPU em milicores (m). 1000m é igual a 1 núcleo.

   % de CPU

   A porcentagem da capacidade total da CPU usada no nó.

   Memória (bytes)

   O uso atual da memória em MiB (megabytes) ou GiB (gigabytes).

   MEMÓRIA%

   A porcentagem da capacidade total de memória usada.

   Um nó com alta porcentagem de CPU ou MEMÓRIA (acima de 80%) pode estar sobrecarregado e exigir recursos adicionais. Um nó com baixa% de CPU ou% de MEMÓRIA (abaixo de 20%) pode estar sendo subutilizado, indicando que há espaço para redistribuição da carga de trabalho. Se um nó atingir 100% de uso da CPU ou da memória, as novas cargas de trabalho poderão não ser programadas ou sofrer degradação do desempenho.

5. Colete o uso de recursos dos pods usando o seguinte comando.

   kubectl top pods --all-namespaces
   

   Exemplo de saída

   NAMESPACE       NAME                                  CPU(cores)   MEMORY(bytes)
   default            my-app-564bc58dad-hk5gn       120m            256Mi
   default             my-db-789d9c6c4f-tn7mv         300m            512Mi
   

   NOME

   O nome do pod.

   CPU (núcleos)

   A CPU total usada pelo pod em todos os seus contêineres.

   Memória (bytes)

   A memória total usada pelo pod em todos os seus contêineres.

   Se o uso da CPU de um pod for alto, ele poderá estar sofrendo limitação de CPU, o que afeta o desempenho. Se o uso de memória de um pod estiver próximo do seu limite, ele poderá estar sujeito a erros OOM (Out of Memory), nos quais os processos Kubernetes são encerrados para liberar memória. Um pod com baixo uso de recursos pode ter solicitações superalocadas, o que leva ao desperdício de recursos.

6. Verifique as métricas no nível do contêiner executando o comando top pod.

   kubectl top pod pod-a --containers -n appns
   ```sh
   {: pre}
   Example output
   ```sh
   NAME           CONTAINER      CPU(cores)   MEMORY(bytes)
   pod-a            app-container        100m         300Mi
   pod-a            db-container           50m          200Mi
   ```sh
   {: screen}
   
   

7. O comando kubectl top mostra apenas o uso real, não os recursos solicitados ou limitados. Para comparar e analisar a saída do comando top, verifique a especificação do pod usando o seguinte comando.

   kubectl describe pod <pod-name> -n <namespace>
   

   Exemplo de saída

   Containers:
    app-container:
      Requests:
     cpu: 250m
     memory: 512Mi
     Limits:
     cpu: 500m
     memory: 1Gi
   

   Se o uso da CPU ou da memória exceder as solicitações, isso pode indicar subprovisionamento, o que leva a problemas de desempenho. Se o uso estiver próximo dos limites, o contêiner poderá ser estrangulado ou encerrado quando os recursos forem limitados. Se o uso for significativamente menor do que as solicitações, o pod poderá ser provisionado em excesso, desperdiçando recursos.

8. Identifique quais pods estão consumindo mais CPU.

   kubectl top pod --all-namespaces | sort -k3 -nr | head -10
   

9. Identificar pods com alto consumo de memória.

   kubectl top pod --all-namespaces | sort -k4 -nr | head -10
   

10. Monitorar o uso de recursos do daemon do sistema. DaemonSets, como kube-proxy ou agentes de monitoramento, podem consumir recursos inesperados.

    kubectl top pod -n kube-system
    ```sh
    {: pre}
    
    

11. Se determinados pods do sistema consumirem muita CPU ou memória, talvez seja necessário ajustar as solicitações e os limites. Para rastrear as alterações de recursos continuamente, use o comando watch.

    watch -n 5 kubectl top pod --all-namespaces
    ```sh
    {: pre}
    This command updates the output every 5 seconds, helping to spot spikes or anomalies in resource usage.
    
    

12. Verifique os eventos do site OOMKilled. Quando Kubernetes relata OOMKilled, o pod excedeu seu limite de memória e foi encerrado. O status do pod muda para crashloopbackoff.

    kubectl get events --field-selector involvedObject.name=your-pod-name -n your-namespace
    

13. Procure por mensagens OOM nos registros.

    kubectl logs your-pod-name -n your-namespace | grep -i "out of memory"
    

14. Verifique o último estado do contêiner para OOM termination.

    kubectl describe pod your-pod-name -n your-namespace | grep -A 10 "Last State"
    

Coleta de logs de nós de trabalho

Siga as etapas para acessar o trabalhador e coletar os registros do nó de trabalho.

1. Reúna e salve os seguintes arquivos de registro. Revise os logs para possíveis causas da interrupção do nó do trabalhador, como uma falta de memória ou espaço em disco, o disco entrando no modo somente leitura e outros problemas.

   • /var/log/containerd.log
   • /var/log/kern.log
   • /var/log/kube-proxy.log
   • /var/log/syslog
   • /var/log/kubelet.log

2. Execute os comandos a seguir e salve a saída para conectar ao chamado de suporte.

   Obter estatísticas do contêiner (requer acesso SSH ao nó).

   crictl stats
   

   Obtenha estatísticas detalhadas de um contêiner específico.

   crictl stats --id <container-id> --output json
   

   Execute o comando para despejar os processos em execução.

   ps -aux
   

   Obtenha uma visão dinâmica e em tempo real dos processos em execução e das tarefas gerenciadas pelo kernel, bem como da utilização de recursos, incluindo o uso da CPU e da memória.

   top
   

   Obter o estado atual do sistema.

   htop
   

   Obtenha um relatório de monitoramento abrangente com dados históricos.

   atop
   

   Obtenha informações em tempo real sobre os processos do sistema.

   btop
   

   Obter detalhes da conexão de rede.

   netstat
   

   Obter informações sobre o uso do disco.

   df -H
   

   Execute vmstat para obter relatórios sobre processos, memória, paginação, E/S de bloco, traps e atividade da CPU. Esse comando obtém as informações em intervalos de 2 segundos, 5 vezes.

   vmstat 2 5
   

   Execute o site iostat para coletar estatísticas de uso de disco que abrangem taxa de transferência, utilização, comprimentos de fila, taxas de transação e muito mais.

   iostat -x 1 5
   

   Coletar informações de hardware.

   lshw
   

   Descubra se a última reinicialização foi graciosa ou não usando o comando abaixo.

   last -Fxn2 shutdown reboot
   

   Para descartar o problema do disco, verifique se o disco pode ser gravado.

   mount | grep -i "(ro"
   touch /this
   

3. Se o problema persistir, abra um tíquete de suporte e anexe todos os resultados salvos nas etapas anteriores.