Solucionar problemas de actualización de clústeres

Si la actualización del plano de control o del grupo de nodos de Google Kubernetes Engine (GKE) falla, se bloquea o provoca un comportamiento inesperado de la carga de trabajo, es posible que tengas que solucionar el problema. Es fundamental mantener actualizados el plano de control y los grupos de nodos para garantizar la seguridad y el rendimiento, y resolver cualquier problema ayuda a que tu entorno siga siendo estable.

Para solucionar los problemas habituales de actualización, un buen primer paso es monitorizar el proceso de actualización del clúster. A continuación, puedes consultar consejos para resolver el problema:

Esta información es importante para los administradores y operadores de la plataforma que quieran diagnosticar las causas principales de las actualizaciones bloqueadas o fallidas, gestionar las políticas de mantenimiento y resolver los problemas de incompatibilidad de versiones. Los desarrolladores de aplicaciones pueden consultar las directrices para resolver problemas de cargas de trabajo posteriores a la actualización y saber cómo pueden afectar a la duración de la actualización las configuraciones de cargas de trabajo, como PodDisruptionBudgets. Para obtener más información sobre los roles habituales y las tareas de ejemplo a los que hacemos referencia en el contenido, consulta Roles y tareas de usuario habituales de GKE. Google Cloud

Monitorizar el proceso de actualización del clúster

Para resolver los problemas de actualización de forma más eficaz, empieza por entender qué ha ocurrido durante el proceso de actualización. GKE ofrece varias herramientas que te permiten ver este proceso.

En la Google Cloud consola, el panel de control de actualización ofrece una vista de todo el proyecto con todas las actualizaciones de clúster en curso, una cronología de los eventos recientes y advertencias sobre posibles bloqueos, como exclusiones de mantenimiento activas o versiones obsoletas próximas. Para las comprobaciones automatizadas o de línea de comandos, puedes usar el comando gcloud container operations list para obtener el estado de operaciones de actualización específicas. Para obtener más información, consulta Obtener visibilidad de las actualizaciones del clúster.

Para llevar a cabo una investigación más detallada, Cloud Logging es tu principal fuente de información. GKE registra información detallada sobre los procesos de actualización del plano de control y del grupo de nodos en Cloud Logging. Esto incluye registros de auditoría de alto nivel que monitorizan las principales operaciones de actualización, así como registros más detallados, como los eventos de Kubernetes y los registros de los componentes de los nodos, que pueden mostrarte más información sobre errores específicos.

En las siguientes secciones se explica cómo consultar estos registros con el Explorador de registros o con gcloud CLI. Para obtener más información, consulta Comprobar los registros de actualización.

Identificar la operación de actualización con registros de auditoría

Si no sabes qué operación de actualización ha fallado, puedes usar los registros de auditoría de GKE. Los registros de auditoría monitorizan las acciones administrativas y proporcionan un registro oficial de cuándo se inició una actualización y cuál fue su estado final. Usa las siguientes consultas en el Explorador de registros para encontrar la operación pertinente.

Tipo de evento Consulta del registro
Actualización automática del plano de control 
resource.type="gke_cluster"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

Sustituye CLUSTER_NAME por el nombre del clúster que quieras investigar.

Esta consulta muestra la versión del plano de control de destino y la versión anterior del plano de control.
Actualización manual del plano de control 
resource.type="gke_cluster"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

 
Actualización automática de grupos de nodos (solo versión de destino) 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

Sustituye NODEPOOL_NAME por el nombre del grupo de nodos que pertenece al clúster.
Actualización manual de grupos de nodos 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.v1.ClusterManager.UpdateNodePool"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

Para encontrar la versión anterior del grupo de nodos, consulta los registros de la API de Kubernetes:

resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.methodName="nodes.patch"

Buscar mensajes de error detallados en los registros de GKE

Una vez que el registro de auditoría te muestre qué operación ha fallado y cuándo, puedes buscar mensajes de error más detallados de los componentes de GKE aproximadamente a la misma hora. Estos registros pueden contener los motivos específicos por los que no se ha podido realizar la actualización, como un objeto PodDisruptionBudget mal configurado.

