Débogage des noeuds worker à l'aide de l'API Kubernetes

Si vous avez accès au cluster, vous pouvez déboguer les noeuds worker en utilisant l'API Kubernetes sur la ressource Node.

Avant de commencer, assurez-vous que vous disposez du rôle d'accès au service Manager dans tous les espaces de noms ou du rôle de plate-forme Administrateur pour le cluster, qui correspond au rôle RBAC cluster-admin.

Accédez à votre cluster Red Hat OpenShift.
Répertoriez les noeuds worker de votre cluster et notez le nom (NAME) de ceux qui ne sont pas à l'état Prêt (valeur Ready dans STATUS). Notez que le nom (NAME) correspond à l'adresse IP privée du noeud worker.
```
oc get nodes
```
Décrivez chaque noeud worker et examinez la section Conditions dans la sortie.
- Type : type de condition qui peut affecter le noeud worker, par exemple, sollicitation du disque ou de la mémoire.
- LastTransitionTime : heure à laquelle le statut a été mis à jour en dernier. Utilisez cette heure pour déterminer à quel moment le problème lié à votre noeud worker a commencé, ce qui peut vous aider à le résoudre.
```
oc describe node <name>
```
Vérifiez l'utilisation des noeuds worker.
1. Dans la sortie Allocated resources de la commande précédente, examinez les charges de travail qui utilisent l'UC et les ressources de mémoire du noeud worker. Vous remarquerez peut-être que certains cabosses n'établissent pas de limites de ressources et consomment plus de ressources que prévu. Si tel est le cas, réglez l'utilisation des ressources des pods.
2. Examinez le pourcentage d'utilisation de l'UC et de la mémoire sur les noeuds worker de votre cluster. Si l'utilisation est constamment supérieure à 80 %, ajoutez des nœuds de travail à la grappe pour prendre en charge les charges de travail.
Recherchez les contrôleurs d'admission personnalisés qui sont installés dans votre cluster. Les contrôleurs d'admission bloquent souvent l'exécution des pods requis, ce qui peut occasionner le passage de vos noeuds worker à un état critique. Si vous disposez de contrôleurs d'admission personnalisés, essayez de les retirer avec la commande oc delete. Vérifiez ensuite si le problème de noeud worker est résolu.
```
kubectl get mutatingwebhookconfigurations --all-namespaces
```
```
kubectl get validatingwebhookconfigurations --all-namespaces
```
Si vous avez configuré l'acheminement des journaux, examinez les journaux liés au noeud à partir des chemins suivants :
```
/var/log/kubelet.log
/var/log/syslog
/var/log/messages
```
Vérifiez qu'un déploiement de charge de travail n'entraîne pas le problème de noeud worker.
1. Appliquez une teinte au noeud worker présentant le problème.
```
oc taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
```
2. Vérifiez que vous avez supprimé tous les contrôleurs d'admission personnalisés, comme décrit à l'étape 5.
3. Redémarrez le noeud worker.
  - Classique : Rechargez le noeud worker.
```
ibmcloud oc worker reload -c <cluster_name_or_ID> --worker <worker_ID>
```
  - VPC : Remplacez le noeud worker.
```
ibmcloud oc worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update
```
4. Attendez que le noeud worker ait redémarré. Si le noeud worker passe à un état correct, le problème est probablement lié à une charge de travail.
5. Planifiez une charge de travail à la fois sur le noeud worker pour identifier celle qui provoque le problème. Pour planifier les charges de travail, ajoutez la tolérance suivante :
```
tolerations:
- effect: NoExecute
  key: ibm-cloud-debug-isolate-customer-workload
  operator: Exists
```
6. Une fois que vous avez identifié la charge de travail à l'origine du problème, passez à la section Débogage de déploiements d'application.