Debugging der Workerknoten mit Kubernetes-API

Wenn Sie Zugriff auf den Cluster haben, können Sie die Workerknoten mithilfe der Kubernetes-API auf der Ressource Node (Knoten) debuggen.

Bevor Sie beginnen, vergewissern Sie sich, dass Sie in allen Namespaces über die Dienstzugriffsrolle Manager oder die Plattformrolle Administrator für den Cluster verfügen, die der RBAC-Rolle cluster-admin entspricht.

Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
Listen Sie die Arbeiterknoten in Ihrem Cluster auf und notieren Sie die NAMEN der Arbeiterknoten, die sich nicht in einem Ready STATUS befinden. Beachten Sie, dass NAME die private IP-Adresse des Workerknotens ist.
```
kubectl get nodes
```
Beschreiben Sie den einzelnen Workerknoten und überprüfen Sie den Abschnitt Conditions (Bedingungen) in der Ausgabe.
- Type: Der Typ von Bedingung, der sich auf den Workerknoten auswirken kann, z. B. Arbeitsspeicher- oder Plattenverfügbarkeit.
- LastTransitionTime: Der letzte Zeitpunkt, zu dem der Status aktualisiert wurde. Anhand dieser Zeitangabe können Sie ermitteln, wann das Problem mit Ihrem Workerknoten begann, was Ihnen wiederum dabei helfen kann, das Problem zu beheben.
```
kubectl describe node <name>
```
Prüfen Sie die Nutzung der Workerknoten.
1. Überprüfen Sie in der Ausgabe Allocated resources (Zugeordnete Ressourcen) des vorherigen Befehls die Workloads, die die CPU- und Speicherressourcen des Workerknotens verwenden. Möglicherweise stellen Sie fest, dass einige Pods keine Ressourcengrenzwerte festlegen und mehr Ressourcen verbrauchen als erwartet. Wenn dies der Fall ist, passen Sie die Ressourcennutzung der Pods an.
2. Überprüfen Sie den Prozentsatz der Nutzung von CPU und Speicher für alle Workerknoten in Ihrem Cluster. Wenn die Auslastung konstant über 80 % liegt, fügen Sie dem Cluster weitere Arbeitsknoten hinzu, um die Arbeitslasten zu unterstützen.
Prüfen Sie, ob angepasste Admission Controller in Ihrem Cluster installiert sind. Admission Controller blockieren oftmals die Ausführung von erforderlichen Pods, was dazu führen kann, dass Ihre Workerknoten in einen kritischen Zustand eintreten. Wenn Sie über angepasste Admission Controller verfügen, versuchen Sie, diese mit kubectl delete zu löschen. Prüfen Sie dann, ob das Problem mit dem Workerknoten behoben wurde.
```
kubectl get mutatingwebhookconfigurations --all-namespaces
```
```
kubectl get validatingwebhookconfigurations --all-namespaces
```
Wenn Sie die Protokollweiterleitung konfiguriert haben, überprüfen Sie die knotenbezogenen Protokolle in den folgenden Pfaden.
```
/var/log/containerd.log
/var/log/kube-proxy.log
/var/log/kubelet.log
/var/log/syslog
```
Prüfen Sie, dass nicht eine Workloadbereitstellung das Problem mit dem Workerknoten verursacht.
1. Versehen Sie den Workerknoten mit dem Problem mit Taints.
```
kubectl taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
```
2. Stellen Sie sicher, dass Sie alle angepassten Admission Controller gelöscht haben, wie in Schritt 5 beschrieben.
3. Starten Sie den Workerknoten erneut.
  - Klassisch: Workerknoten erneut laden.
```
ibmcloud ks worker reload -c <cluster_name_or_ID> --worker <worker_ID>
```
  - VPC: Workerknoten ersetzen.
```
ibmcloud ks worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update
```
4. Warten Sie, bis der Workerknoten vollständig erneut gestartet wurde. Wenn der Workerknoten einen einwandfreien Zustand aufweist, wird das Problem wahrscheinlich von einer Workload verursacht.
5. Planen Sie eine Workload nach der anderen für den Workerknoten, um zu sehen, welche Workload das Problem verursacht. Zum Planen der Workloads fügen Sie die folgende Tolerierung hinzu.
```
tolerations:
- effect: NoExecute
  key: ibm-cloud-debug-isolate-customer-workload
  operator: Exists
```
6. Nachdem Sie die Workload identifiziert haben, die das Problem verursacht, fahren Sie mit dem Abschnitt App-Bereitstellungen debuggen fort.