Por ejemplo, después de encontrar una operación UPGRADE_NODES fallida en los registros de auditoría, puedes usar su marca de tiempo para acotar la búsqueda. En Explorador de registros, introduce la siguiente consulta y, a continuación, usa el selector de intervalo de tiempo para centrarte en el momento en el que se produjo el fallo:

resource.type="k8s_node"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.node_name="NODE_NAME"
severity=ERROR

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre de tu clúster.
  • NODE_NAME: el nombre del nodo del clúster cuyos errores quieres comprobar.

Usar la CLI de gcloud para ver los eventos de actualización

Además del Explorador de registros, puedes usar comandos de la CLI de gcloud para revisar los eventos de actualización.

Para buscar actualizaciones del plano de control, ejecuta el siguiente comando:

gcloud container operations list --filter="TYPE=UPGRADE_MASTER"

El resultado debería ser similar al siguiente:

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_MASTER
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

Esta salida incluye los siguientes valores:

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

Para buscar actualizaciones de grupos de nodos, ejecuta el siguiente comando:

gcloud container operations list --filter="TYPE=UPGRADE_NODES"

El resultado debería ser similar al siguiente:

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_NODES
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

Ejemplo: Usar registros para solucionar problemas de actualizaciones del plano de control

En el siguiente ejemplo se muestra cómo usar los registros para solucionar problemas con una actualización del plano de control que no se ha completado correctamente:

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

    Ir a Explorador de registros

  2. En el panel de consultas, filtra los registros de actualización del plano de control introduciendo la siguiente consulta:

    resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

    Sustituye CLUSTER_NAME por el nombre del clúster que quieras investigar.

  3. Haz clic en Realizar una consulta.

  4. Revisa el resultado del registro para obtener la siguiente información:

  5. Comprueba que la actualización se haya iniciado: busca eventos recientes UPGRADE_MASTER en el momento en que iniciaste la actualización. La presencia de estos eventos confirma que tú o GKE habéis activado el proceso de actualización.

    • Verifica las versiones: comprueba los siguientes campos para confirmar las versiones anterior y de destino:

      • protoPayload.metadata.previousMasterVersion: muestra la versión del plano de control antes de la actualización.

      • protoPayload.metadata.currentMasterVersion: muestra la versión a la que GKE ha intentado actualizar el plano de control.

        Por ejemplo, si querías actualizar a la versión 1.30.1-gke.1234, pero por error especificaste 1.30.2-gke.4321 (una versión más reciente y potencialmente incompatible con tus cargas de trabajo), al revisar estos dos campos se destacaría la discrepancia. Si el campo currentMasterVersion sigue mostrando la versión anterior después de un periodo prolongado, significa que la actualización no ha aplicado la nueva versión.

    • Busca errores: comprueba si hay eventos UPGRADE_MASTER repetidos u otros mensajes de error. Si el registro de operaciones se detiene sin indicar que se ha completado o que ha fallado, significa que hay un problema.

Una vez que hayas identificado un error o un comportamiento específico en los registros, puedes usar esa información para encontrar la solución adecuada en esta guía.

Solucionar problemas de actualizaciones de grupos de nodos que tardan más de lo habitual

Si la actualización de tu grupo de nodos tarda más de lo previsto, prueba las siguientes soluciones:

  1. Comprueba el valor de terminationGracePeriodSeconds en el manifiesto de tus pods. Este valor define el tiempo máximo que espera Kubernetes para que un pod se cierre correctamente. Un valor alto (por ejemplo, unos minutos) puede prolongar significativamente la duración de las actualizaciones, ya que Kubernetes espera el periodo completo de cada pod. Si este retraso está causando problemas, considere la posibilidad de reducir el valor.

  2. Comprueba tus objetos PodDisruptionBudget. Cuando se está drenando un nodo, GKE espera como máximo una hora por nodo para desalojar correctamente sus cargas de trabajo. Si el objeto PodDisruptionBudget es demasiado restrictivo, puede impedir que se complete la expulsión gradual. En este caso, GKE utiliza todo el periodo de gracia de una hora para intentar vaciar el nodo antes de que se agote el tiempo y se fuerce la actualización. Este retraso, cuando se repite en varios nodos, es una causa habitual de una actualización general lenta del clúster. Para confirmar si un PodDisruptionBudget objeto restrictivo es la causa de la lentitud de las actualizaciones, utiliza el Explorador de registros:

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

      Ir a Explorador de registros

    2. En el panel de consultas, introduce la siguiente consulta:

      resource.type=("gke_cluster" OR "k8s_cluster")
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.response.message="Cannot evict pod as it would violate the pod's disruption budget."
log_id("cloudaudit.googleapis.com/activity")

    3. Haz clic en Realizar una consulta.

    4. Revisa el resultado del registro. Si el objeto PodDisruptionBudget es la causa del problema, el resultado será similar al siguiente:

      resourceName: "core/v1/namespaces/istio-system/pods/POD_NAME/eviction"

