Soluciona problemas de nodos con el estado NotReady en GKE

El estado NotReady en Google Kubernetes Engine (GKE) significa que el kubelet del nodo no informa al plano de control correctamente. Como Kubernetes no programará nuevos Pods en un nodo NotReady, este problema puede reducir la capacidad de la aplicación y provocar tiempo de inactividad.

Usa este documento para distinguir entre los estados NotReady esperados y los problemas reales, diagnosticar la causa raíz y encontrar soluciones para problemas comunes, como el agotamiento de recursos, los problemas de red y las fallas del tiempo de ejecución del contenedor.

Esta información está dirigida a los administradores y operadores de la plataforma responsables de la estabilidad del clúster, y a los desarrolladores de aplicaciones que deseen comprender el comportamiento de las aplicaciones relacionado con la infraestructura. Para obtener más información sobre los roles comunes y las tareas de ejemplo a los que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Antes de comenzar

  • Para obtener los permisos que necesitas para realizar las tareas de este documento, pídele a tu administrador que te otorgue los siguientes roles de IAM en tu proyecto Google Cloud :

    Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

    También puedes obtener los permisos necesarios a través de roles personalizados o cualquier otro rol predefinido.

  • Configura la herramienta de línea de comandos de kubectl para que se comunique con tu clúster de GKE:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION \
    --project PROJECT_ID

    Reemplaza lo siguiente:

    • CLUSTER_NAME: El nombre de tu clúster.
    • LOCATION: Es la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.
    • PROJECT_ID: El ID de tu proyecto Google Cloud .

Verifica el estado y las condiciones del nodo

Para confirmar que un nodo tiene el estado NotReady y ayudarte a diagnosticar la causa raíz, sigue estos pasos para inspeccionar las condiciones, los eventos, los registros y las métricas de recursos de un nodo:

  1. Consulta el estado de tus nodos. Para obtener detalles adicionales, como direcciones IP y versiones del kernel, que son útiles para el diagnóstico, usa la marca -o wide:

    kubectl get nodes -o wide

    El resultado es similar a lo siguiente:

    NAME                                STATUS     ROLES    AGE   VERSION               INTERNAL-IP  EXTERNAL-IP  OS-IMAGE                             KERNEL-VERSION   CONTAINER-RUNTIME
gke-cluster-pool-1-node-abc1        Ready      <none>   94d   v1.32.3-gke.1785003   10.128.0.1   1.2.3.4      Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
gke-cluster-pool-1-node-def2        Ready      <none>   94d   v1.32.3-gke.1785003   10.128.0.2   5.6.7.8      Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
gke-cluster-pool-1-node-ghi3        NotReady   <none>   94d   v1.32.3-gke.1785003   10.128.0.3   9.10.11.12   Container-Optimized OS from Google   6.6.72+          containerd://1.7.24

    En el resultado, busca los nodos con un valor de NotReady en la columna STATUS y anota sus nombres.

  2. Para ver más información sobre nodos específicos con el estado NotReady, incluidas sus condiciones y los eventos recientes de Kubernetes, haz lo siguiente:

    kubectl describe node NODE_NAME

    Reemplaza NODE_NAME por el nombre de un nodo con el estado NotReady.

    En el resultado, enfócate en la sección Conditions para comprender el estado del nodo y en la sección Events para ver un historial de los problemas recientes. Por ejemplo:

    Name:                   gke-cluster-pool-1-node-ghi3
