Soluciona problemas de los clústeres de Autopilot

En esta página, se muestra cómo resolver problemas con los clústeres de Autopilot de Google Kubernetes Engine (GKE).

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Problemas de clústeres

No se puede crear un clúster: 0 nodos registrados

El siguiente problema ocurre cuando intentas crear un clúster de Autopilot con una cuenta de servicio de IAM que está inhabilitada o no tiene los permisos necesarios. La creación de un clúster falla con el siguiente mensaje de error:

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

Para solucionar el problema, haz lo siguiente:

  1. Verifica si la cuenta de servicio predeterminada de Compute Engine o la cuenta de servicio de IAM personalizada que deseas usar está inhabilitada:

    gcloud iam service-accounts describe SERVICE_ACCOUNT

    Reemplaza SERVICE_ACCOUNT por la dirección de correo electrónico de la cuenta de servicio, como my-iam-account@my-first-project.iam.gserviceaccount.com.

    Si la cuenta de servicio está inhabilitada, el resultado es similar al siguiente:

    disabled: true
displayName: my-service-account
email: my-service-account@my-project.iam.gserviceaccount.com
...

  2. Si la cuenta de servicio está inhabilitada, habilítala:

    gcloud iam service-accounts enable SERVICE_ACCOUNT

Si la cuenta de servicio está habilitada y el error persiste, otórgale los permisos mínimos necesarios para GKE:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT" \
    --role roles/container.nodeServiceAccount

Espacio de nombres atascado en el estado de finalización cuando el clúster tiene 0 nodos

El siguiente problema ocurre cuando borras un espacio de nombres en un clúster después de que se reduce a cero nodos. El componente metrics-server no puede aceptar la solicitud de eliminación del espacio de nombres porque el componente no tiene réplicas.

Para diagnosticar este problema, ejecuta el siguiente comando:

kubectl describe ns/NAMESPACE_NAME

Reemplaza NAMESPACE_NAME por el nombre del espacio de nombres.

Esta es la salida:

Discovery failed for some groups, 1 failing: unable to retrieve the complete
list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to
handle the request

A fin de resolver este problema, escala verticalmente cualquier carga de trabajo para activar GKE y crear un nodo nuevo. Cuando el nodo está listo, la solicitud de eliminación del espacio de nombres se completa de forma automática. Después de que GKE borre el espacio de nombres, reduce la escala de la carga de trabajo.

Problemas de escalamiento

Error de escalamiento vertical del nodo: el Pod está en riesgo de no estar programado

El siguiente problema se produce cuando el registro de puertos en serie está inhabilitado en tu proyecto de Google Cloud. Los clústeres de Autopilot de GKE requieren registros de puertos en serie para depurar de forma eficaz los problemas de los nodos. Si el registro de puertos en serie está inhabilitado, Autopilot no puede aprovisionar nodos para ejecutar tus cargas de trabajo.

El mensaje de error en el registro de eventos de Kubernetes es similar al siguiente:

LAST SEEN   TYPE      REASON          OBJECT                          MESSAGE
12s         Warning   FailedScaleUp   pod/pod-test-5b97f7c978-h9lvl   Node scale up in zones associated with this pod failed: Internal error. Pod is at risk of not being scheduled

El registro de puertos en serie puede inhabilitarse a nivel de la organización a través de una política de la organización que aplica la restricción compute.disableSerialPortLogging. El registro de los puertos en serie también se podría inhabilitar a nivel del proyecto o de la máquina virtual (VM).

Para solucionar este problema, haz lo siguiente:

  1. Pídele al administrador de políticas de la organización de Google Cloud que quite la restricción compute.disableSerialPortLogging del proyecto con tu clúster de Autopilot.
  2. Si no tienes una política de la organización que aplique esta restricción, intenta habilitar el registro de puertos en serie en los metadatos del proyecto. Para esta acción, se requiere el permiso de IAM compute.projects.setCommonInstanceMetadata.

Error de escalamiento vertical del nodo: GCE fuera de los recursos

El siguiente problema se produce cuando tus cargas de trabajo solicitan más recursos de los que están disponibles para usar en esa región o zona de Compute Engine. Es posible que los Pods permanezcan en el estado Pending.

  • Verifica los eventos de tu Pod:

    kubectl get events --for='POD_NAME' --types=Warning

    Reemplaza RESOURCE_NAME por el nombre del recurso de Kubernetes pendiente. Por ejemplo, pod/example-pod.

    El resultado es similar al siguiente:

    LAST SEEN         TYPE            REASON                  OBJECT                   Message
19m               Warning         FailedScheduling        pod/example-pod          gke.io/optimize-utilization-scheduler  0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
14m               Warning         FailedScheduling        pod/example-pod          gke.io/optimize-utilization-scheduler  0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
12m (x2 over 18m) Warning         FailedScaleUp           cluster-autoscaler       Node scale up in zones us-central1-f associated with this pod failed: GCE out of resources. Pod is at risk of not being scheduled.
34s (x3 over 17m) Warning         FailedScaleUp           cluster-autoscaler       Node scale up in zones us-central1-b associated with this pod failed: GCE out of resources. Pod is at risk of not being scheduled.