response: {
  @type: "core.k8s.io/v1.Status"
  apiVersion: "v1"
  code: 429
  details: {
  causes: [
    0: {
    message: "The disruption budget istio-egressgateway needs 1 healthy pods and has 1 currently"
    reason: "DisruptionBudget"
    }
  ]
  }
  kind: "Status"
  message: "Cannot evict pod as it would violate the pod's disruption budget."
  metadata: {
  }
  reason: "TooManyRequests"
  status: "Failure"
}

    5. Después de confirmar que un objeto PodDisruptionBudget es la causa, enumera todos los objetos PodDisruptionBudget y asegúrate de que los ajustes sean los adecuados:

      kubectl get pdb --all-namespaces

      El resultado debería ser similar al siguiente:

      NAMESPACE        NAME          MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       3               0                 1                     12d

      En este ejemplo, el PodDisruptionBudget llamado one_pdb requiere un mínimo de tres pods disponibles. Como desalojar un pod durante la actualización dejaría solo dos pods disponibles, la acción infringe el presupuesto y provoca que la actualización se detenga.

      Si tu objeto PodDisruptionBudget funciona como quieres, no tienes que hacer nada. Si no es así, plantéate reducir los ajustes de PodDisruptionBudget durante la ventana de actualización.

  3. Comprueba las afinidades de los nodos. Las reglas restrictivas pueden ralentizar las actualizaciones, ya que impiden que los pods se vuelvan a programar en los nodos disponibles si estos no coinciden con las etiquetas necesarias. Este problema es especialmente grave durante las actualizaciones de picos de demanda, ya que las afinidades de los nodos pueden limitar el número de nodos que se pueden actualizar simultáneamente si los nodos con las etiquetas correctas no tienen suficiente capacidad de clúster para alojar los nuevos pods.

  4. Comprueba si usas la estrategia de actualización de corta duración. GKE usa la estrategia de actualización de corta duración para los nodos de inicio flexible y para los nodos que solo usan el aprovisionamiento en cola en clústeres que ejecutan la versión 1.32.2-gke.1652000 de GKE o una posterior. Si usas esta estrategia de actualización, la operación puede tardar hasta siete días.

  5. Comprueba si usas pods de duración ampliada (disponibles en clústeres de Autopilot). Durante una actualización, GKE debe vaciar todos los pods de un nodo para que se pueda completar el proceso. Sin embargo, durante una actualización iniciada por GKE, GKE no expulsa los pods de larga duración hasta siete días. Esta protección evita que el nodo se agote. GKE fuerza la finalización del pod solo después de que finalice este periodo, y este retraso significativo de varios días para un solo nodo puede retrasar más actualizaciones de nodos en el clúster de Autopilot.

  6. Los volúmenes persistentes adjuntos pueden provocar que el proceso de actualización tarde más de lo habitual, debido al tiempo que se tarda en gestionar el ciclo de vida de estos volúmenes.

  7. Consulta el estado de la actualización automática del clúster. Si el motivo es SYSTEM_CONFIG, las actualizaciones automáticas se pausan temporalmente por motivos técnicos o empresariales. Si ves este motivo, te recomendamos que no realices una actualización manual a menos que sea necesario.

Solucionar problemas de actualizaciones incompletas de grupos de nodos

