Depuración de nodos trabajadores con la API de Kubernetes

Si tiene acceso al clúster, puede depurar los nodos trabajadores utilizando la API de Kubernetes en el recurso Node.

Antes de empezar, asegúrese de que tiene el rol de acceso al servicio de Gestor en todos los espacios de nombres para el clúster, que corresponde al rol de RBAC cluster-admin.

Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.
Obtenga una lista de los nodos trabajadores del clúster y anote el nombre (NAME) de los nodos trabajadores que no están en estado (ReadySTATUS**) preparado (**). Tenga en cuenta que el nombre (NAME) es la dirección IP privada del nodo trabajador.
```
kubectl get nodes
```
Describa cada uno de los nodos trabajadores y revise la sección Conditions en la salida.
- Type: el tipo de condición que puede afectar al nodo trabajador, como la memoria o la presión de disco.
- LastTransitionTime: la hora más reciente en la que se ha actualizado el estado. Utilice este tiempo para identificar cuando se ha iniciado el problema con su nodo trabajador, lo que le puede ayudar a solucionar el problema.
```
kubectl describe node <name>
```
Compruebe el uso de nodos trabajadores.
1. En la salida Allocated resources del mandato anterior, revise las cargas de trabajo que utilizan los recursos de memoria y CPU del nodo trabajador. Puede que observe que algunos pods no establecen límites de recursos y consumen más recursos de los previstos. Si es así, ajuste el uso de recursos de los pods.
2. Revise el porcentaje del uso de la CPU y la memoria en los nodos trabajadores del clúster. Si el uso supera constantemente el 80%, añada más nodos trabajadores al clúster para dar soporte a las cargas de trabajo.
Compruebe si hay controladores de admisión personalizados instalados en el clúster. Los controladores de admisión suelen bloquear la ejecución de pods necesarios, lo que podría hacer que los nodos trabajadores entren en un estado crítico. Si tiene controladores de admisión personalizados, intente eliminarlos con kubectl delete. A continuación, compruebe si el problema del nodo trabajador se resuelve.
```
kubectl get mutatingwebhookconfigurations --all-namespaces
```
```
kubectl get validatingwebhookconfigurations --all-namespaces
```
Si ha configurado el reenvío de registro, revise los registros relacionados con nodos de las siguientes vías de acceso.
```
/var/log/containerd.log
/var/log/kubelet.log
/var/log/kube-proxy.log
/var/log/syslog
```
Compruebe que el despliegue de carga de trabajo no cause el problema del nodo trabajador.
1. Marque como sospechoso el nodo trabajador que tiene el problema.
```
kubectl taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
```
2. Asegúrese de haber suprimido los controladores de admisión personalizados tal como se describe en el paso 5.
3. Reinicie el nodo trabajador.
  - Clásico: vuelva a cargar el nodo trabajador.
```
ibmcloud ks worker reload -c <cluster_name_or_ID> --worker <worker_ID>
```
  - VPC: sustituya el nodo trabajador.
```
ibmcloud ks worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update
```
4. Espere a que el nodo trabajador termine de reiniciarse. Si el nodo trabajador entra en un buen estado, es probable que el problema esté causado por una carga de trabajo.
5. Planifique una carga de trabajo a la vez en el nodo trabajador para ver qué carga de trabajo causa el problema. Para planificar las cargas de trabajo, añada la tolerancia siguiente.
```
tolerations:
- effect: NoExecute
  key: ibm-cloud-debug-isolate-customer-workload
  operator: Exists
```
6. Después de identificar la carga de trabajo que provoca el problema, continúe con Depuración de despliegues de app.