Si uno o algunos nodos de trabajador se ven afectados

Si sólo algunos, pero no todos, de los nodos trabajadores del clúster están en un estado Critical o NotReady, siga estos pasos para determinar la causa de la interrupción y resolver el problema. Si los nodos trabajadores afectados son todos de la misma zona, subred o VLAN, continúe en la sección siguiente.

1. Consulta los detalles del nodo específico.

   oc describe node <node-IP-address>
   

2. En la salida, compruebe la sección Condiciones para determinar si el nodo está experimentando problemas de memoria, disco o PID. Esta información puede indicar que el nodo se está quedando sin ese tipo de recurso. Esta situación puede producirse por alguna de las siguientes razones:

   • Agotamiento de memoria o CPU causado por una falta de solicitudes y límites adecuados en los pods.
   • Los discos de trabajador están llenos, a veces debido a registros de pod grandes o a la salida de pod en el propio nodo.
   • Pérdidas de memoria lentas que se acumulan con el tiempo, lo que puede causar problemas a los trabajadores que no se han actualizado en más de un mes.
   • Errores y bloqueos que afectan al kernel de Linux.

3. Si puede determinar la causa del problema a partir de la información de la sección Condiciones, siga los pasos de Depuración de nodos trabajadores para aislar la carga de trabajo del problema.

4. Si los pasos anteriores no resuelven el problema, vuelva a cargar o sustituya los trabajadores afectados de uno en uno.

Si todos los nodos trabajadores de una sola zona, subred o VLAN se ven afectados

Si todos los nodos trabajadores de una zona, subred o VLAN se encuentran en un estado Critical o NotReady, pero todos los demás nodos trabajadores del clúster funcionan con normalidad, es posible que haya un problema con un componente de red. Siga los pasos de Si todos los nodos trabajadores de un clúster están afectados, especialmente los pasos relacionados con los componentes de red que pueden afectar a la zona, subred o VLAN, como por ejemplo reglas de cortafuegos o pasarela, ACL o rutas personalizadas, o políticas de red de Calico y Kubernetes.

Si ha seleccionado los componentes de red y todavía no puede resolver el problema, recopile los datos del nodo trabajador y abra una incidencia de soporte.

Si todos los nodos trabajadores de un clúster se ven afectados

Si todos los nodos trabajadores del clúster muestran Critical o NotReady al mismo tiempo, es posible que haya un problema con el clúster apiserver o la vía de acceso de red entre los nodos trabajadores y el apiserver. Siga estos pasos de resolución de problemas para determinar la causa y resolver el problema.

Algunos pasos son específicos de un área especializada, como la red o la automatización. Consulte con el administrador o equipo correspondiente de su organización antes de completar estos pasos.

1. Compruebe si se han producido cambios recientes en el clúster, entorno o cuenta que puedan afectar a los nodos trabajadores. Si es así, revierta los cambios y, a continuación, compruebe el estado del nodo trabajador para determinar si los cambios han causado el problema.

   • Para los clústeres clásicos, compruebe cualquier cortafuegos o pasarela, como por ejemplo Virtual Router Appliance, Vyatta o Juniper que gestiona el tráfico para los trabajadores del clúster. Busque cambios o problemas que puedan descartar o redireccionar el tráfico de los trabajadores del clúster.
   • Para los clústeres de VPC, compruebe si se han realizado cambios en el grupo de seguridad predeterminado y las ACL en la VPC o en los nodos trabajadores. Si se han realizado modificaciones, asegúrese de que está permitiendo todo el tráfico necesario desde los nodos trabajadores del clúster al maestro del clúster, al registro de contenedor y a otros servicios críticos. Para obtener más información, consulte Comprensión de las redes VPC de clúster seguras por defecto y Creación y gestión de grupos de seguridad VPC y Control del tráfico con ACL.
   • Para los clústeres de VPC, compruebe si hay cambios en las reglas de direccionamiento personalizadas que puedan estar bloqueando el tráfico del clúster apiserver.
   • Compruebe las políticas de red de Calico o Kubernetes que se aplican al clúster y asegúrese de que no bloquean el tráfico desde el nodo trabajador al clúster apiservice, el registro de contenedor u otros servicios críticos.

2. Compruebe si las aplicaciones, la seguridad o los componentes de supervisión del clúster están sobrecargando el clúster apiserver con solicitudes, lo que puede provocar interrupciones para los nodos trabajadores.

3. Si ha añadido recientemente algún componente al clúster, elimínelo. Si ha realizado cambios en algún componente existente del clúster, revierta los cambios. A continuación, compruebe el estado de los nodos trabajadores para ver si los nuevos componentes o cambios estaban causando el problema.