En ocasiones, GKE no puede completar una actualización de un grupo de nodos, por lo que el grupo de nodos se actualiza parcialmente. Hay varios motivos por los que las actualizaciones pueden estar incompletas:

  • La actualización se ha cancelado manualmente.
  • La actualización ha fallado debido a un problema, como que los nodos nuevos no se hayan podido registrar, que se hayan agotado las direcciones IP o que no haya suficientes cuotas de recursos.
  • GKE ha pausado la actualización. Esta pausa puede producirse, por ejemplo, para evitar una actualización a una versión con problemas conocidos o durante determinados periodos de mantenimiento iniciados por Google.
  • Si usas las actualizaciones automáticas, una ventana de mantenimiento ha finalizado antes de que se pudiera completar la actualización. También puede que haya empezado un periodo de exclusión de mantenimiento antes de que se pudiera completar la actualización. Para obtener más información, consulta Ventana de mantenimiento que impide que se complete la actualización de un nodo.

Cuando un grupo de nodos se actualiza parcialmente, los nodos se ejecutan en diferentes versiones. Para resolver este problema y verificar que todos los nodos del grupo de nodos ejecutan la misma versión, puedes reanudar la actualización o revertir la actualización.

Sin embargo, las estrategias de actualizaciones con picos de uso y actualizaciones azul-verde interactúan de forma diferente con las ventanas de mantenimiento:

  • Actualizaciones con compensación: la operación de actualización se pausa si se prolonga más allá de la ventana de mantenimiento. La actualización se reanudará automáticamente durante la próxima ventana de mantenimiento programada.
  • Actualizaciones azul-verde: la operación de actualización continúa hasta que se completa, aunque supere el periodo de mantenimiento. Las actualizaciones azul-verde ofrecen un control granular sobre el ritmo de las actualizaciones con funciones como los tiempos de espera de los lotes y los grupos de nodos, y el grupo de nodos adicional ayuda a garantizar que las cargas de trabajo sigan operativas.

Solucionar problemas inesperados con la actualización automática

A veces, las actualizaciones automáticas de clústeres no se realizan como cabría esperar. En las siguientes secciones se explica cómo solucionar estos problemas:

No se pueden actualizar los clústeres cuando la actualización automática de nodos está habilitada

Si no has inhabilitado la actualización automática de nodos, pero no se produce ninguna actualización, prueba las siguientes soluciones:

  1. Si usas un canal de lanzamiento, comprueba que las actualizaciones automáticas de los nodos no estén bloqueadas. En el caso de los clústeres registrados en un canal de lanzamiento, maintenancePolicy es la forma principal de controlar las actualizaciones automáticas. Puede impedir que se inicie una actualización o interrumpir una que ya esté en curso. Una exclusión de mantenimiento activa puede bloquear una actualización por completo y el momento de una ventana de mantenimiento puede provocar una interrupción. Revisa tu maintenancePolicy para determinar si alguno de estos ajustes es la causa:

    gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster del grupo de nodos que se va a describir.
    • PROJECT_ID: el ID de proyecto del clúster.
    • LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.

    El resultado debería ser similar al siguiente:

    …
maintenancePolicy:
  maintenanceExclusions:
  - exclusionName: critical-event-q4-2025
    startTime: '2025-12-20T00:00:00Z'
    endTime: '2026-01-05T00:00:00Z'
    scope:
      noUpgrades: true # This exclusion blocks all upgrades
  window:
    dailyMaintenanceWindow:
      startTime: 03:00 # Daily window at 03:00 UTC
