Solucionar problemas de nodos con el estado NotReady en GKE

El estado NotReady en Google Kubernetes Engine (GKE) significa que el kubelet del nodo no está enviando información 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 un tiempo de inactividad.

Usa este documento para distinguir entre los estados NotReady esperados y los problemas reales, diagnosticar la causa principal y encontrar soluciones a problemas habituales, como el agotamiento de recursos, los problemas de red y los errores 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, así como a los desarrolladores de aplicaciones que quieran 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 usuario de GKE.

Antes de empezar

  • Para obtener los permisos que necesitas para realizar las tareas de este documento, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos en tu proyecto Google Cloud :

    Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar acceso a proyectos, carpetas y organizaciones.

    También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.

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

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

    Haz los cambios siguientes:

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

Comprobar 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 más detalles, como las direcciones IP y las versiones del kernel, que son útiles para el diagnóstico, usa la marca -o wide:

    kubectl get nodes -o wide

    El resultado debería ser similar al 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 que tengan el valor 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, siga estos pasos:

    kubectl describe node NODE_NAME

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

    En el resultado, céntrate en la sección Conditions para conocer 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 de cualquier condición negativa o Unknown de la condición Ready indica que hay un problema. Presta especial 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 ha detectado un interbloqueo, que es un error grave que puede bloquear 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 con los controladores o el hardware.
    • NetworkUnavailable: True si la red del nodo no está configurada correctamente.
    • OutOfDisk: True si el espacio en disco disponible se agota por completo. 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 está experimentando un 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 de nodo no ha recibido información del nodo durante un periodo de gracia (el valor predeterminado es de 50 segundos) y el estado del nodo es desconocido.

    A continuación, consulta la sección Events, que proporciona un registro cronológico de las acciones y las observaciones sobre el nodo. Esta cronología es fundamental para entender qué ocurrió inmediatamente antes de que el nodo se convirtiera en NotReady. Busca mensajes específicos que puedan ayudarte a encontrar la causa, como advertencias de desalojo (que indican presión de recursos), comprobaciones de estado fallidas o eventos del ciclo de vida de los nodos, como el acordonamiento para realizar 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. Consulta los registros de kubelet para ver el estado de NotReady.

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

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

      Ir a Explorador de registros

    3. En el panel de consultas, introduce 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"

      Haz los cambios siguientes:

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

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

    5. Si los registros de kubelet no revelan la causa principal, consulta 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 un fallo de tiempo de ejecución o un pánico del kernel) que lo ha provocado.

    6. En el panel de consultas del Explorador de registros, introduce 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")

      Sustituye COMPONENT_NAME por uno de los siguientes valores:

      • container-runtime: el tiempo de ejecución (containerd), responsable del ciclo de vida completo del contenedor, incluida la extracción de imágenes y la gestión de la ejecución del contenedor. Revisar los registros container-runtimees fundamental para solucionar problemas relacionados con la creación de instancias de contenedores, errores de servicios de tiempo de ejecución o problemas causados por la configuración del tiempo de ejecución.
      • node-problem-detector: una utilidad que monitoriza de forma proactiva e informa de diversos problemas a nivel de nodo al plano de control. Sus registros son fundamentales para identificar problemas sistémicos subyacentes que pueden provocar inestabilidad en los nodos, como bloqueos del kernel, corrupción del sistema de archivos o fallos de hardware, que es posible que no detecten otros componentes de Kubernetes.

    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 Google Cloud consola, ve a la página Explorador de métricas:

      Ir a Explorador de métricas

    2. En el explorador de métricas, comprueba si la instancia de Compute Engine subyacente del nodo tiene recursos insuficientes. Céntrate en las métricas relacionadas con la CPU, la memoria y la E/S de disco. Por ejemplo:

      • Métricas de nodos de GKE: empieza con las métricas que tengan el prefijo kubernetes.io/node/, como kubernetes.io/node/cpu/allocatable_utilization o kubernetes.io/node/memory/allocatable_utilization. Estas métricas muestran cuántos de los recursos disponibles del nodo están usando tus pods. El importe disponible no incluye los recursos que Kubernetes reserva para la sobrecarga del sistema.
      • Métricas del SO invitado: para ver el SO del nodo desde dentro, 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.

      Para obtener las métricas del SO invitado y del hipervisor, debes filtrar por el nombre de la instancia de Compute Engine subyacente, no por el nombre del nodo de Kubernetes. Para encontrar el nombre de 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.