4. Compruebe si hay cambios en los webhooks del clúster, lo que puede interrumpir las solicitudes de apiserver o bloquear la capacidad de un nodo trabajador para conectarse con el apiserver. Comprueba si hay webhooks que rechazan peticiones. Ejecute el siguiente comando para obtener una lista de webhooks que están rechazando peticiones.

   kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
   

5. Revise la salida para los webhooks que tienen el estado ' rejected="true".

6. Elimine y vuelva a generar los secretos de extracción de Docker personalizados, que, si están mal configurados, pueden impedir que los nodos trabajadores extraigan imágenes de los registros de Docker.

   1. Ejecute los mandatos oc delete secret -n openshift pull-secret y oc delete secret -n openshift-config pull-secret para suprimir los secretos de extracción de Docker personalizados.

       oc delete secret -n openshift pull-secret
       ```
       ```sh {: pre}
       oc delete secret -n openshift-config pull-secret
       ```
   1. Espere a que el clúster vuelva a generar los secretos de extracción de Docker personalizados. Los componentes mal configurados ya no están presentes en los secretos de extracción regenerados.
   

7. Comprueba el estado de tus nodos de trabajo. Si están en un estado Normal, añada de nuevo los componentes suprimidos y vuelva a crear los cambios revertidos, uno por uno, hasta que pueda determinar qué configuración o componente ha causado la interrupción del nodo trabajador.

8. Si el problema sigue sin resolverse, siga los pasos para recopilar los datos del nodo trabajador y abrir una incidencia de soporte.

Si los nodos trabajadores conmutan entre los estados normal y crítico

Si los nodos trabajadores conmutan entre un estado Normal y Critical o NotReady, compruebe los siguientes componentes para ver si hay problemas o cambios recientes que puedan interrumpir los nodos trabajadores.

1. Para clústeres clásicos, compruebe los cortafuegos o las pasarelas. Si hay un límite de ancho de banda o cualquier tipo de mal funcionamiento, resuelva el problema. A continuación, vuelva a comprobar los nodos trabajadores.

2. Compruebe si las aplicaciones, la seguridad o los componentes de supervisión del clúster están sobrecargando el clúster apiserver con solicitudes, lo que puede provocar interrupciones para los nodos trabajadores.

3. Si ha añadido recientemente algún componente al clúster, elimínelo. Si ha realizado cambios en algún componente existente del clúster, revierta los cambios. A continuación, compruebe el estado de los nodos trabajadores para ver si los nuevos componentes o cambios estaban causando el problema.

4. Compruebe si hay cambios en los webhooks del clúster, lo que puede interrumpir las solicitudes de apiserver o bloquear la capacidad de un nodo trabajador para conectarse con el apiserver. Comprueba si hay webhooks que rechazan peticiones. Ejecute el siguiente comando para obtener una lista de webhooks que están rechazando peticiones.

   kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
   

5. Revise la salida para los webhooks que tienen el estado ' rejected="true".

6. Si el problema sigue sin resolverse, siga los pasos para recopilar los datos del nodo trabajador y abrir una incidencia de soporte.

Antes de empezar

Compruebe las condiciones de los nodos trabajadores y el clúster antes de recopilar datos.

1. Compruebe el nivel de CPU y memoria de los nodos. Si algún nodo está por encima del 80% en uso de CPU o de memoria, considere la posibilidad de suministrar más nodos o reducir la carga de trabajo.

   oc top node
   

   Salida de ejemplo

   NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
   10.001.1.01     640m         16%    6194Mi          47%       
   10.002.2.02     2686m        68%    4024Mi          30%       
   10.003.3.03     2088m        53%    10735Mi         81%  
   

2. Compruebe si hay cambios en los webhooks del clúster, lo que puede interrumpir las solicitudes de apiserver o bloquear la capacidad de un nodo trabajador para conectarse con el apiserver. Comprueba si hay webhooks que rechazan peticiones. Ejecute el siguiente comando para obtener una lista de webhooks que están rechazando peticiones.

   kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
   

3. Revise la salida para los webhooks que tienen el estado ' rejected="true".

Recopilando datos

Siga los pasos para recopilar los datos de nodo trabajador relevantes.

1. Obtenga los detalles de cada nodo. Guarde los detalles de salida para incluirlos en la incidencia de soporte.

   oc describe node <node-ip-address>
   

2. Mostrar que no hay ningún webhooks añadido que mute o valide que permanezcan en el clúster obteniendo los detalles del webhook. Guarde la salida del mandato para incluirla en la incidencia de soporte. Tenga en cuenta que los siguientes webhooks mutantes pueden permanecer y no es necesario suprimirlos: alertmanagerconfigs.openshift, managed-storage-validation-webhooks, multus.openshift.io, performance-addon-operator, prometheusrules.openshift.io,snapshot.storage.k8s.io.

   kubectl get mutatingwebhookconfigurations
   

   kubectl get validatingwebhookconfigurations
   

3. Clústeres clásicos: acceda a la consola de KVM para uno de los trabajadores afectados. A continuación, recopile los registros y la salida relevantes.

   1. Siga los pasos para acceder a la consola de KVM.
   2. Recopile y guarde los registros siguientes. Revise los registros para ver las posibles causas de la interrupción del nodo trabajador, como la falta de memoria o espacio de disco, el disco que entra en modalidad de sólo lectura y otros problemas.
      • /var/log/boot.log
      • /var/log/calico/cni/cni.log
      • /var/log/crio.log
      • /var/log/cron
      • /var/log/messages
      • /var/log/secure
   3. Ejecute los mandatos siguientes y guarde la salida para adjuntarla a la incidencia de soporte.
      • ps -aux # Volcar proceso en ejecución
      • df -H # Volcar información de uso de disco
      • vmstat # Volcar información de uso de memoria
      • lshw # Volcar información de hardware
      • last -Fxn2 shutdown reboot # determinar si el último reinicio ha sido graceful o no
      • mount | grep -i "(ro" # para descartar un problema de sólo lectura de disco. NOTA: tmpfs estar ro está bien
      • touch /this # para descartar un problema de sólo lectura de disco

4. Clusters VPC: Recopila el uso de recursos de los nodos trabajadores utilizando el comando kubectl top como en el siguiente ejemplo.

   kubectl top nodes
   

   La salida de ejemplo muestra el uso de CPU en milicores (m) y el uso de memoria en megabytes (Mi).

   NAME          CPU(cores)    CPU%   MEMORY(bytes)   MEMORY%
   k8s-node-1      250m              12%    800Mi                         40%
   k8s-node-2      180m               9%     600Mi                         30%
   k8s-node-3      250m               22%    700Mi                        50%
   

   NOMBRE

   Nombre del nodo.

   CPU (núcleos)

   El uso actual de la CPU en milicores (m). 1000m equivale a 1 núcleo.

   CPU

   Porcentaje de la capacidad total de la CPU utilizada en el nodo.

   Memoria (bytes)

   El uso actual de memoria en MiB (megabytes) o GiB (gigabytes).

   MEMORIA

   Porcentaje de la capacidad total de memoria utilizada.

   Un nodo con un alto % de CPU o % de MEMORIA (por encima del 80%) podría estar sobrecargado y requerir recursos adicionales. Un nodo con un CPU% o MEMORY% bajo (por debajo del 20%) podría estar infrautilizado, lo que indica que hay margen para redistribuir la carga de trabajo. Si un nodo alcanza el 100% de uso de CPU o memoria, las nuevas cargas de trabajo podrían no programarse o experimentar una degradación del rendimiento.

5. Recopile el uso de recursos de los pods mediante el siguiente comando.

   kubectl top pods --all-namespaces
   

   Salida de ejemplo

   NAMESPACE       NAME                                  CPU(cores)   MEMORY(bytes)
   default            my-app-564bc58dad-hk5gn       120m            256Mi
   default             my-db-789d9c6c4f-tn7mv         300m            512Mi
   

   NOMBRE

   Nombre del pod.

   CPU (núcleos)

   La CPU total utilizada por el pod en todos sus contenedores.

   Memoria (bytes)

   La memoria total utilizada por el pod en todos sus contenedores.

   Si el uso de la CPU de un pod es elevado, es posible que esté experimentando un estrangulamiento de la CPU, lo que afecta al rendimiento. Si el uso de memoria de un pod se acerca a su límite, podría correr el riesgo de sufrir errores OOM (Out of Memory), en los que Kubernetes termina los procesos para liberar memoria. Un pod con bajo uso de recursos podría tener peticiones sobreasignadas, lo que llevaría a un desperdicio de recursos.

6. Compruebe las métricas a nivel de contenedor ejecutando el comando top pod.

   kubectl top pod pod-a --containers -n appns
   ```sh
   {: pre}
   Example output
   ```sh
   NAME           CONTAINER      CPU(cores)   MEMORY(bytes)
   pod-a            app-container        100m         300Mi
   pod-a            db-container           50m          200Mi
   ```sh
   {: screen}
   
   