…

    En el resultado, revise la sección maintenancePolicy para comprobar si se cumplen las dos condiciones siguientes:

    • Para ver si se ha bloqueado una actualización, busca un maintenanceExclusion activo con un ámbito NO_MINOR_OR_NODE_UPGRADES. Este ajuste suele impedir que GKE inicie una nueva actualización.
    • Para comprobar si se ha interrumpido una actualización, consulta la programación de tu dailyMaintenanceWindow o maintenanceExclusions. Si una actualización se prolonga más allá del periodo programado, GKE la pausará, lo que dará lugar a una actualización parcial. Para obtener más información sobre las actualizaciones parciales, consulta la sección Solucionar problemas de actualizaciones incompletas.

    Para solucionar estos problemas, puedes esperar a que finalice una exclusión, eliminarla o ajustar tus ventanas de mantenimiento para que haya más tiempo para completar las actualizaciones.

  2. Si no usas un canal de lanzamiento, comprueba que la actualización automática siga habilitada en el grupo de nodos:

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION

    Sustituye NODE_POOL_NAME por el nombre del grupo de nodos que quieras describir.

    Si las actualizaciones automáticas de grupos de nodos están habilitadas en este grupo de nodos, el resultado del campo autoUpgrade será el siguiente:

    management:
  autoUpgrade: true

    Si autoUpgrade tiene el valor false o el campo no está presente, habilita las actualizaciones automáticas.

  3. Es posible que la actualización no se haya implementado en la región o zona en la que se encuentra tu clúster, aunque se haya mencionado en las notas de la versión. Las actualizaciones de GKE se implementan progresivamente a lo largo de varios días (normalmente, cuatro o más). Una vez que la actualización llegue a tu región o zona, solo se iniciará durante las ventanas de mantenimiento aprobadas. Por ejemplo, una implementación puede llegar a la zona de tu clúster el primer día de la implementación, pero la siguiente ventana de mantenimiento del clúster no será hasta el séptimo día. En este caso, GKE no actualizará el clúster hasta el séptimo día. Para obtener más información, consulta la programación de lanzamientos de GKE.

Los clústeres se actualizan automáticamente cuando la actualización automática no está habilitada

Para mantener la fiabilidad, la disponibilidad, la seguridad y el rendimiento de tu entorno de GKE, GKE puede actualizar automáticamente tus clústeres, aunque no uses las actualizaciones automáticas.

GKE puede omitir tus ventanas de mantenimiento, exclusiones o actualizaciones automáticas de grupos de nodos inhabilitadas para realizar las actualizaciones necesarias por varios motivos críticos, como los siguientes:

  • Clústeres cuyo plano de control ejecuta una versión de GKE que ha alcanzado la fecha de finalización del periodo de asistencia. Para confirmar que tu clúster se acerca a la fecha de finalización del periodo de asistencia, consulta el calendario estimado de los canales de lanzamiento.
  • Nodos de un clúster que ejecutan una versión de GKE que ha llegado a su fecha de finalización de la asistencia.
  • Clústeres que están en estado de ejecución, pero no muestran actividad durante un periodo prolongado. Por ejemplo, GKE puede considerar que un clúster está abandonado si no tiene llamadas a la API, tráfico de red ni uso activo de subredes.
  • Clústeres que muestran una inestabilidad persistente y que cambian repetidamente entre estados operativos. Por ejemplo, estados que pasan de estar en funcionamiento a degradado, en reparación o suspendido y vuelven a estar en funcionamiento sin que se haya resuelto el problema.

Si observas una actualización automática inesperada y te preocupa el efecto que pueda tener en tu clúster, ponte en contacto con el equipo de Asistencia de Google Cloud para obtener ayuda.

Solucionar problemas de actualización

Cuando se produce un error en la actualización, GKE genera mensajes de error. En las siguientes secciones se explican las causas y las soluciones de los siguientes errores:

Error: kube-apiserver no está en buen estado

A veces, puede que veas el siguiente mensaje de error al iniciar una actualización manual del plano de control de la versión de GKE de tu clúster:

FAILED: All cluster resources were brought up, but: component
"KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful"
is unhealthy.

Este mensaje aparece en gcloud CLI y en las entradas de registro de los tipos de recursos gke_cluster y gke_nodepool.

Este problema se produce cuando algunos webhooks de admisión implementados por el usuario impiden que los componentes del sistema creen los roles RBAC permisivos necesarios para funcionar correctamente.

Durante una actualización del plano de control, GKE vuelve a crear el componente del servidor de la API de Kubernetes (kube-apiserver). Si un webhook bloquea el rol RBAC del componente del servidor de la API, el servidor de la API no se iniciará y la actualización del clúster no se completará. Aunque un webhook funcione correctamente, puede provocar que la actualización del clúster falle porque el plano de control recién creado no pueda acceder al webhook.

Kubernetes concilia automáticamente los roles RBAC del sistema predeterminados con las políticas predeterminadas de la última versión secundaria. Las políticas predeterminadas de los roles del sistema a veces cambian en las nuevas versiones de Kubernetes.