...
Conditions:
Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                   Message
----                          ------    -----------------                 ------------------                ------                   -------
NetworkUnavailable            False     Wed, 01 Oct 2025 10:29:19 +0100   Wed, 01 Oct 2025 10:29:19 +0100   RouteCreated             RouteController created a route
MemoryPressure                Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
DiskPressure                  Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
PIDPressure                   False     Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:29:00 +0100   KubeletHasSufficientPID  kubelet has sufficient PID available
Ready                         Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
Events:
Type     Reason                   Age                  From                                   Message
----     ------                   ----                 ----                                   -------
Normal   Starting                 32m                  kubelet, gke-cluster-pool-1-node-ghi3  Starting kubelet.
Warning  PLEGIsNotHealthy         5m1s (x15 over 29m)  kubelet, gke-cluster-pool-1-node-ghi3  PLEG is not healthy: pleg was last seen active 5m1.123456789s ago; threshold is 3m0s
Normal   NodeHasSufficientMemory  5m1s (x16 over 31m)  kubelet, gke-cluster-pool-1-node-ghi3  Node gke-cluster-pool-1-node-ghi3 status is now: NodeHasSufficientMemory

    En la sección Conditions, el estado True para cualquier condición negativa o Unknown para la condición Ready indica un problema. Presta mucha atención a los campos Reason y Message de estas condiciones, ya que explican la causa del problema.

    A continuación, se explica el significado de cada tipo de condición:

    • KernelDeadlock: True si el kernel del sistema operativo del nodo detectó un bloqueo, que es un error grave que puede congelar el nodo.
    • FrequentUnregisterNetDevice: True si el nodo anula el registro de sus dispositivos de red con frecuencia, lo que puede ser un signo de problemas de hardware o controladores.
    • NetworkUnavailable: True si la red del nodo no está configurada correctamente.
    • OutOfDisk: True si el espacio disponible en el disco está completamente agotado. Esta condición es más grave que DiskPressure.
    • MemoryPressure: True si la memoria del nodo es baja
    • DiskPressure: True si el espacio en disco del nodo es bajo
    • PIDPressure: True si el nodo experimenta agotamiento del ID de proceso (PID).
    • Ready: Indica si el nodo está en buen estado y listo para aceptar Pods.
      • True si el nodo está en buen estado
      • False si el nodo no está en buen estado y no acepta Pods
      • Unknown si el controlador del nodo no ha recibido información del nodo durante un período de gracia (el valor predeterminado es de 50 segundos) y el estado del nodo es desconocido.

    A continuación, examina la sección Events, que proporciona un registro cronológico de las acciones y observaciones sobre el nodo. Esta línea de tiempo es fundamental para comprender qué sucedió inmediatamente antes de que el nodo se volviera NotReady. Busca mensajes específicos que puedan ayudarte a encontrar la causa, como advertencias de desalojo (que indican presión de recursos), verificaciones de estado fallidas o eventos de ciclo de vida de nodos, como el acordonamiento para una reparación.

  3. Para obtener más información sobre por qué los nodos tienen el estado NotReady, consulta los registros del nodo y sus componentes.

    1. Verifica los registros de kubelet para conocer el estado de NotReady.

      El kubelet es el agente principal que informa el estado del nodo al plano de control, por lo que es más probable que sus registros contengan el mensaje literal NotReady. Estos registros son la fuente autorizada para diagnosticar problemas relacionados con los eventos del ciclo de vida de los Pods, las condiciones de presión de recursos (como MemoryPressure o DiskPressure) y la conectividad del nodo con el plano de control de Kubernetes.

    2. En la consola de Google Cloud , ve a la página Explorador de registros.

      Ir al Explorador de registros

    3. En el panel de consultas, ingresa la siguiente consulta:

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("kubelet")
textPayload=~"(?i)NotReady"

      Reemplaza lo siguiente:

      • NODE_NAME: Es el nombre del nodo que investigas.
      • CLUSTER_NAME: El nombre de tu clúster.
      • LOCATION: Es la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) para el clúster.

    4. Haz clic en Ejecutar consulta y revisa los resultados.

    5. Si los registros de kubelet no revelan la causa raíz, verifica los registros de container-runtime y node-problem-detector. Es posible que estos componentes no registren el estado NotReady directamente, pero a menudo registran el problema subyacente (como una falla de tiempo de ejecución o un error de kernel) que lo causó.

    6. En el panel de consultas del Explorador de registros, ingresa la siguiente consulta:

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("COMPONENT_NAME")

      Reemplaza COMPONENT_NAME por uno de los siguientes valores:

      • container-runtime: Es el entorno de ejecución (containerd) responsable del ciclo de vida completo del contenedor, incluida la extracción de imágenes y la administración de la ejecución del contenedor. Revisar los registros de container-runtime es fundamental para solucionar problemas relacionados con la creación de instancias de contenedores, errores del servicio de tiempo de ejecución o problemas causados por la configuración del tiempo de ejecución.
      • node-problem-detector: Es una utilidad que supervisa de forma proactiva y registra una variedad de problemas a nivel del nodo en el plano de control. Sus registros son fundamentales para identificar problemas sistémicos subyacentes que pueden causar inestabilidad en los nodos, como bloqueos del kernel, daños en el sistema de archivos o fallas de hardware, que otros componentes de Kubernetes podrían no capturar.

    7. Haz clic en Ejecutar consulta y revisa los resultados.

  4. Usa el Explorador de métricas para buscar el agotamiento de recursos en el momento en que el nodo se convirtió en NotReady:

    1. En la consola de Google Cloud , ve a la página Explorador de métricas:

      Ir al Explorador de métricas

    2. En el Explorador de métricas, verifica si la instancia subyacente de Compute Engine del nodo tiene agotamiento de recursos. Enfócate en las métricas relacionadas con la CPU, la memoria y las operaciones de E/S de disco. Por ejemplo:

      • Métricas de nodos de GKE: Comienza con las métricas que tienen el prefijo kubernetes.io/node/, como kubernetes.io/node/cpu/allocatable_utilization o kubernetes.io/node/memory/allocatable_utilization. Estas métricas muestran qué cantidad de los recursos disponibles del nodo usan tus Pods. La cantidad disponible no incluye los recursos que Kubernetes reserva para la sobrecarga del sistema.
      • Métricas del SO invitado: Para obtener una vista desde el interior del sistema operativo del nodo, usa métricas con el prefijo compute.googleapis.com/guest/, como compute.googleapis.com/guest/cpu/usage o compute.googleapis.com/guest/memory/bytes_used.
      • Métricas del hipervisor: Para ver el rendimiento de la VM desde el nivel del hipervisor, usa métricas con el prefijo compute.googleapis.com/instance/, como compute.googleapis.com/instance/cpu/utilization o métricas de E/S de disco, como compute.googleapis.com/instance/disk/read_bytes_count.

      Las métricas del hipervisor y del SO invitado requieren que filtres por el nombre de la instancia subyacente de Compute Engine, no por el nombre del nodo de Kubernetes. Para encontrar el nombre de la instancia de un nodo, ejecuta el comando kubectl describe node NODE_NAME y busca el campo ProviderID en el resultado. El nombre de la instancia es la última parte de ese valor. Por ejemplo:

      ...
Spec:
ProviderID: gce://my-gcp-project-123/us-central1-a/gke-my-cluster-default-pool-1234abcd-5678
...

      En este ejemplo, el nombre de la instancia es gke-my-cluster-default-pool-1234abcd-5678.

Identifica la causa por síntoma

Si identificaste un síntoma específico, como un mensaje de registro, una condición del nodo o un evento del clúster, usa la siguiente tabla para encontrar sugerencias de solución de problemas:

Categoría Síntoma o mensaje de registro Posible causa: Pasos para solucionar problemas
Condiciones de nodo NetworkUnavailable: True Problema de conectividad del nodo al plano de control o falla del complemento de la interfaz de red de contenedor (CNI). Soluciona los problemas de la conectividad de red
MemoryPressure: True El nodo no tiene suficiente memoria. Soluciona problemas de escasez de recursos de nodos
DiskPressure: True El nodo no tiene suficiente espacio en el disco. Soluciona problemas de escasez de recursos de nodos
PIDPressure: True El nodo no tiene suficientes IDs de proceso disponibles. Soluciona problemas de escasez de recursos de nodos
Eventos y mensajes de registro PLEG is not healthy Kubelet está sobrecargado debido a un uso elevado de la CPU o de E/S, o a una cantidad excesiva de Pods. Cómo resolver problemas de PLEG
Out of memory: Kill process
sys oom event		 Se agotó por completo la memoria del nodo. Cómo resolver eventos de OOM a nivel del sistema
leases.coordination.k8s.io...is forbidden El espacio de nombres kube-node-lease está atascado en el proceso de finalización. Cómo resolver problemas con el espacio de nombres kube-node-lease
Container runtime not ready
runtime is down
Errores que hacen referencia a /run/containerd/containerd.sock o docker.sock		 El servicio de Containerd o Docker falló o está mal configurado. Cómo resolver problemas del entorno de ejecución del contenedor
Los Pods están atascados en Terminating
Los registros de Kubelet muestran DeadlineExceeded para el contenedor de eliminación
Los registros de containerd muestran mensajes Kill container repetidos		 Procesos atascados en suspensión de disco ininterrumpible (estado D), a menudo relacionados con E/S. Cómo resolver procesos atascados en el estado D
Síntomas a nivel del clúster Varios nodos fallan después de un lanzamiento de DaemonSet. El DaemonSet interfiere en las operaciones del nodo. Cómo resolver problemas causados por objetos DaemonSets de terceros
compute.instances.preempted en los registros de auditoría. Se interrumpió la VM Spot, que es el comportamiento esperado. Confirmar la preferencia del nodo
kube-system Pods atascados en Pending. El webhook de admisión bloquea componentes críticos. Cómo resolver problemas causados por webhooks de admisión
exceeded quota: gcp-critical-pods La cuota configurada de forma incorrecta está bloqueando los Pods del sistema. Cómo resolver problemas causados por las cuotas de recursos