Para resolver este problema, realiza las siguientes acciones:

  • Implementa el Pod en una región o zona diferente. Si el Pod tiene una restricción zonal, como un selector de topología, quítala, si puedes. Para obtener instrucciones, consulta Coloca Pods de GKE en zonas específicas.
  • Crea un clúster en una región diferente y vuelve a intentar la implementación.
  • Intenta usar una clase de procesamiento diferente. Las clases de procesamiento respaldadas por tipos de máquinas de Compute Engine más pequeños tienen más probabilidades de tener recursos disponibles. Por ejemplo, el tipo de máquina predeterminado para Autopilot tiene la disponibilidad más alta. Para obtener una lista de las clases de procesamiento y los tipos de máquina correspondientes, consulta Cuándo usar clases de procesamiento específicas.
  • Si ejecutas cargas de trabajo de GPU, es posible que la GPU solicitada no esté disponible en la ubicación de tu nodo. Intenta implementar tu carga de trabajo en una ubicación diferente o solicitar un tipo de GPU diferente.

Para evitar problemas de escalamiento vertical causados por la disponibilidad de recursos en el futuro, considera los siguientes enfoques:

Los nodos no escalan verticalmente: se excedieron los recursos zonales de Pod

El siguiente problema ocurre cuando Autopilot no aprovisiona nodos nuevos para un Pod en una zona específica porque un nodo nuevo infringiría los límites de recursos.

El mensaje de error en los registros es similar al siguiente:

    "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              ...

Este error se refiere a un evento noScaleUp, en el que el aprovisionamiento automático de nodos no aprovisionó ningún grupo de nodos para el Pod en la zona.

Si encuentras este error, confirma lo siguiente:

Problemas de cargas de trabajo

Pods atascados en el estado Pendiente

Un Pod puede detenerse en el estado Pending si seleccionas un nodo específico para que use tu Pod, pero la suma de solicitudes de recursos en el Pod y en DaemonSets que deben ejecutarse en el nodo excede la capacidad máxima asignable de del nodo. Esto puede provocar que el Pod obtenga un estado Pending y permanezca no programado.

Para evitar este problema, evalúa los tamaños de las cargas de trabajo implementadas a fin de asegurarte de que se encuentren dentro de las solicitudes de recursos máximas admitidas para Autopilot.

También puedes intentar programar tus DaemonSets antes de programar tus Pods de carga de trabajo normales.

Rendimiento de cargas de trabajo constantemente poco confiable en un nodo específico

En la versión 1.24 y posteriores de GKE, si tus cargas de trabajo en un nodo específico experimentan interrupciones, fallas o comportamientos poco confiables similares de manera constante, puedes informar a GKE sobre el nodo problemático mediante el siguiente comando:

kubectl drain NODE_NAME --ignore-daemonsets

Reemplaza NODE_NAME con el nombre del nodo problemático. Para encontrar el nombre del nodo, ejecuta kubectl get nodes.

GKE hace lo siguiente:

  • Expulsa cargas de trabajo existentes del nodo y deja de programar cargas de trabajo en ese nodo.
  • Vuelve a crear de forma automática las cargas de trabajo expulsadas que administra un controlador, como un objeto Deployment o un StatefulSet, en otros nodos.
  • Finaliza cualquier carga de trabajo que quede en el nodo y repara o vuelve a crear el nodo con el tiempo.
  • Si usas Autopilot, GKE se cierra y reemplaza el nodo de inmediato y, también, ignora cualquier PodDisruptionBudgets configurado.

Los Pods tardan más de lo esperado en programarse en clústeres vacíos.

Este evento ocurre cuando implementas una carga de trabajo en un clúster de Autopilot que no tiene otras cargas de trabajo. Los clústeres de Autopilot comienzan con cero nodos utilizables y escalan a cero nodos si el clúster está vacío para evitar tener recursos de procesamiento sin usar en el clúster. Implementar una carga de trabajo en un clúster que tiene cero nodos activa un evento de escalamiento vertical.

Si experimentas esto, Autopilot funciona según lo previsto y no es necesaria ninguna acción. Tu carga de trabajo se implementará como se espera después de que se inicien los nodos nuevos.

Verifica si tus Pods están esperando nodos nuevos:

  1. Describe tu Pod pendiente:

    kubectl describe pod POD_NAME

    Reemplaza POD_NAME por el nombre del Pod pendiente.

  2. Verifica la sección Events del resultado. Si el Pod espera nodos nuevos, el resultado es similar al siguiente:

    Events:
  Type     Reason            Age   From                                   Message
  ----     ------            ----  ----                                   -------
  Warning  FailedScheduling  11s   gke.io/optimize-utilization-scheduler  no nodes available to schedule pods
  Normal   TriggeredScaleUp  4s    cluster-autoscaler                     pod triggered scale-up: [{https://www.googleapis.com/compute/v1/projects/example-project/zones/example-zone/instanceGroups/gk3-example-cluster-pool-2-9293c6db-grp 0->1 (max: 1000)} {https://www.googleapis.com/compute/v1/projects/example-project/zones/example-zone/instanceGroups/gk3-example-cluster-pool-2-d99371e7-grp 0->1 (max: 1000)}]

    El evento TriggeredScaleUp muestra que tu clúster escala verticalmente de cero nodos a tantos nodos necesarios para ejecutar la carga de trabajo implementada.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.