Para llevar a cabo esta conciliación, GKE crea o actualiza los ClusterRoles y ClusterRoleBindings en el clúster. Si tienes un webhook que intercepta y rechaza las solicitudes de creación o actualización debido al ámbito de los permisos que usan las políticas de RBAC predeterminadas, el servidor de la API no puede funcionar en la nueva versión secundaria.

Para identificar el webhook que falla, consulta los registros de auditoría de GKE para ver las llamadas de control de acceso basado en roles con la siguiente información:

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

En este resultado, RBAC_RULE es el nombre completo del rol de RBAC, como rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.

El nombre del webhook que ha fallado se muestra en el registro con el siguiente formato:

admission webhook WEBHOOK_NAME denied the request

Para solucionar este problema, prueba las siguientes soluciones:

  1. Revisa tus ClusterRoles para asegurarte de que no sean demasiado restrictivos. Tus políticas no deben bloquear las solicitudes de GKE para crear o actualizar los ClusterRoles con el prefijo system: predeterminado.
  2. Ajusta tu webhook para que no intercepte las solicitudes de creación y actualización de roles RBAC del sistema.
  3. Inhabilita el webhook.

Error: DeployPatch failed

A veces, la operación de actualización del clúster falla y se muestra el siguiente error:

DeployPatch failed

Este error puede producirse si el plano de control de Kubernetes no funciona correctamente durante más de 20 minutos.

Este error suele ser temporal, ya que el plano de control vuelve a intentar la operación hasta que se completa correctamente. Si la actualización sigue fallando y aparece este error, ponte en contacto con Cloud Customer Care.

Solucionar problemas después de completar una actualización

Si detectas un comportamiento inesperado después de completar la actualización, en las siguientes secciones se ofrecen instrucciones para solucionar los problemas habituales:

Comportamiento inesperado debido a cambios incompatibles

Si la actualización se ha completado correctamente, pero observas un comportamiento inesperado después de la actualización, consulta las notas de la versión de GKE para obtener información sobre errores y cambios incompatibles relacionados con la versión a la que se ha actualizado el clúster.

Cargas de trabajo desalojadas tras actualizar un clúster estándar

Es posible que tus cargas de trabajo corran el riesgo de expulsión después de actualizar un clúster si se cumplen todas las condiciones siguientes:

  • Las cargas de trabajo del sistema requieren más espacio cuando el plano de control del clúster ejecuta la nueva versión de GKE.
  • Tus nodos no tienen suficientes recursos para ejecutar las nuevas cargas de trabajo del sistema y las cargas de trabajo actuales.
  • La herramienta de adaptación dinámica de clústeres está inhabilitada en el clúster.

Para solucionar este problema, prueba las siguientes soluciones:

  1. Habilita el autoescalado en los grupos de nodos que ya tengas.
  2. Habilita el aprovisionamiento automático de nodos.
  3. Crea un grupo de nodos.
  4. Escalar verticalmente un grupo de nodos.

Los pods se quedan en estado Pending después de configurar Node Allocatable

Si has configurado Node Allocatable, a veces, al actualizar la versión de un nodo, los pods que tenían el estado Running se quedan en el estado Pending. Este cambio suele producirse porque el nodo actualizado consume recursos del sistema ligeramente diferentes o porque los pods que se han reprogramado ahora deben ajustarse a los límites asignables de los nodos nuevos o modificados, posiblemente en condiciones más estrictas.

Si tus Pods tienen el estado Pending después de una actualización, prueba las siguientes soluciones:

  1. Comprueba que las solicitudes de CPU y memoria de tus pods no superen su uso máximo. Como GKE reserva CPU y memoria para la sobrecarga, los pods no pueden solicitar estos recursos. Los pods que solicitan más CPU o memoria de la que usan impiden que otros pods soliciten estos recursos y pueden provocar que el clúster no se utilice de forma óptima. Para obtener más información, consulta el artículo Cómo se programan los pods con solicitudes de recursos de la documentación de Kubernetes.
  2. Te recomendamos que aumentes el tamaño de tu clúster.
  3. Para verificar si la actualización es la causa de este problema, revierte la actualización bajando la versión de tus grupos de nodos.
  4. Configura tu clúster para enviar métricas del programador de Kubernetes a Cloud Monitoring y consulta las métricas del programador. Si monitorizas estas métricas, puedes determinar si hay suficientes recursos para que se ejecuten los pods.