Verifica si se generaron los eventos NotReady esperados

El estado NotReady no siempre indica un problema. Puede ser un comportamiento esperado durante operaciones planificadas, como una actualización del grupo de nodos, o si usas ciertos tipos de máquinas virtuales.

Confirma las operaciones del ciclo de vida del nodo

Síntomas:

Un nodo muestra temporalmente un estado NotReady durante ciertos eventos del ciclo de vida.

Causa:

El estado de un nodo se convierte temporalmente en NotReady durante varios eventos comunes del ciclo de vida. Este comportamiento se espera cada vez que se crea o se vuelve a crear un nodo, como en las siguientes situaciones:

  • Actualizaciones de grupos de nodos: Durante una actualización, se agota y reemplaza cada nodo. El nodo nuevo y actualizado tiene el estado NotReady hasta que finaliza la inicialización y se une al clúster.
  • Reparación automática de nodos: Cuando GKE reemplaza un nodo que no funciona correctamente, el nodo de reemplazo permanece en estado NotReady mientras se aprovisiona.
  • Aumento de escala del escalador automático del clúster: Cuando se agregan nodos nuevos, comienzan en estado NotReady y se vuelven Ready solo después de que se aprovisionan por completo y se unen al clúster.
  • Cambios manuales en la plantilla de instancias: GKE vuelve a crear los nodos cuando aplicas cambios en la plantilla. El nodo nuevo tiene un estado NotReady durante su fase de inicio.

Solución:

Los nodos solo deben tener el estado NotReady brevemente. Si el estado persiste por más de 10 minutos, investiga otras causas.

Confirma la preferencia del nodo

Si tu nodo se ejecuta en una VM Spot o una VM interrumpible, Compute Engine podría finalizarlo de forma abrupta para recuperar recursos. Este es el comportamiento esperado para estos tipos de máquinas virtuales de corta duración y no es un error.

Síntomas:

Si observas los siguientes síntomas, es probable que el estado NotReady del nodo se deba a una interrupción esperada de la VM Spot:

  • Un nodo entra de forma inesperada en el estado NotReady antes de que el escalador automático del clúster lo borre y lo vuelva a crear.
  • Los Registros de auditoría de Cloud muestran un evento compute.instances.preempted para la instancia de VM subyacente.

Causa:

El nodo se ejecutaba en una instancia de VM interrumpible o VM Spot, y Compute Engine reclamó esos recursos de procesamiento para otra tarea. Las VMs Spot se pueden interrumpir en cualquier momento, aunque suelen proporcionar un aviso de finalización de 30 segundos.

Solución:

Usa VM Spot o VM interrumpibles solo para cargas de trabajo tolerantes a errores, sin estado o por lotes que estén diseñadas para controlar las finalizaciones frecuentes de forma correcta. Para las cargas de trabajo de producción o con estado que no pueden tolerar interrupciones repentinas, aprovisiona tus grupos de nodos con VMs estándar a pedido.

Soluciona problemas de escasez de recursos de nodos

A menudo, un nodo se vuelve NotReady porque carece de recursos esenciales, como CPU, memoria o espacio en disco. Cuando un nodo no tiene suficientes recursos, los componentes críticos no pueden funcionar correctamente, lo que genera inestabilidad en la aplicación y falta de respuesta del nodo. En las siguientes secciones, se explican las diferentes formas en que pueden aparecer estas deficiencias, desde condiciones generales de presión hasta eventos más graves en todo el sistema.

Cómo resolver la presión de recursos del nodo

El agotamiento de recursos ocurre cuando un nodo no tiene suficiente CPU, memoria, espacio en disco o IDs de proceso (PID) para ejecutar sus cargas de trabajo. Este problema puede generar el estado NotReady.

Síntomas:

Si observas las siguientes condiciones y registros del nodo, es probable que el agotamiento de recursos sea la causa del estado NotReady del nodo:

  • En el resultado del comando kubectl describe node, verás el estado True para condiciones como OutOfDisk, MemoryPressure, DiskPressure o PIDPressure.
  • Es posible que los registros de kubelet contengan eventos de memoria insuficiente (OOM), lo que indica que se invocó el OOM Killer del sistema.

Causa:

Las cargas de trabajo en el nodo exigen, en conjunto, más recursos de los que el nodo puede proporcionar.

Solución:

Para los clústeres de Standard, prueba las siguientes soluciones:

En el caso de los clústeres de Autopilot, no controlas directamente los tipos de máquinas de los nodos ni los tamaños de los discos de arranque. La capacidad de los nodos se administra automáticamente según tus solicitudes de Pods. Asegúrate de que las solicitudes de recursos de tu carga de trabajo estén dentro de los límites de Autopilot y reflejen con precisión las necesidades de tu aplicación. Los problemas persistentes de recursos pueden indicar la necesidad de optimizar las solicitudes de Pod o, en casos excepcionales, un problema de la plataforma que requiere la asistencia de Atención al cliente de Cloud.

Cómo resolver eventos de OOM a nivel del sistema

Un evento de memoria insuficiente (OOM) a nivel del sistema ocurre cuando se agota la memoria total de un nodo, lo que obliga al kernel de Linux a finalizar procesos para liberar recursos. Este evento es diferente de un evento de OOM a nivel del contenedor, en el que un solo Pod supera sus límites de memoria.

Síntomas:

Si observas los siguientes síntomas, es probable que un evento de OOM a nivel del sistema sea la causa de la inestabilidad del nodo:

  • Observarás el mensaje Out of memory: Kill process en los registros de la consola serie del nodo.
  • Los registros de kubelet contienen eventos oom_watcher, que indican que kubelet detectó un evento de OOM a nivel del sistema.
  • Finalización inesperada de varios procesos, incluidos los daemons del sistema o los Pods de carga de trabajo potencialmente críticos, no necesariamente los mayores consumidores de memoria

Causa:

Se agotó la memoria general del nodo. Este problema puede deberse a un error en un servicio del sistema, a una carga de trabajo mal configurada que consume una cantidad excesiva de memoria o a un nodo demasiado pequeño para las demandas de memoria colectivas de todos sus Pods en ejecución.

Solución:

Para resolver los eventos de OOM a nivel del sistema, diagnostica la causa y, luego, reduce la demanda de memoria o aumenta la capacidad del nodo. Para obtener más información, consulta Soluciona problemas de eventos de OOM.

Cómo resolver problemas de PLEG

El generador de eventos de ciclo de vida del Pod (PLEG) es un componente dentro de kubelet. Verifica periódicamente el estado de todos los contenedores del nodo y comunica los cambios al kubelet.

Cuando el PLEG experimenta problemas de rendimiento, no puede proporcionar actualizaciones oportunas al kubelet, lo que puede provocar que el nodo se vuelva inestable.

Síntomas:

Si observas los siguientes síntomas, es posible que el PLEG no funcione correctamente:

  • Los registros de kubelet del nodo contienen un mensaje similar a PLEG is not healthy.
  • El estado del nodo cambia con frecuencia entre Ready y NotReady.

Causa:

Por lo general, los problemas del PLEG se deben a problemas de rendimiento que impiden que kubelet reciba actualizaciones oportunas del entorno de ejecución del contenedor. Entre las causas comunes, se incluyen las siguientes:

  • Carga de CPU alta: La CPU del nodo está saturada, lo que impide que kubelet y el tiempo de ejecución del contenedor tengan la potencia de procesamiento que necesitan.
  • Regulación de E/S: El disco de arranque del nodo experimenta operaciones de E/S pesadas, lo que puede ralentizar todas las tareas relacionadas con el disco.
  • Pods excesivos: Demasiados Pods en un solo nodo pueden sobrecargar el kubelet y el entorno de ejecución del contenedor, lo que genera contención de recursos.

Solución:

En el caso de los clústeres estándar, reduce la carga en los recursos del nodo:

En el caso de los clústeres de Autopilot, si bien no puedes cambiar directamente el tamaño o el tipo de disco de un nodo existente, puedes influir en el hardware en el que se ejecutan tus cargas de trabajo usando ComputeClasses personalizadas. Esta función te permite especificar requisitos en el manifiesto de tu carga de trabajo, como una cantidad mínima de CPU y memoria o una serie de máquinas específica, para guiar la programación de tus Pods.

Si no usas ComputeClasses, ajusta las implementaciones de cargas de trabajo (como los recuentos de réplicas y las solicitudes o los límites de recursos) y asegúrate de que cumplan con las restricciones de Autopilot. Si los problemas de PLEG persisten después de optimizar tus cargas de trabajo, comunícate con Atención al cliente de Cloud.

Cómo resolver procesos atascados en el estado D

Los procesos atascados en un modo de suspensión de disco no interrumpible (estado D) pueden hacer que un nodo no responda. Este problema impide que los Pods finalicen y puede provocar que fallen componentes críticos, como containerd, lo que genera un estado NotReady.

Síntomas:

  • Los Pods, en especial los que usan almacenamiento de red como NFS, se atascan en el estado Terminating durante mucho tiempo.
  • Los registros de Kubelet muestran errores de DeadlineExceeded cuando se intenta detener un contenedor.
  • Es posible que los registros de la consola serie del nodo muestren mensajes del kernel sobre hung tasks o tareas bloqueadas durante más de 120 segundos.

Causa:

Los procesos ingresan en un estado D cuando esperan que se complete una operación de E/S y no se pueden interrumpir. Entre las causas comunes, se incluyen las siguientes:

  • Sistemas de archivos remotos lentos o que no responden, como un recurso compartido NFS mal configurado o sobrecargado
  • Se produjo una degradación grave del rendimiento del disco o errores de E/S de hardware en los discos locales del nodo.

Solución:

Para resolver problemas con los procesos en estado D, identifica la fuente de E/S y, luego, borra el estado seleccionando una de las siguientes opciones:

Clústeres estándar

  1. Busca el proceso atascado y determina qué está esperando:

    1. Conéctate al nodo afectado con SSH:

      gcloud compute ssh NODE_NAME \
    --zone ZONE \
    --project PROJECT_ID

      Reemplaza lo siguiente:

      • NODE_NAME: Es el nombre del nodo al que se conectará.
      • ZONE: Es la zona de Compute Engine del nodo.
      • PROJECT_ID: el ID de tu proyecto

    2. Para encontrar cualquier proceso en estado D, haz lo siguiente:

      ps -eo state,pid,comm,wchan | grep '^D'

      El resultado es similar a lo siguiente:

      D  12345  my-app      nfs_wait
D  54321  data-writer io_schedule

      El resultado no tendrá un encabezado. Las columnas, en orden, representan lo siguiente:

      • Estado
      • ID de proceso (PID)
      • Comando
      • Canal de espera (wchan)

    3. Examina la columna wchan para identificar la fuente de E/S:

      • Si la columna wchan incluye términos como nfs o rpc, el proceso está esperando un recurso compartido de NFS.
      • Si la columna wchan incluye términos como io_schedule, jbd2 o ext4, el proceso está esperando el disco de arranque local del nodo.

    4. Para obtener más detalles sobre las funciones del kernel en las que espera el proceso, consulta la pila de llamadas del kernel del proceso:

      cat /proc/PID/stack

      Reemplaza PID por el ID del proceso que encontraste en el paso anterior.

  2. Reinicia el nodo. A menudo, reiniciar el dispositivo es la forma más eficaz de detener un proceso atascado en el estado D.

    1. Desvía el nodo.
    2. Borra la instancia de VM subyacente. Por lo general, GKE crea una VM nueva para reemplazarla.

  3. Después de solucionar el problema inmediato, investiga el sistema de almacenamiento subyacente para evitar que se repita.

    • Para problemas de almacenamiento en red (NFS): Usa las herramientas de supervisión de tu proveedor de almacenamiento para verificar si hay latencia alta, errores del servidor o problemas de red entre el nodo de GKE y el servidor NFS.

    • Para problemas con el disco local: Verifica si hay limitación de E/S en Cloud Monitoring. Para ello, consulta las métricas compute.googleapis.com/instance/disk/throttled_read_ops_count y compute.googleapis.com/instance/disk/throttled_write_ops_count de la instancia de Compute Engine.