7. El comando kubectl top sólo muestra el uso real, no los recursos solicitados o limitados. Para comparar y analizar la salida del comando top, compruebe la especificación del pod mediante el siguiente comando.

   kubectl describe pod <pod-name> -n <namespace>
   

   Salida de ejemplo

   Containers:
    app-container:
      Requests:
     cpu: 250m
     memory: 512Mi
     Limits:
     cpu: 500m
     memory: 1Gi
   

   Si el uso de la CPU o de la memoria supera las peticiones, podría indicar un aprovisionamiento insuficiente, lo que provocaría problemas de rendimiento. Si el uso está cerca de los límites, el contenedor puede ser estrangulado o terminado cuando los recursos son limitados. Si el uso es significativamente inferior a las solicitudes, es posible que el pod esté sobreaprovisionado, desperdiciando recursos.

8. Identifique los pods que consumen más CPU.

   kubectl top pod --all-namespaces | sort -k3 -nr | head -10
   

9. Identificar los pods que consumen mucha memoria.

   kubectl top pod --all-namespaces | sort -k4 -nr | head -10
   

10. Monitoriza el uso de recursos del demonio del sistema. DaemonSets, como kube-proxy o agentes de supervisión, pueden consumir recursos inesperados.

    kubectl top pod -n kube-system
    ```sh
    {: pre}
    
    

11. Si determinados pods del sistema consumen demasiada CPU o memoria, puede ser necesario ajustar las solicitudes y los límites. Para realizar un seguimiento continuo de los cambios en los recursos, utilice el comando watch.

    watch -n 5 kubectl top pod --all-namespaces
    ```sh
    {: pre}
    This command updates the output every 5 seconds, helping to spot spikes or anomalies in resource usage.
    
    