Solucionar problemas de versión y compatibilidad

Para mantener la estabilidad y el rendimiento, es fundamental que todos los componentes de tu clúster tengan versiones compatibles. En las siguientes secciones se ofrecen directrices sobre cómo identificar y resolver problemas de versiones y compatibilidad que pueden afectar al proceso de actualización.

Comprobar si hay incompatibilidad entre la versión del plano de control y la del nodo

Si hay una diferencia de versión entre el plano de control y los nodos, el clúster puede volverse inestable. La política de diferencia de versiones de GKE indica que un plano de control solo es compatible con nodos que tengan hasta dos versiones secundarias anteriores. Por ejemplo, un plano de control 1.19 funciona con nodos 1.19, 1.18 y 1.17.

Si tus nodos quedan fuera de este periodo admitido, corres el riesgo de tener problemas de compatibilidad críticos. Estos problemas suelen estar relacionados con las APIs. Por ejemplo, una carga de trabajo de un nodo antiguo puede usar una versión de la API que se haya retirado o haya quedado obsoleta en el plano de control más reciente. Esta incompatibilidad también puede provocar fallos más graves, como una ruta de red dañada que impida que los nodos se registren en el clúster si una carga de trabajo incompatible interrumpe la comunicación.

Periódicamente, el equipo de GKE realiza actualizaciones del plano de control del clúster en tu nombre. Los planos de control se actualizan a versiones estables más recientes de Kubernetes. Para que tus nodos sigan siendo compatibles con el plano de control actualizado, también deben mantenerse al día. De forma predeterminada, GKE gestiona esta actualización porque los nodos de un clúster tienen habilitada la actualización automática, y te recomendamos que no la inhabilites. Si la actualización automática está inhabilitada en los nodos de un clúster y no los actualizas manualmente, el plano de control acabará siendo incompatible con los nodos.

Para confirmar si las versiones del plano de control y de los nodos son incompatibles, comprueba qué versión de Kubernetes están ejecutando el plano de control y los grupos de nodos de tu clúster:

gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre del clúster del grupo de nodos que se va a describir.
  • PROJECT_ID: el ID de proyecto del clúster.
  • LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.

El resultado debería ser similar al siguiente:

…
currentMasterVersion: 1.32.3-gke.1785003
…
currentNodeVersion: 1.26.15-gke.1090000
…

En este ejemplo, la versión del plano de control y la versión del grupo de nodos son incompatibles.

Para resolver este problema, actualiza manualmente la versión del grupo de nodos a una versión compatible con el plano de control.

Si te preocupa que el proceso de actualización provoque interrupciones en las cargas de trabajo que se ejecutan en los nodos afectados, sigue estos pasos para migrar tus cargas de trabajo a un nuevo grupo de nodos:

  1. Crea un grupo de nodos con una versión compatible.
  2. Aísla los nodos del grupo de nodos.
  3. Opcional: actualiza las cargas de trabajo que se ejecutan en el grupo de nodos para añadir un selector de nodos para la etiqueta cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME. Sustituye NEW_NODE_POOL_NAME por el nombre del nuevo grupo de nodos. Esta acción asegura que GKE coloque esas cargas de trabajo en los nodos del nuevo grupo de nodos.
  4. Drena el grupo de nodos.
  5. Comprueba que las cargas de trabajo se ejecuten correctamente en el nuevo grupo de nodos. Si es así, puedes eliminar el grupo de nodos antiguo. Si observas interrupciones en las cargas de trabajo, reprograma las cargas de trabajo en los nodos actuales. Para ello, quita el aislamiento de los nodos del grupo de nodos actual y vacía los nodos nuevos.

El uso de CPU del nodo es más alto de lo previsto

Puede que se produzca un problema en el que algunos nodos usen más CPU de la esperada de los pods en ejecución.

Este problema puede producirse si usas actualizaciones manuales y tus clústeres o nodos no se han actualizado para ejecutar una versión compatible. Consulta las notas de la versión para asegurarte de que las versiones que usas estén disponibles y sean compatibles.

Siguientes pasos