Identificar la causa por el síntoma

Si has identificado un síntoma específico, como un mensaje de registro, una condición de nodo o un evento de clúster, consulta la siguiente tabla para obtener consejos sobre cómo solucionar el problema:

Categoría Síntoma o mensaje de registro Posible causa Pasos para solucionar problemas
Condiciones de los nodos NetworkUnavailable: True Problema de conectividad entre el nodo y el plano de control o fallo del complemento Container Network Interface (CNI). Solucionar problemas de conectividad de red
MemoryPressure: True El nodo no tiene suficiente memoria. Solucionar problemas de escasez de recursos de nodos
DiskPressure: True El nodo no tiene suficiente espacio en disco. Solucionar problemas de escasez de recursos de nodos
PIDPressure: True El nodo no tiene suficientes IDs de proceso disponibles. Solucionar 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 las E/S, o a que hay demasiados pods. Resolver problemas de PLEG
Out of memory: Kill process
sys oom event		 La memoria del nodo está completamente agotada. Resolver eventos de falta de memoria a nivel del sistema
leases.coordination.k8s.io...is forbidden El espacio de nombres kube-node-lease no se termina. 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 ha fallado o está mal configurado. Resolver problemas del tiempo de ejecución del contenedor
Los pods se quedan bloqueados en Terminating
Los registros de Kubelet muestran DeadlineExceeded para el contenedor de eliminaciónLos registros de containerd muestran mensajes Kill container repetidos
 Procesos bloqueados en el estado de suspensión de disco ininterrumpible (estado D), a menudo relacionados con la E/S. Resolver procesos bloqueados en el estado D
Síntomas a nivel de clúster Se produce un fallo en varios nodos después de implementar un DaemonSet. DaemonSet interfiere con las operaciones de los nodos. Resolver problemas causados por DaemonSets de terceros
compute.instances.preempted en los registros de auditoría. Se ha interrumpido la VM de acceso puntual, que es el comportamiento esperado. Confirmar la expropiación de nodos
kube-system Pods atascados en Pending. El webhook de admisión está bloqueando componentes críticos. Resolver problemas causados por webhooks de admisión
exceeded quota: gcp-critical-pods Una cuota mal configurada está bloqueando los pods del sistema. Resolver problemas causados por cuotas de recursos

Comprobar si hay eventos NotReady esperados

El estado NotReady no siempre indica que haya un problema. Es un comportamiento esperado durante operaciones planificadas, como una actualización de un pool de nodos, o si usas determinados tipos de máquinas virtuales.

Confirmar operaciones del ciclo de vida de los nodos

Síntomas:

Un nodo muestra temporalmente el estado NotReady durante determinados eventos del ciclo de vida.

Causa:

El estado de un nodo pasa a ser NotReady temporalmente durante varios eventos comunes del ciclo de vida. Este comportamiento es el esperado siempre que se cree o se vuelva a crear un nodo, como en los siguientes casos:

  • Actualizaciones de grupos de nodos: durante una actualización, se vacía y se sustituye cada nodo. El nodo nuevo y actualizado tiene el estado NotReady hasta que termina de inicializarse y se une al clúster.
  • Reparación automática de nodos: cuando GKE sustituye un nodo que no funciona correctamente, el nodo de sustitución permanece NotReady mientras se aprovisiona.
  • Escalado vertical del autoescalador de clústeres: cuando se añaden nodos nuevos, empiezan con el estado NotReady y pasan al estado Ready solo cuando se han aprovisionado por completo y se han unido al clúster.
  • Cambios manuales en la plantilla de instancia: GKE vuelve a crear los nodos cuando aplicas cambios en la plantilla. El nuevo nodo tiene el estado NotReady durante la fase de inicio.