Clústeres de Autopilot

  1. Intenta identificar la fuente del bloqueo:

    El acceso SSH directo a los nodos y la ejecución de comandos como ps o cat /proc no están disponibles en los clústeres de Autopilot. Debes basarte en los registros y las métricas.

    1. Verifica los registros del nodo: En Cloud Logging, analiza los registros del nodo afectado. Filtra por el nombre del nodo y el período del problema. Busca mensajes del kernel que indiquen errores de E/S, tiempos de espera de almacenamiento (por ejemplo, en el disco o NFS) o mensajes de los controladores de CSI.
    2. Verifica los registros de la carga de trabajo: Examina los registros de los Pods que se ejecutan en el nodo afectado. Los registros de la aplicación pueden revelar errores relacionados con las operaciones de archivos, las llamadas a la base de datos o el acceso al almacenamiento de red.
    3. Usa Cloud Monitoring: Si bien no puedes obtener detalles a nivel del proceso, verifica si hay problemas de E/S a nivel del nodo.

  2. Activa el reemplazo de un nodo para borrar el estado.

    No puedes borrar manualmente la VM subyacente. Para activar un reemplazo, agota el nodo. Esta acción aísla el nodo y expulsa los Pods.

    GKE detecta automáticamente los nodos en mal estado y comienza las reparaciones, por lo general, reemplazando la VM subyacente.

    Si el nodo permanece bloqueado después de la extracción y no se reemplaza automáticamente, comunícate con Atención al cliente de Cloud.

  3. Después de solucionar el problema inmediato, investiga el sistema de almacenamiento subyacente para evitar que se repita.

    • Para problemas con el disco local: Verifica la limitación de E/S en Cloud Monitoring. Para ello, consulta las métricas compute.googleapis.com/instance/disk/throttled_read_ops_count y compute.googleapis.com/instance/disk/throttled_write_ops_count. Puedes filtrar estas métricas para el grupo de instancias subyacente del grupo de nodos, aunque Google administra las instancias individuales.
    • Para problemas de almacenamiento en red (NFS): Usa las herramientas de supervisión de tu proveedor de almacenamiento para verificar si hay latencia alta, errores del servidor o problemas de red entre el nodo de GKE y el servidor NFS. Verifica los registros de los Pods de cualquier controlador de CSI en Cloud Logging.

Soluciona problemas de fallas en los componentes principales

Después de descartar las causas esperadas y la falta de recursos, es posible que el software del nodo o un mecanismo principal de Kubernetes sean la causa del problema. El estado NotReady puede ocurrir cuando falla un componente crítico, como el entorno de ejecución del contenedor. También puede ocurrir cuando se descompone un mecanismo principal de verificación de estado de Kubernetes, como el sistema de concesión de nodos.

Cómo resolver problemas del entorno de ejecución del contenedor

Los problemas con el entorno de ejecución del contenedor, como containerd, pueden impedir que kubelet inicie Pods en un nodo.

Síntomas:

Si observas los siguientes mensajes en los registros de kubelet, es probable que el problema del tiempo de ejecución del contenedor sea la causa del estado NotReady del nodo:

  • Container runtime not ready
  • Container runtime docker failed!
  • docker daemon exited
  • Errores al conectarse al socket del entorno de ejecución (por ejemplo, unix:///var/run/docker.sock o unix:///run/containerd/containerd.sock)

Causa:

El entorno de ejecución del contenedor no funciona correctamente, está mal configurado o se encuentra en un bucle de reinicio.

Solución:

Para resolver problemas del tiempo de ejecución del contenedor, haz lo siguiente:

  1. Analiza los registros del entorno de ejecución del contenedor:

    1. En la consola de Google Cloud , accede a la página Explorador de registros.

      Ir al Explorador de registros

    2. Para ver todos los registros de advertencias y errores del tiempo de ejecución del contenedor en el nodo afectado, ingresa lo siguiente en el panel de consultas:

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("container-runtime")
severity>=WARNING

      Reemplaza lo siguiente:

      • NODE_NAME: Es el nombre del nodo que investigas.
      • CLUSTER_NAME: El nombre de tu clúster.
      • LOCATION: Es la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) para el clúster.

    3. Haz clic en Ejecutar consulta y revisa el resultado para ver mensajes de error específicos que indiquen por qué falló el tiempo de ejecución. Un mensaje como failed to load TOML en los registros de containerd en Cloud Logging suele indicar que el archivo está mal formado.

    4. Para verificar si el entorno de ejecución está atascado en un bucle de reinicio, ejecuta una búsqueda de mensajes de inicio. Una gran cantidad de estos mensajes en un período breve confirma que se producen reinicios frecuentes.

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("container-runtime")
("starting containerd" OR "Containerd cri plugin version" OR "serving..."
OR "loading plugin" OR "containerd successfully booted")

      Los reinicios frecuentes suelen indicar un problema subyacente, como un archivo de configuración dañado o presión de recursos, que provoca que el servicio falle de forma reiterada.

  2. Revisa la configuración de containerd para detectar modificaciones: Los parámetros de configuración incorrectos pueden provocar fallas en el tiempo de ejecución del contenedor. Puedes realizar cambios en la configuración a través de un archivo de configuración del sistema de nodos o mediante modificaciones directas que realizan las cargas de trabajo con privilegios elevados.

    1. Determina si el grupo de nodos usa un archivo de configuración del sistema de nodos:

      gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION \
    --format="yaml(config.containerdConfig)"

      Reemplaza lo siguiente:

      • NODE_POOL_NAME: es el nombre de tu grupo de nodos.
      • CLUSTER_NAME: El nombre de tu clúster.
      • LOCATION: La región o zona de Compute Engine del clúster.

      Si el resultado muestra una sección containerdConfig, GKE administra estos parámetros de configuración personalizados. Para modificar o revertir la configuración, sigue las instrucciones en Personaliza la configuración de containerd en nodos de GKE.

    2. Si las personalizaciones administradas por GKE no están activas o si sospechas que hay otros cambios, busca cargas de trabajo que puedan estar modificando el sistema de archivos del nodo directamente. Busca DaemonSets con permisos elevados (securityContext.privileged: true) o volúmenes hostPath que monten directorios sensibles, como /etc.

      Para inspeccionar su configuración, enumera todos los DaemonSets en formato YAML:

      kubectl get daemonsets --all-namespaces -o yaml

      Revisa el resultado y examina los registros de cualquier DaemonSet sospechoso.

    3. En el caso de los clústeres de Standard, inspecciona el archivo de configuración directamente. No es posible acceder a SSH ni inspeccionar archivos de forma manual en los clústeres de Autopilot, ya que Google administra la configuración del tiempo de ejecución. Informa los problemas persistentes de tiempo de ejecución al servicio de Atención al cliente de Google Cloud.

      Si usas un clúster estándar, inspecciona el archivo:

      1. Conéctate al nodo con SSH:

        gcloud compute ssh NODE_NAME \
    --zone ZONE \
    --project PROJECT_ID

        Reemplaza lo siguiente:

        • NODE_NAME: Es el nombre del nodo al que se conectará.
        • ZONE: Es la zona de Compute Engine del nodo.
        • PROJECT_ID: el ID de tu proyecto

      2. Muestra el contenido del archivo de configuración de containerd:

        sudo cat /etc/containerd/config.toml

      3. Para verificar las modificaciones recientes, enumera los detalles del archivo:

        ls -l /etc/containerd/config.toml

    4. Compara el contenido de este archivo con el resultado de containerdConfig del comando gcloud node-pools describe que ejecutaste en el paso anterior. Cualquier parámetro de configuración en /etc/containerd/config.toml que no esté en el resultado de gcloud es un cambio no administrado.

    5. Para corregir cualquier error de configuración, quita los cambios que no se aplicaron a través de una configuración del sistema de nodos.

  3. Soluciona problemas comunes del entorno de ejecución: Si quieres conocer más pasos para solucionar problemas, consulta Soluciona problemas del entorno de ejecución del contenedor.

