Depurando nós do trabalhador com API do Kubernetes

Se você tiver acesso ao cluster, será possível depurar os nós do trabalhador usando a API do Kubernetes no recurso Node.

Antes de começar, certifique-se de que você tenha a função de acesso ao serviço Manager em todos os namespaces ou a função de plataforma Administrator para o cluster, que corresponde à função cluster-admin RBAC.

Acesse o seu Red Hat OpenShift cluster.
Liste os nós de trabalho em seu cluster e anote o NOME dos nós de trabalho que não estão em um Ready STATUS. Observe que o NOME é o endereço IP privado do nó do trabalhador.
```
oc get nodes
```
Descreva cada nó do trabalhador e revise a seção Conditions na saída.
- Type: o tipo de condição que pode afetar o nó do trabalhador, como pressão de memória ou de disco.
- LastTransitionTime: o horário mais recente em que o status foi atualizado. Use esse horário para identificar quando começou o problema com o seu nó do trabalhador, o que pode ajudar a resolver melhor o problema.
```
oc describe node <name>
```
Verifique o uso dos nós do trabalhador.
1. Na saída Allocated resources do comando anterior, revise as cargas de trabalho que usam os recursos de CPU e de memória do nó do trabalhador. Você pode notar que alguns pods não configuram limites de recursos e estão consumindo mais recursos do que o esperado. Nesse caso, ajuste o uso de recursos dos pods.
2. Revise a porcentagem de uso de CPU e de memória nos nós do trabalhador em seu cluster. Se o uso for consistentemente superior a 80%, adicione mais nós de trabalho ao cluster para dar suporte às cargas de trabalho.
Verifique os controladores de admissão customizados que estão instalados em seu cluster. Os controladores de admissão muitas vezes bloqueiam a execução dos pods necessários, o que pode fazer seus nós do trabalhador entrarem em estado crítico. Se você tiver controladores de admissão customizados, tente removê-los com oc delete. Em seguida, verifique se o problema do nó do trabalhador foi resolvido.
```
kubectl get mutatingwebhookconfigurations --all-namespaces
```
```
kubectl get validatingwebhookconfigurations --all-namespaces
```
Se você configurou o encaminhamento de log, revise os logs relacionados ao nó por meio dos caminhos a seguir.
```
/var/log/kubelet.log
/var/log/syslog
/var/log/messages
```
Verifique se uma implementação de carga de trabalho não causa o problema do nó do trabalhador.
1. Contamine o nó do trabalhador com o problema.
```
oc taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
```
2. Certifique-se de que tenha excluído quaisquer controladores de admissão customizados conforme descrito na etapa 5.
3. Reinicie o nó do trabalhador.
  - Clássico: recarregue o nó do trabalhador.
```
ibmcloud oc worker reload -c <cluster_name_or_ID> --worker <worker_ID>
```
  - VPC: substitua o nó do trabalhador.
```
ibmcloud oc worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update
```
4. Espere a conclusão da reinicialização do nó do trabalhador. Se o nó do trabalhador entrar em um estado funcional, provavelmente o problema será causado por uma carga de trabalho.
5. Agende uma carga de trabalho em um horário no nó do trabalhador para ver qual carga de trabalho causa o problema. Para agendar as cargas de trabalho, inclua a seguinte tolerância.
```
tolerations:
- effect: NoExecute
  key: ibm-cloud-debug-isolate-customer-workload
  operator: Exists
```
6. Depois de identificar a carga de trabalho que causa o problema, continue com Depurando implementações do app.