Resolución:

Los nodos solo deben tener el estado NotReady durante un breve periodo. Si el estado persiste durante más de 10 minutos, investiga otras causas.

Confirmar la apropiación de nodos

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

Síntomas:

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

  • Un nodo pasa inesperadamente al estado NotReady antes de que el autoescalador del clúster lo elimine y lo vuelva a crear.
  • Los registros de auditoría de Cloud muestran un evento compute.instances.preempted de la instancia de VM subyacente.

Causa:

El nodo se estaba ejecutando en una instancia de Spot VM o de VM interrumpible y Compute Engine ha reclamado esos recursos de computación para otra tarea. Las máquinas virtuales de acceso puntual se pueden interrumpir en cualquier momento, aunque suelen avisar con 30 segundos de antelación.

Resolución:

Utiliza máquinas virtuales de acceso puntual o máquinas virtuales interrumpibles solo para cargas de trabajo tolerantes a fallos, sin estado o por lotes que estén diseñadas para gestionar las finalizaciones frecuentes de forma correcta. Para las cargas de trabajo de producción o con estado que no puedan tolerar interrupciones repentinas, aprovisiona tus grupos de nodos con máquinas virtuales estándar bajo demanda.

Solucionar problemas de escasez de recursos de nodos

Un nodo suele pasar a estar en estado NotReady porque no tiene recursos esenciales, como CPU, memoria o espacio en disco. Si un nodo no tiene suficientes recursos de este tipo, los componentes críticos no pueden funcionar correctamente, lo que provoca inestabilidad en las aplicaciones y que el nodo no responda. En las secciones siguientes se describen las diferentes formas en las que pueden producirse estas carencias, desde condiciones de presión generales hasta eventos más graves en todo el sistema.

Resolver la presión de recursos de nodos

El agotamiento de recursos se produce cuando un nodo no tiene suficiente CPU, memoria, espacio en disco o IDs de proceso (PIDs) para ejecutar sus cargas de trabajo. Este problema puede provocar que el estado sea NotReady.

Síntomas:

Si observas las siguientes condiciones y registros de los nodos, 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 en condiciones como OutOfDisk, MemoryPressure, DiskPressure o PIDPressure.
  • Los registros de kubelet pueden contener eventos de falta de memoria (OOM), lo que indica que se ha invocado el proceso OOM Killer del sistema.

Causa:

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

Resolución:

En el caso de los clústeres estándar, prueba las siguientes soluciones:

En 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 gestiona automáticamente en función de las solicitudes de tus 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 con los recursos pueden indicar la necesidad de optimizar las solicitudes de pods o, en casos excepcionales, un problema de la plataforma que requiera la asistencia de Cloud Customer Care.

Resolver eventos de falta de memoria a nivel del sistema

Un evento de falta de memoria (OOM) a nivel de sistema se produce 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 OOM a nivel de contenedor, en el que un solo pod supera sus límites de memoria.

Síntomas:

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

  • Observas 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 ha detectado un evento OOM a nivel de 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 que consumen más memoria.

Causa:

La memoria general del nodo se ha agotado. 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 que es demasiado pequeño para las demandas de memoria colectivas de todos sus pods en ejecución.

Resolución:

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

Resolver problemas de PLEG

El generador de eventos del ciclo de vida de los pods (PLEG) es un componente de kubelet. Comprueba periódicamente el estado de todos los contenedores del nodo e informa de los cambios a kubelet.

Cuando el PLEG tiene 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 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:

Los problemas de PLEG suelen deberse a problemas de rendimiento que impiden que kubelet reciba actualizaciones oportunas del tiempo de ejecución del contenedor. Las causas más frecuentes son 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.
  • Limitación de E/S: el disco de arranque del nodo está experimentando operaciones de E/S intensivas, lo que puede ralentizar todas las tareas relacionadas con el disco.
  • Demasiados pods: si hay demasiados pods en un solo nodo, se puede sobrecargar el kubelet y el tiempo de ejecución del contenedor, lo que provoca una contención de recursos.

Resolución:

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