Cómo resolver problemas con el espacio de nombres kube-node-lease

Los recursos en el espacio de nombres kube-node-lease son responsables de mantener el estado de los nodos. No se debe borrar este espacio de nombres. Si intentas borrar este espacio de nombres, este quedará atascado en el estado Terminating. Cuando el espacio de nombres kube-node-lease se atasca en el estado Terminating, los kubelets no pueden renovar sus concesiones de verificación de estado. Este problema hace que el plano de control considere que los nodos no están en buen estado, lo que genera un problema en todo el clúster en el que los nodos alternan entre los estados Ready y NotReady.

Síntomas:

Si observas los siguientes síntomas, es probable que un problema con el espacio de nombres kube-node-lease sea la causa de la inestabilidad en todo el clúster:

  • Los registros de kubelet en cada nodo muestran errores persistentes similares a los siguientes:

    leases.coordination.k8s.io NODE_NAME is forbidden: unable to create new content in namespace kube-node-lease because it is being terminated

  • Los nodos del clúster alternan repetidamente entre los estados Ready y NotReady.

Causa:

El espacio de nombres kube-node-lease, que administra los latidos de nodos, está atascado de forma anormal en el estado Terminating. Este error impide que el servidor de la API de Kubernetes permita la creación o modificación de objetos dentro del espacio de nombres. Como resultado, los kubelets no pueden renovar sus objetos Lease, que son esenciales para indicar su actividad al plano de control. Sin estas actualizaciones de estado, el plano de control no puede confirmar que los nodos estén en buen estado, lo que hace que los estados de los nodos alternen entre Ready y NotReady.

Estos son algunos de los motivos subyacentes por los que el espacio de nombres kube-node-lease podría quedar atascado en el estado Terminating:

  • Recursos con finalizadores: Si bien son menos comunes para el espacio de nombres kube-node-lease del sistema (que contiene principalmente objetos Lease), un recurso dentro de él podría tener un finalizador. Los finalizadores de Kubernetes son claves que indican que un controlador debe realizar tareas de limpieza antes de que se pueda borrar un recurso. Si el controlador responsable de quitar el finalizador no funciona correctamente, el recurso no se borra y se detiene el proceso de borrado del espacio de nombres.
  • Servicios de API agregados no disponibles o que no responden: Se puede bloquear la finalización del espacio de nombres si un objeto APIService, que se usa para registrar un servidor de API agregado, está vinculado al espacio de nombres y deja de estar disponible. Es posible que el plano de control espere a que el servidor de API agregado se cierre o limpie correctamente, lo que no ocurrirá si el servicio no responde.
  • Problemas del plano de control o del controlador: En casos excepcionales, los errores o problemas dentro del plano de control de Kubernetes, específicamente el controlador de espacio de nombres, podrían impedir la recolección de elementos no utilizados y el borrado correctos del espacio de nombres.

Solución:

Sigue las indicaciones en Soluciona problemas relacionados con el espacio de nombres atrapado en el estado de finalización.

Soluciona problemas de conectividad de red

Los problemas de red pueden impedir que un nodo se comunique con el plano de control o que funcionen componentes críticos, como el complemento de CNI, lo que genera un estado NotReady.

Síntomas:

Si observas los siguientes síntomas, es posible que los problemas de red sean la causa del estado NotReady de tus nodos:

  • La condición NetworkNotReady es True.
  • Los registros de Kubelet en el nodo muestran errores similares a los siguientes:
    • connection timeout to the control plane IP address
    • network plugin not ready
    • CNI plugin not initialized
    • Mensajes connection refused o timeout cuando se intenta acceder a la dirección IP del plano de control
  • Los Pods, en especial en el espacio de nombres kube-system, están atascados en ContainerCreating con eventos como NetworkPluginNotReady.

Causa:

Por lo general, los síntomas relacionados con la red indican una falla en una de las siguientes áreas:

  • Problemas de conectividad: El nodo no puede establecer una conexión de red estable con el plano de control de Kubernetes.
  • Falla del complemento de CNI: El complemento de CNI, que es responsable de configurar la red de Pods, no se ejecuta correctamente o no se pudo inicializar.
  • Problemas con webhooks: Los webhooks de admisión mal configurados pueden interferir en los recursos relacionados con el complemento de CNI, lo que impide que la red se configure correctamente.