12. Consulte los eventos en OOMKilled. Cuando Kubernetes informa a OOMKilled, el pod excedió su límite de memoria y fue terminado. El estado del pod cambia a crashloopbackoff.

    kubectl get events --field-selector involvedObject.name=your-pod-name -n your-namespace
    

13. Busque mensajes OOM en los registros.

    kubectl logs your-pod-name -n your-namespace | grep -i "out of memory"
    

14. Compruebe el último estado del contenedor para OOM terminación.

    kubectl describe pod your-pod-name -n your-namespace | grep -A 10 "Last State"
    

Recopilación de registros de nodos trabajadores

Siga los pasos para acceder al trabajador y recopilar los registros del nodo trabajador.

1. Reúna y guarde los siguientes archivos de registro. Revise los registros para ver las posibles causas de la interrupción del nodo trabajador, como la falta de memoria o espacio de disco, el disco que entra en modalidad de sólo lectura y otros problemas.

   • /var/log/containerd.log
   • /var/log/kern.log
   • /var/log/kube-proxy.log
   • /var/log/syslog
   • /var/log/kubelet.log

2. Ejecute los mandatos siguientes y guarde la salida para adjuntarla a la incidencia de soporte.

   Obtener estadísticas del contenedor (requiere acceso SSH al nodo).

   crictl stats
   

   Obtenga estadísticas detalladas de un contenedor específico.

   crictl stats --id <container-id> --output json
   

   Ejecute el comando para volcar los procesos en ejecución.

   ps -aux
   

   Obtenga una vista dinámica y en tiempo real de los procesos en ejecución y de las tareas gestionadas por el kernel, así como de la utilización de los recursos, incluido el uso de la CPU y la memoria.

   top
   

   Obtener el estado actual del sistema.

   htop
   

   Obtenga un informe de seguimiento completo con datos históricos.

   atop
   

   Obtenga información en tiempo real sobre los procesos del sistema.

   btop
   

   Obtener detalles de la conexión de red.

   netstat
   

   Obtener información sobre el uso del disco.

   df -H
   

   Ejecute vmstat para obtener informes sobre procesos, memoria, paginación, IO en bloque, traps y actividad de la CPU. Este comando obtiene la información a intervalos de 2 segundos, 5 veces.

   vmstat 2 5
   

   Ejecute iostat para recopilar estadísticas de uso del disco que cubran el rendimiento, la utilización, la longitud de las colas, las tasas de transacción, etc.

   iostat -x 1 5
   

   Recopila información sobre el hardware.

   lshw
   

   Averigua si el último reinicio fue graceful o no utilizando el comando que aparece a continuación.

   last -Fxn2 shutdown reboot
   

   Para descartar el problema del disco, verifique que el disco es grabable.

   mount | grep -i "(ro"
   touch /this
   

3. Si los problemas persisten, abra un ticket de soporte y adjunte todos los resultados guardados en los pasos anteriores.