Soluciona problemas de los clústeres de Autopilot

Los problemas con tus clústeres de Autopilot de Google Kubernetes Engine (GKE) pueden afectar la disponibilidad y la eficiencia operativa de tu aplicación. Estos problemas pueden interrumpir todo el ciclo de vida de tus aplicaciones, desde la implementación inicial hasta el ajuste de la escala bajo carga.

Usa esta página para diagnosticar y resolver problemas comunes específicos de los clústeres de Autopilot. Encuentra orientación para solucionar problemas de creación de clústeres que impiden el aprovisionamiento de tu clúster, problemas de escalamiento, como errores de out of resources, y problemas específicos de la carga de trabajo, como errores de almacenamiento efímero o Pods atascados en el estado Pending.

Esta información es importante para los desarrolladores de aplicaciones que deben asegurarse de que sus aplicaciones se implementen y ejecuten sin problemas, y para los administradores y operadores de plataformas que son responsables del estado general y la administración de recursos de los clústeres de Autopilot. 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 de usuario y tareas comunes de GKE.

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.defaultNodeServiceAccount

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 puerto en serie está inhabilitado en tu proyecto deGoogle 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 Google Cloud quequite la restricción compute.disableSerialPortLoggingen el 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

Las cargas de trabajo se atascan 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 Deployment 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: Es el nombre de la carga de trabajo atascada.

Si el Pod no se crea porque la solicitud de almacenamiento efímero supera el máximo, el resultado tendrá un aspecto 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 de modo que el almacenamiento efímero total solicitado por los contenedores de cargas de trabajo y por los contenedores que insertan 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.

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.

No se pueden programar los Pods del sistema en clústeres vacíos

Este evento ocurre cuando ninguna de tus cargas de trabajo se ejecuta en un clúster, lo que provoca que el clúster se reduzca a cero nodos. Los clústeres de Autopilot comienzan con cero nodos utilizables y se reducen a cero nodos si no ejecutas ninguna de tus cargas de trabajo en el clúster. Este comportamiento minimiza el desperdicio de recursos de procesamiento en el clúster.

Cuando un clúster se reduce a cero nodos, las cargas de trabajo del sistema de GKE no se programarán y permanecerán en el estado Pending. Este es el comportamiento esperado, y no es necesario que realices ninguna acción. La próxima vez que implementes una carga de trabajo en el clúster, GKE lo escalará verticalmente y los Pods del sistema pendientes se ejecutarán en esos nodos.

Para verificar si los Pods del sistema están pendientes debido a que el clúster está vacío, haz lo siguiente:

  1. Verifica si tu clúster tiene nodos:

    kubectl get nodes

    El resultado es el siguiente, lo que indica que el clúster no tiene nodos:

    No resources found

  2. Verifica el estado de los Pods del sistema:

    kubectl get pods --namespace=kube-system

    El resultado es similar a este:

    NAME                                                       READY   STATUS    RESTARTS   AGE
antrea-controller-horizontal-autoscaler-6d97f7cf7c-ngfd2   0/1     Pending   0          9d
egress-nat-controller-84bc985778-6jcwl                     0/1     Pending   0          9d
event-exporter-gke-5c5b457d58-7njv7                        0/2     Pending   0          3d5h
event-exporter-gke-6cd5c599c6-bn665                        0/2     Pending   0          9d
konnectivity-agent-694b68fb7f-gws8j                        0/2     Pending   0          3d5h
konnectivity-agent-7d659bf64d-lp4kt                        0/2     Pending   0          9d
konnectivity-agent-7d659bf64d-rkrw2                        0/2     Pending   0          9d
konnectivity-agent-autoscaler-5b6ff64fcd-wn7fw             0/1     Pending   0          9d
konnectivity-agent-autoscaler-cc5bd5684-tgtwp              0/1     Pending   0          3d5h
kube-dns-65ccc769cc-5q5q7                                  0/5     Pending   0          3d5h
kube-dns-7f7cdb9b75-qkq4l                                  0/5     Pending   0          9d
kube-dns-7f7cdb9b75-skrx4                                  0/5     Pending   0          9d
kube-dns-autoscaler-6ffdbff798-vhvkg                       0/1     Pending   0          9d
kube-dns-autoscaler-8b7698c76-mgcx8                        0/1     Pending   0          3d5h
l7-default-backend-87b58b54c-x5q7f                         0/1     Pending   0          9d
metrics-server-v1.31.0-769c5b4896-t5jjr                    0/1     Pending   0          9d

  3. Comprueba el motivo por el que los Pods del sistema tienen el estado Pending:

    kubectl describe pod --namespace=kube-system SYSTEM_POD_NAME

    Reemplaza SYSTEM_POD_NAME por el nombre de cualquier Pod del sistema del resultado del comando anterior.

    El resultado es similar a este:

    ...
Events:
Type     Reason            Age                       From               Message
----     ------            ----                      ----               -------
Warning  FailedScheduling  4m35s (x27935 over 3d5h)  default-scheduler  no nodes available to schedule pods
...

    En el resultado, el valor no nodes available to schedule pods en el campo Message para el evento FailedScheduling indica que el Pod del sistema no se programó porque el clúster está vacío.

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:
        # This section drops NET_RAW to mitigate security vulnerabilities
        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?