Solución:

Para resolver problemas de red, haz lo siguiente:

  1. Aborda el estado transitorio NetworkNotReady: En los nodos recién creados, es normal ver un breve evento NetworkNotReady. Este estado debería resolverse en uno o dos minutos mientras se inicializan el complemento de CNI y otros componentes. Si el estado persiste, continúa con los siguientes pasos.

  2. Verifica la conectividad entre el nodo y el plano de control, y las reglas de firewall: Asegúrate de que la ruta de red entre tu nodo y el plano de control esté abierta y funcione correctamente:

    1. Verifica las reglas de firewall: Asegúrate de que las reglas de firewall de tu VPC permitan el tráfico necesario entre tus nodos de GKE y el plano de control. Para obtener información sobre las reglas que GKE requiere para la comunicación del nodo con el plano de control, consulta Reglas de firewall creadas automáticamente.
    2. Probar la conectividad: Usa la prueba de conectividad en Network Intelligence Center para verificar la ruta de red entre la dirección IP interna del nodo y la dirección IP del extremo del plano de control en el puerto 443. Un resultado de Not Reachable a menudo te ayuda a identificar la regla de firewall o el problema de enrutamiento que bloquea la comunicación.

  3. Investiga el estado y los registros del complemento de CNI: Si la red del nodo no está lista, es posible que el problema se deba al complemento de CNI.

    1. Verifica el estado del Pod de CNI: Identifica el complemento de CNI en uso (por ejemplo, netd o calico-node) y verifica el estado de sus Pods en el espacio de nombres kube-system. Puedes filtrar el nodo específico con el siguiente comando:

      kubectl get pods \
    -n kube-system \
    -o wide \
    --field-selector spec.nodeName=NODE_NAME \
    | grep -E "netd|calico|anetd"

    2. Examina los registros de los Pods de CNI: Si los Pods no funcionan correctamente, examina sus registros en Cloud Logging para ver mensajes de error detallados. Usa una consulta similar a la siguiente para los Pods de netd en un nodo específico:

      resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
resource.labels.namespace_name="kube-system"
labels."k8s-pod/app"="netd"
resource.labels.node_name="NODE_NAME"
severity>=WARNING

    3. Errores específicos de CNI relacionados con la dirección:

      • Si los registros muestran Failed to allocate IP address, es posible que se hayan agotado los rangos de direcciones IP de tu Pod. Verifica el uso de las direcciones IP de los Pods y revisa los rangos de CIDR del clúster.
      • Si los registros muestran NetworkPluginNotReady o cni plugin not initialized, confirma que el nodo tenga suficientes recursos de CPU y memoria. También puedes intentar reiniciar el Pod de CNI borrándolo, lo que permite que el DaemonSet lo vuelva a crear.
      • Si usas GKE Dataplane V2 y los registros muestran Cilium API client timeout exceeded, reinicia el Pod anetd en el nodo.

    4. Verifica si hay interferencia en el webhook de admisión: Los webhooks que no funcionan correctamente pueden impedir que se inicien los Pods de CNI, lo que deja el nodo en estado NetworkNotReady.

    5. Verifica los registros del servidor de la API: Revisa los registros del servidor de la API en Cloud Logging para detectar errores relacionados con las llamadas de webhook. Para identificar si un webhook está bloqueando la creación de recursos de CNI, busca mensajes como failed calling webhook.

      Si un webhook causa problemas, es posible que debas identificar el ValidatingWebhookConfiguration o el MutatingWebhookConfiguration problemático y, luego, inhabilitarlo temporalmente para que el nodo esté listo. Para obtener más información, consulta Cómo resolver problemas causados por webhooks de admisión.

Soluciona problemas de configuración incorrecta del clúster

En las siguientes secciones, se te ayudará a auditar algunos parámetros de configuración de todo el clúster que podrían interferir en las operaciones normales de los nodos.

Cómo resolver problemas causados por webhooks de admisión

Un webhook de admisión mal configurado, no disponible o demasiado lento puede bloquear solicitudes críticas de la API, lo que impide que se inicien componentes esenciales o que los nodos se unan al clúster.

Síntomas:

Si observas los siguientes síntomas, es probable que un webhook de admisión mal configurado o no disponible esté bloqueando operaciones esenciales del clúster:

  • Los Pods, especialmente en el espacio de nombres kube-system (como los Pods de CNI o de almacenamiento), están atascados en un estado Pending o Terminating.
  • Los nodos nuevos no pueden unirse al clúster y, a menudo, se agota el tiempo de espera con un estado NotReady.

Causa:

Es posible que los webhooks de admisión que no responden o que están mal configurados bloqueen operaciones esenciales del clúster.

Solución:

Revisa la configuración de tus webhooks para asegurarte de que sean resilientes y tengan el alcance adecuado. Para evitar interrupciones, establece el campo failurePolicy en Ignore para los webhooks no críticos. En el caso de los webhooks críticos, asegúrate de que su servicio de respaldo tenga alta disponibilidad y excluye el espacio de nombres kube-system de la supervisión de webhooks con un namespaceSelector para evitar bloqueos del plano de control. Para obtener más información, consulta Garantiza la estabilidad del plano de control cuando usas webhooks.

Cómo resolver problemas causados por cuotas de recursos

Una cuota de recursos mal calculada en el espacio de nombres kube-system puede impedir que GKE cree Pods críticos del sistema. Debido a que se bloquean componentes como las redes (CNI) y el DNS, este problema puede impedir que los nodos nuevos se unan correctamente al clúster.

Síntomas:

  • Los Pods críticos en el espacio de nombres kube-system (por ejemplo, netd, konnectivity-agent o kube-dns) están atascados en el estado Pending.
  • Los mensajes de error en los registros del clúster o el resultado de kubectl describe pod muestran errores como exceeded quota: gcp-critical-pods.

Causa:

Este problema se produce cuando el controlador de cuotas de recursos de Kubernetes deja de actualizar con precisión el recuento utilizado en los objetos ResourceQuota. Una causa común es un webhook de admisión de terceros que no funciona correctamente y bloquea las actualizaciones del controlador, lo que hace que el uso de la cuota parezca mucho más alto de lo que realmente es.

