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 sin recursos

El siguiente problema se produce cuando tus cargas de trabajo solicitan más recursos de los que están disponibles para usarse 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 events --for='pod/POD_NAME' --types=Warning

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

    El resultado es similar a este:

    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 tu Pod tiene una restricción zonal, como un selector de topología, quita la restricción 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. Es más probable que las clases de procesamiento respaldadas por tipos de máquina más pequeños de Compute Engine tengan recursos disponibles. Por ejemplo, el tipo de máquina predeterminado para Autopilot tiene la mayor disponibilidad. 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 solicita un tipo diferente de GPU.

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

Cargas de trabajo atascadas con un error de almacenamiento efímero

GKE no creará Pods si tus solicitudes de almacenamiento efímero de Pods superan el máximo de Autopilot de 10 GiB en la versión 1.28.6-gke.1317000 de GKE y versiones posteriores.

Para diagnosticar este problema, describe el controlador de carga de trabajo, como la implementación o el trabajo:

kubectl describe CONTROLLER_TYPE/CONTROLLER_NAME

Reemplaza lo siguiente:

  • CONTROLLER_TYPE: El tipo de controlador de carga de trabajo, como replicaset o daemonset. Para obtener una lista de los tipos de controladores, consulta Administración de cargas de trabajo.
  • CONTROLLER_NAME: El nombre de la carga de trabajo atascada.

Si el Pod no se crea debido a que la solicitud de almacenamiento efímero excede el máximo, el resultado es similar al siguiente:

# lines omitted for clarity

Events:

{"[denied by autogke-pod-limit-constraints]":["Max ephemeral-storage requested by init containers for workload '' is higher than the Autopilot maximum of '10Gi'.","Total ephemeral-storage requested by containers for workload '' is higher than the Autopilot maximum of '10Gi'."]}

Para resolver este problema, actualiza tus solicitudes de almacenamiento efímero para que el almacenamiento efímero total solicitado por los contenedores de carga de trabajo y los contenedores que insertan los webhooks sea menor o igual que el máximo permitido. Para obtener más información sobre el máximo, consulta Solicitudes de recursos en Autopilot para la configuración de la carga 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.

Pods que se detuvieron durante la finalización o la creación

Un problema conocido hace que los Pods se detengan en ocasiones en uno de los siguientes estados:

  • Terminating
  • CreateContainerError

Este problema tiene una pequeña posibilidad de ocurrir cuando usas pods de alto rendimiento en entornos de GKE que cumplen con todas las condiciones siguientes:

  1. Tus nodos ejecutan versiones de GKE a partir de la 1.29.2-gke.1060000 hasta la 1.30.2-gke.1394000, no inclusive.
  2. Tu Pod usa una de las siguientes clases de procesamiento:
    • La clase de procesamiento de uso general predeterminada
    • La clase de procesamiento Balanced
    • La clase de procesamiento Scale-Out

Para mitigar este problema, actualiza tu plano de control a la versión 1.30.2-gke.1394000 o posterior de GKE. Los Pods que ya están atascados en el estado Terminating o en el estado CreateContainerError se implementarán de forma correcta después de que GKE vuelva a crear los Pods en los nodos que ejecutan una versión fija.

Cuando actualizas un clúster de Autopilot, GKE actualiza los nodos trabajadores para que coincidan con la versión del plano de control con el tiempo. Es necesario reiniciar el plano de control para habilitar los aumentos de actividad y debe ocurrir después de que todos los nodos ejecuten una versión compatible. El plano de control se reinicia de forma automática alrededor de una vez a la semana durante operaciones como el escalamiento, las actualizaciones o el mantenimiento.

Para activar el reinicio de un plano de control de forma manual, haz lo siguiente:

  1. Verifica si todos tus nodos ejecutan la versión 1.30.2-gke.1349000 o una posterior:

    kubectl get nodes

    El resultado es similar a este:

    NAME                                          STATUS   ROLES    AGE     VERSION
gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000

    Todos los nodos del resultado deben mostrar la versión requerida o una posterior.

  2. Inicia de forma manual una actualización del plano de control a la misma versión que el clúster ya usa. Para obtener instrucciones, consulta Actualiza el plano de control de forma manual.

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 los Pods esperan 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 como sean necesarios para ejecutar la carga de trabajo implementada.

El acceso a los nodos subyacentes está prohibido en un clúster de GKE Autopilot. Por lo tanto, es necesario ejecutar la utilidad tcpdump desde un Pod y, luego, copiarla con el comando kubectl cp. Si, por lo general, ejecutas la utilidad tcpdump desde un Pod en un clúster de GKE Autopilot, es posible que veas el siguiente error:

    tcpdump: eth0: You don't have permission to perform this capture on that device
    (socket: Operation not permitted)

Esto sucede porque GKE Autopilot aplica de forma predeterminada un contexto de seguridad a todos los Pods que disminuye la capacidad NET_RAW para mitigar posibles vulnerabilidades. Por ejemplo:

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: tcpdump
  name: tcpdump
spec:
  containers:
  - image: nginx
    name: nginx
    resources:
      limits:
        cpu: 500m
        ephemeral-storage: 1Gi
        memory: 2Gi
      requests:
        cpu: 500m
        ephemeral-storage: 1Gi
        memory: 2Gi
    securityContext:
      capabilities:
        drop:
        - NET_RAW

Como solución, si tu carga de trabajo requiere la capacidad NET_RAW, puedes volver a habilitarla:

  1. Agrega la capacidad NET_RAW a la sección securityContext de la especificación YAML de tu Pod:

    securityContext:
  capabilities:
    add:
    - NET_RAW

  2. Ejecuta tcpdump desde un Pod:

    tcpdump port 53 -w packetcap.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

  3. Usa el comando kubectl cp para copiarlo en tu máquina local para realizar un análisis más detallado:

    kubectl cp POD_NAME:/PATH_TO_FILE/FILE_NAME/PATH_TO_FILE/FILE_NAME

  4. Usa kubectl exec para ejecutar el comando tcpdump para realizar la captura de paquetes de red y redireccionar el resultado:

    kubectl exec -it POD_NAME -- bash -c "tcpdump port 53 -w -" > packet-new.pcap

¿Qué sigue?

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