En los clústeres Autopilot, aunque no puedes cambiar directamente el tamaño ni el tipo de disco de un nodo, puedes influir en el hardware en el que se ejecutan tus cargas de trabajo mediante ComputeClasses personalizados. 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 indicar dónde se deben programar tus pods.

Si no usas ComputeClasses, ajusta las implementaciones de cargas de trabajo (como el número de réplicas y las solicitudes o los límites de recursos) y asegúrate de que se ajustan a las restricciones de Autopilot. Si los problemas de PLEG persisten después de optimizar tus cargas de trabajo, ponte en contacto con el servicio de atención al cliente de Cloud.

Resolver procesos bloqueados en estado D

Los procesos bloqueados en un estado de suspensión de disco ininterrumpible (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 lleva a un estado NotReady.

Síntomas:

  • Los pods, sobre todo los que usan almacenamiento de red como NFS, se quedan atascados en el estado Terminating durante mucho tiempo.
  • Los registros de Kubelet muestran errores DeadlineExceeded al intentar detener un contenedor.
  • Los registros de la consola serie del nodo pueden mostrar mensajes del kernel sobre hung tasks o tareas bloqueadas durante más de 120 segundos.

Causa:

Los procesos entran en el estado D cuando esperan a que se complete una operación de E/S y no se pueden interrumpir. Entre las causas más habituales se incluyen las siguientes:

  • Sistemas de archivos remotos lentos o que no responden, como un recurso compartido NFS mal configurado o sobrecargado.
  • El rendimiento del disco se ha degradado gravemente o se han producido errores de E/S de hardware en los discos locales del nodo.

Resolución:

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

Clústeres estándar

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

    1. Conéctate al nodo afectado mediante SSH:

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

      Haz los cambios siguientes:

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

    2. Buscar procesos en estado D:

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

      El resultado debería ser similar al siguiente:

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

      La salida no tendrá encabezado. Las columnas, por 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 NFS.
      • Si la columna wchan incluye términos como io_schedule, jbd2 o ext4, significa que el proceso está esperando el disco de arranque local del nodo.

    4. Para obtener más información sobre las funciones del kernel que está esperando el proceso, consulta la pila de llamadas del kernel del proceso:

      cat /proc/PID/stack

      Sustituye PID por el ID del proceso que has encontrado en el paso anterior.

  2. Reinicia el nodo. Reiniciar suele ser la forma más eficaz de eliminar un proceso que se ha quedado bloqueado en el estado D.

    1. Drena el nodo.
    2. Elimine la instancia de VM subyacente. Normalmente, GKE crea una nueva VM para sustituirla.

  3. Después de solucionar el problema inmediato, investiga el sistema de almacenamiento subyacente para evitar que vuelva a ocurrir.

    • Si tienes problemas con el almacenamiento de red (NFS), usa las herramientas de monitorización de tu proveedor de almacenamiento para comprobar si hay una latencia alta, errores del lado del servidor o problemas de red entre el nodo de GKE y el servidor NFS.

    • Si tienes problemas con el disco local, comprueba 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. Comprobar los registros de los nodos: en Cloud Logging, analiza los registros del nodo afectado. Filtra por el nombre del nodo y el periodo del problema. Busca mensajes del kernel que indiquen errores de E/S, tiempos de espera de almacenamiento (por ejemplo, en disco o NFS) o mensajes de controladores CSI.
    2. Comprobar los registros de la carga de trabajo: examina los registros de los pods que se ejecutan en el nodo afectado. Los registros de aplicaciones pueden revelar errores relacionados con operaciones de archivos, llamadas a bases de datos o acceso al almacenamiento de red.
    3. Usa Cloud Monitoring: aunque no puedes obtener detalles a nivel de proceso, comprueba si hay problemas de E/S a nivel de nodo.

  2. Activa la sustitución de un nodo para borrar el estado.

    No puedes eliminar manualmente la VM subyacente. Para activar una sustitución, vacía el nodo. Esta acción acordonará el nodo y expulsará los pods.

    GKE detecta automáticamente los nodos que no están en buen estado e inicia las reparaciones, normalmente sustituyendo la VM subyacente.

    Si el nodo sigue bloqueado después de drenarse y no se sustituye automáticamente, ponte en contacto con el servicio de atención al cliente de Cloud.

  3. Después de solucionar el problema inmediato, investiga el sistema de almacenamiento subyacente para evitar que vuelva a ocurrir.

    • Si tienes problemas con el disco local, comprueba 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. Puedes filtrar estas métricas del grupo de instancias subyacente del grupo de nodos, aunque Google gestiona las instancias individuales.
    • Si tienes problemas con el almacenamiento de red (NFS), usa las herramientas de monitorización de tu proveedor de almacenamiento para comprobar si hay una latencia alta, errores del lado del servidor o problemas de red entre el nodo de GKE y el servidor NFS. Consulta los registros de los pods de cualquier controlador CSI en Cloud Logging.

Solucionar problemas con los componentes principales

Una vez que hayas descartado las causas esperadas y la falta de recursos, es posible que el problema se deba al software del nodo o a un mecanismo principal de Kubernetes. Un NotReady estado puede producirse cuando falla un componente crítico, como el tiempo de ejecución del contenedor. También puede ocurrir cuando se avería un mecanismo de comprobación del estado principal de Kubernetes, como el sistema de concesión de nodos.

Resolver problemas del entorno de ejecución del contenedor

Los problemas con el tiempo de ejecución del contenedor, como containerd, pueden impedir que kubelet lance pods en un nodo.

Síntomas:

Si observa 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 conectar con el socket del tiempo de ejecución (por ejemplo, unix:///var/run/docker.sock o unix:///run/containerd/containerd.sock).

Causa:

El tiempo de ejecución del contenedor no funciona correctamente, está mal configurado o se ha quedado bloqueado en un bucle de reinicio.

Resolución:

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

  1. Analizar los registros del tiempo de ejecución del contenedor:

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

      Ir a Explorador de registros

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

      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

      Haz los cambios siguientes:

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

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

    4. Para comprobar si el tiempo de ejecución está atascado en un bucle de reinicio, ejecuta una consulta que busque mensajes de inicio. Si se recibe un número elevado de estos mensajes en un breve periodo, se confirma que se reinicia con frecuencia.

      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")

      Si un servicio se reinicia con frecuencia, suele deberse a un problema subyacente, como un archivo de configuración dañado o una presión de recursos, que provoca que el servicio falle repetidamente.

  2. Revisa la configuración de containerd para ver si hay modificaciones: si los ajustes son incorrectos, el tiempo de ejecución del contenedor puede fallar. Puede hacer cambios en la configuración mediante un archivo de configuración del sistema de nodos o mediante modificaciones directas que realicen 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)"

      Haz los cambios siguientes:

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

      Si el resultado muestra una sección containerdConfig, significa que GKE gestiona estos ajustes personalizados. Para modificar o revertir los ajustes, siga las instrucciones que se indican en el artículo Personalizar la configuración de containerd en nodos de GKE.

    2. Si las personalizaciones gestionadas por GKE no están activas o sospechas que se han producido 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 e inspecciona los registros de los DaemonSets sospechosos.

    3. En los clústeres estándar, inspecciona el archivo de configuración directamente. No se puede acceder por SSH ni inspeccionar los archivos manualmente en los clústeres de Autopilot porque Google gestiona la configuración del tiempo de ejecución. Informa de los problemas de tiempo de ejecución persistentes a Google Cloud Customer Care.

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

      1. Conéctate al nodo mediante SSH:

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

        Haz los cambios siguientes:

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

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

        sudo cat /etc/containerd/config.toml

      3. Para comprobar si se han realizado modificaciones recientemente, consulta 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 has ejecutado en el paso anterior. Cualquier ajuste de /etc/containerd/config.toml que no esté en el resultado de gcloud es un cambio no gestionado.

    5. Para corregir cualquier error de configuración, elimina los cambios que no se hayan aplicado mediante una configuración del sistema de nodos.

  3. Solucionar problemas habituales del tiempo de ejecución: para obtener más pasos para solucionar problemas, consulta Solucionar problemas del tiempo de ejecución del contenedor.

Resolver problemas con el espacio de nombres kube-node-lease

Los recursos del espacio de nombres kube-node-lease se encargan de mantener el estado de los nodos. Este espacio de nombres no se debe eliminar. Si intentas eliminar este espacio de nombres, se quedará en el estado Terminating. Cuando el espacio de nombres kube-node-lease se queda bloqueado en el estado Terminating, los kubelets no pueden renovar sus concesiones de comprobación de estado. Este problema provoca 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 la inestabilidad de todo el clúster se deba a un problema con el espacio de nombres kube-node-lease:

  • Los registros de kubelet de 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 gestiona los latidos de nodo, está bloqueado de forma anómala en el estado Terminating. Este error impide que el servidor de la API de Kubernetes permita la creación o modificación de objetos en el espacio de nombres. Por lo tanto, los kubelets no pueden renovar sus objetos Lease, que son esenciales para indicar su actividad al plano de control. Si no se reciben estas actualizaciones de estado, el plano de control no puede confirmar que los nodos estén en buen estado, lo que provoca que el estado de los nodos alterne entre Ready y NotReady.

Estos son algunos de los motivos por los que el propio espacio de nombres kube-node-lease podría quedarse bloqueado en el estado Terminating:

  • Recursos con finalizadores: aunque es menos habitual en el espacio de nombres kube-node-lease del sistema (que contiene principalmente objetos Lease), un recurso de este espacio 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 eliminar un recurso. Si el controlador responsable de quitar el finalizador no funciona correctamente, el recurso no se elimina y se detiene el proceso de eliminación del espacio de nombres.
  • Servicios de API agregados que no funcionan correctamente o no responden: la finalización del espacio de nombres se puede bloquear si un objeto APIService, que se usa para registrar un servidor de API agregado, está vinculado al espacio de nombres y no funciona correctamente. El plano de control puede esperar a que el servidor de API agregado se cierre o se limpie correctamente, lo que no ocurrirá si el servicio no responde.
  • Problemas con el plano de control o el controlador: en casos excepcionales, los errores o problemas en el plano de control de Kubernetes, concretamente en el controlador de espacio de nombres, podrían impedir que se recoja y se elimine correctamente el espacio de nombres.

Resolución:

Sigue las indicaciones del artículo Solucionar problemas con espacios de nombres que se quedan en el estado Terminating.

Solucionar 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 CNI, lo que provoca que el nodo tenga el 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 del nodo muestran errores similares a los siguientes:
    • connection timeout to the control plane IP address
    • network plugin not ready
    • CNI plugin not initialized
    • connection refused o timeout al intentar acceder a la dirección IP del plano de control.
  • Los pods, sobre todo los del espacio de nombres kube-system, se quedan atascados en ContainerCreating con eventos como NetworkPluginNotReady.

Causa:

Los síntomas relacionados con la red suelen indicar un fallo 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.
  • Error del complemento CNI: el complemento CNI, que se encarga de configurar la red de pods, no se está ejecutando correctamente o no se ha podido inicializar.
  • Problemas con los webhooks: los webhooks de admisión mal configurados pueden interferir con los recursos relacionados con el complemento CNI, lo que impide que la red se configure correctamente.

Resolución:

Para solucionar 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 un minuto o dos mientras se inicializan el complemento CNI y otros componentes. Si el estado persiste, sigue los pasos que se indican a continuación.

  2. Verifica la conectividad entre el nodo y el plano de control, así como las reglas de cortafuegos: asegúrate de que la ruta de red entre el nodo y el plano de control esté abierta y funcione correctamente:

    1. Comprueba las reglas de cortafuegos: asegúrate de que las reglas de cortafuegos de tu VPC permitan el tráfico necesario entre los nodos de GKE y el plano de control. Para obtener información sobre las reglas que requiere GKE para la comunicación entre nodos y el plano de control, consulta Reglas de cortafuegos creadas automáticamente.
    2. Prueba de conectividad: usa la prueba de conectividad del Centro de control de redes para verificar la ruta de red entre la dirección IP interna del nodo y la dirección IP del endpoint del plano de control en el puerto 443. El resultado de Not Reachable suele ayudarte a identificar la regla de cortafuegos o el problema de enrutamiento que está bloqueando la comunicación.

  3. Investiga el estado y los registros del complemento CNI: si la red del nodo no está lista, puede que el problema sea del complemento CNI.

    1. Comprobar el estado del pod de CNI: identifica el complemento de CNI que se está usando (por ejemplo, netd o calico-node) y comprueba 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 netd Pods 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. Solucionar errores específicos de CNI:

      • Si los registros muestran Failed to allocate IP address, es posible que se hayan agotado los intervalos de direcciones IP de tu pod. Verifica la utilización de las direcciones IP de los pods y revisa los intervalos CIDR de tu clúster.
      • Si los registros muestran NetworkPluginNotReady o cni plugin not initialized, confirma que el nodo tiene suficientes recursos de CPU y memoria. También puedes probar a reiniciar el pod de CNI eliminándolo, lo que permite que 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. Comprueba si hay interferencias en el webhook de admisión: los webhooks que no funcionan correctamente pueden impedir que se inicien los pods de CNI, lo que provoca que el nodo tenga el estado NetworkNotReady.

    5. Comprueba los registros del servidor de la API: revisa los registros del servidor de la API en Cloud Logging para ver si hay 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 está causando problemas, es posible que tengas que identificar el ValidatingWebhookConfiguration o el MutatingWebhookConfiguration problemático y inhabilitarlo temporalmente para que el nodo esté listo. Para obtener más información, consulta Resolver problemas causados por webhooks de admisión.

Solucionar problemas de configuración incorrecta de clústeres

En las siguientes secciones se explica cómo auditar algunas configuraciones de todo el clúster que pueden interferir con las operaciones normales de los nodos.

Resolver problemas causados por webhooks de admisión

Un webhook de admisión que esté mal configurado, no esté disponible o sea demasiado lento puede bloquear solicitudes de API críticas, 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 los del espacio de nombres kube-system (como los pods de CNI o de almacenamiento), están atascados en el estado Pending o Terminating.
  • Los nodos nuevos no pueden unirse al clúster y, a menudo, se agota el tiempo de espera con el estado NotReady.

Causa:

Los webhooks de admisión mal configurados o que no responden pueden estar bloqueando operaciones esenciales del clúster.

Resolución:

Revisa las configuraciones de webhook para asegurarte de que sean resilientes y tengan el ámbito adecuado. Para evitar interrupciones, asigna el valor Ignore al campo failurePolicy en los webhooks no críticos. En el caso de los webhooks críticos, asegúrate de que su servicio de respaldo tenga una alta disponibilidad y excluye el espacio de nombres kube-system de la supervisión de webhooks mediante un namespaceSelector para evitar los bloqueos del plano de control. Para obtener más información, consulta Asegurar la estabilidad del plano de control al usar webhooks.

Resolver problemas causados por cuotas de recursos

Si se calcula mal la cuota de recursos en el espacio de nombres kube-system, GKE no podrá crear pods del sistema críticos. Como se bloquean componentes como la red (CNI) y el DNS, este problema puede impedir que los nodos nuevos se unan al clúster correctamente.

Síntomas:

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

Causa:

Este problema se produce cuando el controlador de cuota de recursos de Kubernetes deja de actualizar con precisión el recuento usado en los objetos ResourceQuota. Una causa habitual es un webhook de admisión de terceros que no funciona correctamente y que bloquea las actualizaciones del controlador, lo que hace que el uso de la cuota parezca mucho mayor de lo que es en realidad.

Resolución:

  1. Como es muy probable que la causa principal sea un webhook problemático, siga las instrucciones de la sección Resolver problemas causados por webhooks de admisión para identificar y corregir los webhooks que puedan estar bloqueando componentes del sistema. Si corriges el webhook, el problema de cuota se suele resolver automáticamente.

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

    1. Comprueba el uso registrado de la cuota:

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

    2. Comprueba el número real de pods:

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

  3. Si el recuento usado en ResourceQuota parece incorrecto (por ejemplo, si es mucho mayor que el número real de pods), elimina el objeto gcp-critical-pods. El plano de control de GKE se ha 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. Monitoriza el espacio de nombres kube-system durante unos minutos para asegurarte de que el objeto se vuelve a crear y de que los pods pendientes empiezan a programarse.

Solucionar problemas causados por DaemonSets de terceros

Un DaemonSet de terceros recién implementado o actualizado, que se suele usar para la seguridad, la monitorización o el registro, a veces puede provocar inestabilidad en los nodos. Este problema puede producirse si el DaemonSet interfiere con el tiempo de ejecución del contenedor o la red del nodo, consume recursos excesivos del sistema o hace modificaciones inesperadas en el sistema.

Síntomas:

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

  • Varios nodos, posiblemente en todo el clúster, entran en el estado NotReady poco después de que se implemente o actualice el DaemonSet.
  • Los registros de Kubelet de los nodos afectados muestran errores como los siguientes:
    • container runtime is down
    • Failed to create pod sandbox
    • Errores al conectar con el socket del tiempo de ejecución del contenedor (por ejemplo, /run/containerd/containerd.sock).
  • Los pods, incluidos los pods del sistema o los pods propios de DaemonSet, están atascados en los estados PodInitializing o ContainerCreating.
  • Los registros de contenedores de las aplicaciones muestran errores inusuales, como exec format error.
  • Node Problem Detector puede informar de condiciones relacionadas con el estado del tiempo de ejecución o la presión de los recursos.

Causa:

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

  • Consumir demasiada CPU, memoria o E/S de disco, lo que afecta al rendimiento de los componentes críticos del nodo.
  • Interferir con el funcionamiento del entorno de ejecución del contenedor.
  • Provoca conflictos con la configuración de red del nodo o con el complemento de interfaz de red de contenedor (CNI).
  • Alterar la configuración del sistema o las políticas de seguridad de forma no intencionada.

Resolución:

Para determinar si un DaemonSet es la causa, aíslelo y pruébelo:

  1. Identifica los DaemonSets: enumera todos los DaemonSets que se estén ejecutando en tu clúster:

    kubectl get daemonsets --all-namespaces

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

    A menudo, puedes identificar estos DaemonSets consultando lo siguiente:

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

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

  3. Hacer pruebas en un solo nodo:

    1. Elige un nodo afectado.
    2. Acordonar y drenar el nodo.
    3. Impide temporalmente que DaemonSet se programe en este nodo:
      • Aplica una etiqueta de nodo temporal y configura la afinidad o la antiafinidad de nodos en el manifiesto de DaemonSet.
      • Elimina el pod de 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 vuelven a aparecer después de que se vuelva a introducir el DaemonSet, es probable que sea un factor que contribuya a ellos.

  4. Consulta al proveedor: si sospechas que la causa es un agente de terceros, revisa la documentación del proveedor para ver si hay problemas de compatibilidad conocidos o prácticas recomendadas para ejecutar el agente en GKE. Si necesitas más ayuda, ponte en contacto con el proveedor del software.

Verificar que el nodo se ha recuperado

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

  1. Comprueba el estado del nodo:

    kubectl get nodes -o wide

    Busca el nodo afectado en el resultado. La columna Status ahora debería mostrar el valor Ready. El estado puede tardar unos minutos en actualizarse después de que se aplique la corrección. Si el estado sigue siendo NotReady o va cambiando, significa que el problema no se ha resuelto por completo.

  2. Inspecciona la sección Conditions del nodo:

    kubectl describe node NODE_NAME

    En la sección Conditions, compruebe 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 de estas condiciones deben indicar que el problema se ha resuelto.

  3. Prueba la programación de pods. Si el nodo no podía ejecutar cargas de trabajo anteriormente, comprueba si se están programando nuevos pods en él y si los pods que ya existen 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 el estado Running o Completed. No deberías ver pods atascados en el estado Pending ni en otros estados de error.

Siguientes pasos