Debug dei nodi di lavoro con l'API Kubernetes

Se hai accesso al cluster, puoi eseguire il debug dei nodi di lavoro utilizzando l'API Kubernetes sulla risorsa Node.

Prima di iniziare, assicurarsi di avere il ruolo di accesso al servizio Manager in tutti i namespace o il ruolo di piattaforma Administrator per il cluster, che corrisponde al ruolo cluster-admin RBAC.

Accedi al tuo cluster Red Hat OpenShift.
Elenca i nodi di lavoro nel tuo cluster e prendi nota del NOME dei nodi di lavoro che non sono in uno Ready STATO. Nota che il NOME è l'indirizzo IP privato del nodo di lavoro.
```
oc get nodes
```
Descrivi ogni nodo di lavoro e controlla la sezione Conditions nell'output.
- Type: il tipo di condizione che potrebbe influenzare il nodo di lavoro, come la memoria o la pressione del disco.
- LastTransitionTime: l'ora più recente in cui è stato aggiornato lo stato. Utilizza questo tempo per identificare quando è iniziato il problema con il tuo nodo di lavoro, che può aiutarti a risolvere ulteriormente il problema.
```
oc describe node <name>
```
Controllare l'utilizzo dei nodi worker.
1. Nell'output Allocated resources del comando precedente, esamina i carichi di lavoro che utilizzano le risorse di memoria e CPU del nodo di lavoro. Potresti notare che alcuni pod non impostano i limiti per le risorse e stanno consumando più risorse del previsto. In tal caso, regola l'utilizzo delle risorse dei pod.
2. Esamina la percentuale di utilizzo di memoria e CPU tra i nodi di lavoro nel tuo cluster. Se l'utilizzo è costantemente superiore all ' 80%, aggiungi ulteriori nodi di lavoro al cluster per supportare i carichi di lavoro.
Controllare i controller di ammissione personalizzati installati nel cluster. I controller di ammissione spesso bloccano l'esecuzione dei pod richiesti, il che potrebbe rendere i tuoi nodi di lavoro in uno stato critico. Se si dispone di controller di ammissione personalizzati, provare a rimuoverli con oc delete. Quindi, controlla se il problema del nodo di lavoro si risolve.
```
kubectl get mutatingwebhookconfigurations --all-namespaces
```
```
kubectl get validatingwebhookconfigurations --all-namespaces
```
Se hai configurato l'inoltro dei log, esamina i log relativi al nodo dai seguenti percorsi.
```
/var/log/kubelet.log
/var/log/syslog
/var/log/messages
```
Verificare che una distribuzione del workload non causi il problema del nodo di lavoro.
1. Contaminare il nodo di lavoro con il problema.
```
oc taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
```
2. Assicurati di aver eliminato tutti i controller di ammissione personalizzati come descritto al punto 5.
3. Riavvia il nodo di lavoro.
  - Classico: Ricarica il nodo worker.
```
ibmcloud oc worker reload -c <cluster_name_or_ID> --worker <worker_ID>
```
  - VPC: Sostituire il nodo worker.
```
ibmcloud oc worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update
```
4. Attendere che il nodo di lavoro termini il riavvio. Se il nodo di lavoro entra in uno stato integro, il problema è probabilmente causato da un carico di lavoro.
5. Pianifica un carico di lavoro alla volta sul nodo di lavoro per vedere quale carico di lavoro causa il problema. Per pianificare i carichi di lavoro, aggiungi la seguente tolleranza.
```
tolerations:
- effect: NoExecute
  key: ibm-cloud-debug-isolate-customer-workload
  operator: Exists
```
6. Dopo aver identificato il carico di lavoro che causa il problema, continua con Debug delle distribuzioni dell'applicazione.