Solución:

  1. Dado que es más probable que la causa raíz sea un webhook problemático, sigue las instrucciones de la sección Cómo resolver problemas causados por webhooks de admisión para identificar y corregir los webhooks que puedan estar bloqueando los componentes del sistema. Por lo general, corregir el webhook resuelve el problema de cuota automáticamente.

  2. Verifica que el uso registrado de la cuota no esté sincronizado con la cantidad real de Pods en ejecución. En este paso, se confirma si el recuento del objeto ResourceQuota es incorrecto:

    1. Verifica el uso informado de la cuota:

      kubectl get resourcequota gcp-critical-pods -n kube-system -o yaml

    2. Verifica la cantidad real de Pods:

      kubectl get pods -n kube-system --no-headers | wc -l

  3. Si el recuento de uso en ResourceQuota parece incorrecto (por ejemplo, mucho más alto que la cantidad real de Pods), borra el objeto gcp-critical-pods. El plano de control de GKE está diseñado para volver a crear automáticamente este objeto con los recuentos de uso correctos y conciliados:

    kubectl delete resourcequota gcp-critical-pods -n kube-system

  4. Supervisa el espacio de nombres kube-system durante unos minutos para asegurarte de que se vuelva a crear el objeto y de que los Pods pendientes comiencen a programarse.

Cómo resolver problemas causados por DaemonSets de terceros

Un DaemonSet de terceros recién implementado o actualizado, que a menudo se usa para la seguridad, la supervisión o el registro, a veces puede causar inestabilidad en el nodo. Este problema puede ocurrir si el DaemonSet interfiere con el tiempo de ejecución del contenedor o la red del nodo, consume recursos excesivos del sistema o realiza modificaciones inesperadas en el sistema.

Síntomas:

Si observas los siguientes síntomas, es posible que un DaemonSet de terceros implementado o modificado recientemente sea la causa de las fallas en los nodos:

  • Varios nodos, posiblemente en todo el clúster, ingresan en el estado NotReady poco después de que se implementa o actualiza el DaemonSet.
  • Los registros de kubelet para los nodos afectados informan errores como los siguientes:
    • container runtime is down
    • Failed to create pod sandbox
    • Errores de conexión al socket del entorno de ejecución del contenedor (por ejemplo, /run/containerd/containerd.sock).
  • Los Pods, incluidos los Pods del sistema o los Pods propios del DaemonSet, se quedan en los estados PodInitializing o ContainerCreating.
  • Los registros de contenedores para aplicaciones muestran errores inusuales, como exec format error.
  • El detector de problemas del nodo puede informar condiciones relacionadas con el estado del entorno de ejecución o la presión de recursos.

Causa:

El DaemonSet de terceros podría afectar la estabilidad del nodo por los siguientes motivos:

  • Consumir CPU, memoria o E/S de disco en exceso, lo que afecta el rendimiento de los componentes críticos del nodo
  • Interferir en el funcionamiento del entorno de ejecución del contenedor
  • Causar conflictos con la configuración de red del nodo o el complemento de la interfaz de red de contenedor (CNI)
  • Alterar la configuración del sistema o las políticas de seguridad de una manera no intencional

Solución:

Para determinar si un DaemonSet es la causa, aísla y prueba lo siguiente:

  1. Identifica los DaemonSets: Enumera todos los DaemonSets que se ejecutan en tu clúster:

    kubectl get daemonsets --all-namespaces

    Presta mucha atención a los DaemonSets que no forman parte de la instalación predeterminada de GKE.

    A menudo, puedes identificar estos DaemonSets revisando lo siguiente:

    • Espacio de nombres: Los componentes predeterminados de GKE suelen ejecutarse en el espacio de nombres kube-system. Es probable que los DaemonSets en otros espacios de nombres sean personalizados o de terceros.
    • Nombres: Los DaemonSets predeterminados suelen tener nombres como gke-metrics-agent, netd o calico-node. Los agentes externos suelen tener nombres que reflejan el producto.

  2. Correlaciona el tiempo de implementación: Comprueba si la aparición de nodos NotReady coincide con la implementación o actualización de un DaemonSet específico de terceros.

  3. Prueba en un solo nodo:

    1. Elige un nodo afectado.
    2. Acordona y purga el nodo.
    3. Impide temporalmente que el DaemonSet se programe en este nodo:
      • Aplica una etiqueta de nodo temporal y configura la afinidad o la anti-afinidad de nodo en el manifiesto del DaemonSet.
      • Borra el Pod del DaemonSet en ese nodo específico.
    4. Reinicia la instancia de máquina virtual del nodo.
    5. Observa si el nodo se convierte en Ready y permanece estable mientras DaemonSet no se ejecuta en él. Si los problemas reaparecen después de que se vuelve a introducir el DaemonSet, es probable que sea un factor que contribuye al problema.

  4. Consulta al proveedor: Si sospechas que un agente externo es la causa, revisa la documentación del proveedor para conocer los problemas de compatibilidad conocidos o las prácticas recomendadas para ejecutar el agente en GKE. Si necesitas más ayuda, comunícate con el proveedor del software.

Verifica que el nodo se haya recuperado

Después de aplicar una posible solución, sigue estos pasos para verificar que el nodo se haya recuperado correctamente y sea estable:

  1. Verifica el estado del nodo:

    kubectl get nodes -o wide

    Busca el nodo afectado en el resultado. La columna Status ahora debería mostrar un valor de Ready. Es posible que el estado tarde unos minutos en actualizarse después de que se aplique la corrección. Si el estado sigue mostrando NotReady o cambia entre estados, el problema no se resolvió por completo.

  2. Inspecciona la sección Conditions del nodo:

    kubectl describe node NODE_NAME

    En la sección Conditions, verifica los siguientes valores:

    • La condición Ready tiene el estado True.
    • Las condiciones negativas que antes tenían el estado True (por ejemplo, MemoryPressure o NetworkUnavailable) ahora tienen el estado False. Los campos Reason y Message para estas condiciones deben indicar que el problema se resolvió.

  3. Probar la programación de Pods Si el nodo no podía ejecutar cargas de trabajo anteriormente, verifica si se están programando Pods nuevos en él y si los Pods existentes se están ejecutando sin problemas:

    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

    Los pods del nodo deben tener un estado Running o Completed. No deberías ver Pods atascados en el estado Pending ni en otros estados de error.

¿Qué sigue?