Solucionar problemas de extracción de imágenes

Cuando los contenedores no se inician en Google Kubernetes Engine (GKE), es posible que veas estados de pods como ErrImagePull o ImagePullBackOff. La causa de estos estados suele ser un problema con el proceso de extracción de imágenes, en el que Kubernetes intenta recuperar la imagen del contenedor de un registro. Si se produce un error en este proceso, es posible que tus aplicaciones no se inicien o que se produzcan retrasos en la implementación.

En esta página se describen las causas más habituales de los errores de extracción de imágenes y cómo diagnosticarlas y resolverlas:

  • Configuración de autenticación: tu clúster no tiene los permisos necesarios para acceder al registro de imágenes de contenedor.
  • Conectividad de red: tu clúster no puede conectarse al registro debido a problemas de DNS, reglas de cortafuegos o falta de acceso a Internet en clústeres que usan aislamiento de red.
  • No se ha encontrado la imagen en el registro: el nombre o la etiqueta de la imagen especificados son incorrectos, la imagen se ha eliminado o el registro no está disponible.
  • Limitaciones de rendimiento: si el tamaño de la imagen es grande, la E/S del disco es lenta o la red está congestionada, las extracciones pueden ser lentas o agotar el tiempo de espera.
  • Arquitectura de imagen incompatible: la imagen se ha compilado para una arquitectura de CPU diferente a la de tu grupo de nodos de GKE.
  • Versiones de esquema incompatibles: puede que estés usando containerd 2.0 o una versión posterior con un esquema de Docker v1, que no es compatible.

Esta información es importante para los desarrolladores de aplicaciones que necesiten resolver errores de implementación verificando los nombres, las etiquetas y las arquitecturas de las imágenes en sus manifiestos. También ayuda a los administradores y operadores de la plataforma a depurar problemas a nivel de clúster, como configurar credenciales de extracción de imágenes para registros privados o corregir políticas de red que bloquean el acceso a un registro de imágenes. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido deTrusted Cloud by S3NS , consulta Roles y tareas de usuario habituales de GKE.

Si ya has visto un mensaje de evento específico, busca el mensaje en esta página y sigue los pasos para solucionar el problema que se indican. Si no has recibido ningún mensaje, sigue las instrucciones de las secciones que se indican a continuación en el orden en el que aparecen. Si el problema persiste, ponte en contacto con Cloud Customer Care.

Información sobre las extracciones de imágenes

Antes de empezar a solucionar problemas, es útil saber un poco más sobre el ciclo de vida de una imagen y dónde puedes alojarlas.

Ciclo de vida de las imágenes

Cuando creas un pod, kubelet recibe la definición del pod, que incluye la especificación de la imagen. Kubelet necesita esta imagen para poder ejecutar un contenedor basado en ella. Antes de extraer la imagen, el kubelet comprueba el tiempo de ejecución del contenedor para ver si la imagen está presente. El kubelet también comprueba la política de extracción de imágenes del pod. Si la imagen no está en la caché del entorno de ejecución del contenedor o si la política de extracción de imágenes lo requiere, kubelet indica al entorno de ejecución del contenedor (containerd) que extraiga la imagen especificada del registro. Si no se puede extraer una imagen, el contenedor del pod no se puede iniciar.

Una vez que se ha extraído la imagen correctamente, el tiempo de ejecución del contenedor la descomprime para crear un sistema de archivos base de solo lectura para el contenedor. El tiempo de ejecución del contenedor almacena esta imagen y la imagen permanece presente mientras los contenedores en ejecución hagan referencia a ella. Si ningún contenedor en ejecución hace referencia a una imagen, esta se podrá recoger como elemento no utilizado y kubelet la eliminará.

Opciones de alojamiento de imágenes

Te recomendamos que utilices una de las siguientes opciones para alojar tus imágenes:

  • Artifact Registry: Artifact Registry es el gestor de paquetes totalmente gestionado de Google. Artifact Registry se integra estrechamente con otros servicios y ofrece un control de acceso pormenorizado. Trusted Cloud by S3NSPara obtener más información, consulta el artículo Trabajar con imágenes de contenedor de la documentación de Artifact Registry.

  • Registro autohospedado: te ofrece más control, pero también requiere que gestiones el registro. Considera esta opción si tienes necesidades específicas de cumplimiento o seguridad que Artifact Registry no puede satisfacer.

Diagnosticar un error de extracción de imágenes

Para diagnosticar los fallos de extracción de imágenes, realiza las investigaciones que se detallan en las siguientes secciones:

  1. Consulta el estado y los eventos de los pods.
  2. Entender el significado de los estados.
  3. Usa los mensajes de eventos para encontrar la causa del error de extracción de imágenes.
  4. Ver los registros del explorador de registros.

Ver el estado y los eventos de los pods

Para ayudarte a verificar que no se ha podido extraer una imagen, GKE registra los siguientes estados de los pods:

  • ImagePullBackOff
  • ErrImagePull
  • ImageInspectError
  • InvalidImageName
  • RegistryUnavailable
  • SignatureValidationFailed

ImagePullBackOff y ErrImagePull son los estados más habituales.

Además de estos estados, los eventos de Kubernetes te ayudan a encontrar la causa de los errores de extracción de imágenes.

Para confirmar si se produce un error al extraer la imagen, comprueba los mensajes de estado y, a continuación, lee los mensajes de eventos seleccionando una de las siguientes opciones:

Consola

Este agente debe seguir estos pasos:

  1. En la Trusted Cloud consola, ve a la página Cargas de trabajo.

    Ir a Cargas de trabajo

  2. Selecciona la carga de trabajo que quieras investigar. Si no sabes qué carga de trabajo debes examinar, consulta la columna Estado. En esta columna se indica qué cargas de trabajo tienen problemas.

  3. En la página Detalles de la carga de trabajo, busque la sección Pods gestionados y haga clic en el nombre del pod cuyo estado indique que no se ha podido extraer la imagen.

  4. En la página Detalles del pod, haz clic en la pestaña Eventos.

  5. Consulte la información de la tabla. La columna Mensaje muestra los eventos de Kubernetes, que ofrecen más información sobre los errores de extracción de imágenes. En la columna Motivo se indica el estado del pod.

kubectl

Este agente debe seguir estos pasos:

  1. Para ver el estado de tus pods, sigue estos pasos:

    kubectl get pods -n NAMESPACE
    

    Sustituye NAMESPACE por el espacio de nombres en el que se ejecutan tus pods.

    El resultado debería ser similar al siguiente:

    NAME         READY   STATUS       RESTARTS      AGE
    POD_NAME_1   2/2     Running      0             7d5h
    POD_NAME_2   0/1     ErrImagePull 0             7d5h
    

    La columna Status indica qué pods han experimentado un error al extraer una imagen.

  2. Ver eventos de pods con errores de extracción de imágenes:

    kubectl describe POD_NAME -n NAMESPACE
    

    Sustituye POD_NAME por el nombre del pod que has identificado en el paso anterior.

    En la sección Events se muestra más información sobre lo que ha ocurrido durante las extracciones de imágenes fallidas.

    El resultado debería ser similar al siguiente:

    ...
    Events:
      Type    Reason    Age               From           Message
      ----    ------    ----              ----           -------
      Warning  Failed   5m (x4 over 7m)   kubelet, NODE  Failed to pull image "IMAGE_ADDRESS": rpc error: code = Unknown desc = Error response from daemon: repository IMAGE_ADDRESS not found
      Warning  Failed   5m (x4 over 7m)   kubelet, NODE  Error: ErrImagePull
      Normal   BackOff  5m (x6 over 7m)   kubelet, NODE  Back-off pulling image "IMAGE_ADDRESS"
      Warning  Failed   2m (x20 over 7m)  kubelet, NODE  Error: ImagePullBackOff
    

    En este resultado, IMAGE_ADDRESS es la dirección completa de la imagen. Por ejemplo, us-west1-docker.pkg.dev/my-project/my-repo/test:staging.

Información sobre el significado de los estados

Para entender mejor qué significan los diferentes estados, consulta las siguientes descripciones:

  • ImagePullBackOff: el kubelet no ha podido extraer la imagen, pero seguirá intentándolo con un retraso cada vez mayor (o retroceso) de hasta cinco minutos.
  • ErrImagePull: un error general e irrecuperable durante el proceso de extracción de la imagen.
  • ImageInspectError: el tiempo de ejecución del contenedor ha detectado un problema al intentar inspeccionar la imagen del contenedor.
  • InvalidImageName: el nombre de la imagen de contenedor especificado en tu definición de Pod no es válido.
  • RegistryUnavailable: no se puede acceder al registro. Normalmente, se trata de un problema de conectividad de red.
  • SignatureValidationFailed: no se ha podido verificar la firma digital de la imagen del contenedor.

Usar mensajes de eventos para encontrar la causa del error de extracción de imágenes

En la siguiente tabla se enumeran los mensajes de eventos relacionados con errores de extracción de imágenes y los pasos que debes seguir para solucionar los problemas si encuentras uno de estos mensajes.

Los mensajes relacionados con errores de extracción de imágenes suelen tener el siguiente prefijo:

Failed to pull image "IMAGE_ADDRESS": rpc error: code = CODE = failed to pull and unpack image "IMAGE_ADDRESS": failed to resolve reference "IMAGE_ADDRESS":

Este mensaje incluye los siguientes valores:

  • IMAGE_ADDRESS: la dirección completa de la imagen. Por ejemplo, us-west1-docker.pkg.dev/my-project/my-repo/test:staging.
  • CODE: código de error asociado al mensaje de registro. Por ejemplo, NotFound o Unknown.

Algunas causas de los errores de extracción de imágenes no tienen un mensaje de evento relacionado. Si no ves ninguno de los mensajes de eventos de la siguiente tabla, pero sigues teniendo problemas para extraer imágenes, te recomendamos que sigas leyendo el resto de la página.

Mensaje de evento Solución de problemas detallada
Autenticación
  • Failed to authorize: failed to fetch oauth token: unexpected status: 403 Forbidden
  • Pulling from host HOST_NAME failed with status code: 403 Forbidden
  • Failed to authorize: failed to fetch oauth token: unexpected status: 401 Unauthorized
  • Unexpected status code [manifests 1.0]: 401 Unauthorized

Conectividad de red
  • Failed to do request: Head "IMAGE_ADDRESS": dial tcp: lookup gcr.io on REGISTRY_IP_ADDRESS: server misbehaving
  • Failed to start Download and install k8s binaries and configurations
  • Failed to do request: Head "IMAGE_ADDRESS": dial tcp REGISTRY_IP_ADDRESS: i/o timeout
No se ha encontrado la imagen
  • "IMAGE_ADDRESS": not found
  • Failed to copy: httpReadSeeker: failed open: could not fetch content descriptor sha256:SHA_HASH (application/vnd.docker.container.image.v1+json) from remote: not found
Tiempo de espera de la imagen
  • Unknown desc = context canceled
Esquema incompatible
  • Failed to get converter for "IMAGE_ADDRESS": Pulling Schema 1 images have been deprecated and disabled by default since containerd v2.0. As a workaround you may set an environment variable `CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE=1`, but this will be completely removed in containerd v2.1.

Ver registros del explorador de registros

Para examinar los eventos de extracción de imágenes históricos o correlacionar los fallos de extracción de imágenes con la actividad de otros componentes, consulta los registros con Explorador de registros:

  1. En la Trusted 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:

    log_id("events")
    resource.type="k8s_pod"
    resource.labels.cluster_name="CLUSTER_NAME"
    jsonPayload.message=~"Failed to pull image"
    

    Sustituye CLUSTER_NAME por el nombre del clúster en el que se ejecuta el pod con errores de extracción de imágenes.

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

Investigar la configuración de autenticación

En las siguientes secciones se explica cómo verificar que tu entorno de GKE tiene la configuración de autenticación adecuada para extraer imágenes del repositorio.

Para comprobar si tienes problemas de autenticación que provocan un problema de extracción de imágenes, realiza las investigaciones que se detallan en las siguientes secciones:

  1. Verifica el acceso a la imagen.
  2. Verifica la configuración de imagePullSecret y la especificación de Deployment.
  3. Verifica que la cuenta de servicio del nodo esté activa.
  4. Verifica el ámbito de acceso del nodo al repositorio privado de Artifact Registry
  5. Verifica la configuración de Controles de Servicio de VPC para acceder a Artifact Registry.

Verificar el acceso a la imagen

Si se produce un 403 Forbiddenerror al extraer una imagen, comprueba que los componentes necesarios puedan acceder a la imagen de contenedor.

El método para verificar y aplicar los roles necesarios para conceder el acceso requerido varía en función del tipo de repositorio en el que se almacenen las imágenes. Para verificar y conceder acceso, selecciona una de las siguientes opciones:

Artifact Registry

Si usas un imagePullSecret, la cuenta de servicio vinculada con el secreto necesita permiso de lectura para el repositorio. De lo contrario, la cuenta de servicio del grupo de nodos necesita permiso.

  1. Sigue las instrucciones de la documentación de gestión de identidades y accesos para ver los roles asignados a tu cuenta de servicio.
  2. Si tu cuenta de servicio no tiene el rol de gestión de identidades y accesos Lector de Artifact Registry (roles/artifactregistry.reader), concédeselo:

    gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
        --location=REPOSITORY_LOCATION \
        --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
        --role="roles/artifactregistry.reader"
    

    Haz los cambios siguientes:

    • REPOSITORY_NAME: el nombre de tu repositorio de Artifact Registry.
    • REPOSITORY_LOCATION: la región de tu repositorio de Artifact Registry.
    • SERVICE_ACCOUNT_EMAIL: la dirección de correo de la cuenta de servicio obligatoria. Si no conoces la dirección, puedes enumerar todas las direcciones de correo de las cuentas de servicio de tu proyecto con el comando gcloud iam service-accounts list.

Container Registry

Si usas un imagePullSecret, la cuenta de servicio vinculada con el secreto necesita permiso de lectura para el repositorio. De lo contrario, la cuenta de servicio del grupo de nodos necesita permiso.

  1. Sigue las instrucciones de la documentación de gestión de identidades y accesos para ver los roles asignados a tu cuenta de servicio.
  2. Si tu cuenta de servicio no tiene el rol de gestión de identidades y accesos Visor de objetos de Storage (roles/storage.objectViewer), concédeselo para que la cuenta de servicio pueda leer del segmento:

    gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
        --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
        --role=roles/storage.objectViewer
    

    Haz los cambios siguientes:

    • SERVICE_ACCOUNT_EMAIL: el correo de la cuenta de servicio obligatoria. Puedes enumerar todas las cuentas de servicio de tu proyecto con el comando gcloud iam service-accounts list.
    • BUCKET_NAME: el nombre del segmento de Cloud Storage que contiene las imágenes. Puedes enumerar todos los segmentos de tu proyecto con el comando gcloud storage ls.

Si el administrador del registro ha configurado repositorios de gcr.io en Artifact Registry para almacenar imágenes del dominio gcr.io en lugar de Container Registry, debes conceder acceso de lectura a Artifact Registry en lugar de a Container Registry.

Registro autohospedado

En función de cómo hayas configurado tu registro autohospedado, es posible que necesites claves, certificados o ambos para acceder a la imagen.

Si usas claves, utiliza un imagePullSecret. Los imagePullSecrets son una forma segura de proporcionar a tu clúster las credenciales que necesita para acceder a un registro autohospedado. Para ver un ejemplo de cómo configurar un imagePullSecret, consulta Extraer una imagen de un registro privado en la documentación de Kubernetes.

Para proteger la conexión HTTPS a tu registro, también puedes necesitar certificados que verifiquen la integridad de la conexión al servidor remoto. Te recomendamos que uses Secret Manager para gestionar tu propia autoridad de certificación autofirmada. Para obtener más información, consulta Acceder a registros privados con certificados de AC privada.

Verificar la configuración de imagePullSecret y la especificación de Deployment

Si usas un imagePullSecret, asegúrate de haber creado un secreto que contenga las credenciales de autenticación para extraer imágenes y que todos los desplegues especifiquen el secreto que has definido. Para obtener más información, consulta el artículo Specifying imagePullSecrets on a Pod (Especificar imagePullSecrets en un pod) de la documentación de Kubernetes.

Verificar el estado activo de la cuenta de servicio del nodo

Si se produce un error al extraer una imagen de 401 Unauthorized, comprueba que la cuenta de servicio del nodo esté activa. Aunque los permisos estén configurados correctamente, si una cuenta está inhabilitada, se producirá este error. Para verificar el estado activo de la cuenta de servicio del nodo, seleccione una de las siguientes opciones:

Consola

  1. Busca el nombre de la cuenta de servicio que usan tus nodos:

    1. En la Trusted Cloud consola, ve a la página Clusters.

      Ir a Clústeres

    2. En la lista de clústeres, haga clic en el nombre del clúster que quiera inspeccionar.

    3. Busca el nombre de la cuenta de servicio del nodo.

      • En el caso de los clústeres en modo Autopilot, ve a la sección Seguridad y busca el campo Cuenta de servicio.
      • En el caso de los clústeres en modo estándar, haga lo siguiente:
      1. Haz clic en la pestaña Nodos.
      2. En la tabla Grupos de nodos, haz clic en el nombre de un grupo de nodos. Se abrirá la página Detalles del grupo de nodos.
      3. En la sección Seguridad, busca el campo Cuenta de servicio.

      Si el valor del campo Cuenta de servicio es default, tus nodos usarán la cuenta de servicio predeterminada de Compute Engine. Si el valor de este campo no es default, tus nodos usan una cuenta de servicio personalizada.

  2. Comprueba si la cuenta de servicio del nodo está inhabilitada:

    1. En la Trusted Cloud consola, ve a la página Cuentas de servicio.

      Ir a Cuentas de servicio

    2. Selecciona un proyecto.

    3. Busca el nombre de la cuenta de servicio que has identificado en el paso anterior.

    4. Consulta la columna Estado de esa cuenta. Si la cuenta de servicio está inhabilitada, tendrá el estado Disabled.

gcloud

  1. Busca el nombre de la cuenta de servicio que usan tus nodos:

    • En los clústeres del modo Autopilot, ejecuta el siguiente comando:
    gcloud container clusters describe CLUSTER_NAME \
        --location=LOCATION \
        --flatten=autoscaling.autoprovisioningNodePoolDefaults.serviceAccount
    
    • En los clústeres en modo Estándar, ejecuta el siguiente comando:
    gcloud container clusters describe CLUSTER_NAME \
        --location=LOCATION \
        --format="table(nodePools.name,nodePools.config.serviceAccount)"
    

    Si el resultado es default, tus nodos usan la cuenta de servicio predeterminada de Compute Engine. Si el resultado no es default, tus nodos usan una cuenta de servicio personalizada.

  2. Comprueba si la cuenta de servicio del nodo está inhabilitada:

    gcloud iam service-accounts list --filter="email:SERVICE_ACCOUNT_NAME AND disabled:true" \
    --project=PROJECT_ID
    

    Si el comando devuelve un resultado, la cuenta de servicio está inhabilitada.

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

Verifica el ámbito de acceso del nodo al repositorio privado de Artifact Registry

Si almacenas tu imagen de contenedor en un repositorio privado de Artifact Registry, es posible que tu nodo no tenga el ámbito de acceso correcto. Cuando esto ocurre, es posible que veas un error de extracción de imágenes 401 Unauthorized.

Para verificar el ámbito de acceso y concederlo si es necesario, sigue estos pasos:

  1. Identifica el nodo que ejecuta el pod:

    kubectl describe pod POD_NAME | grep "Node:"
    

    Sustituye POD_NAME por el nombre del pod que tiene un error al extraer una imagen.

  2. Verifica que el nodo que has identificado en el paso anterior tenga el ámbito de almacenamiento correcto:

    gcloud compute instances describe NODE_NAME \
        --zone="COMPUTE_ZONE" \
        --format="flattened(serviceAccounts[].scopes)"
    

    Haz los cambios siguientes:

    • NODE_NAME: el nombre del nodo que has identificado en el paso anterior.
    • COMPUTE_ZONE: la zona de Compute Engine a la que pertenece el nodo.

    La salida debe contener al menos uno de los siguientes ámbitos de acceso:

    • serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/devstorage.read_only
    • serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/cloud-platform

    Si el nodo no contiene uno de estos ámbitos, la extracción de la imagen falla.

  3. Vuelve a crear el grupo de nodos al que pertenece el nodo con un ámbito suficiente. Como no puedes modificar los nodos, debes volver a crear el nodo con el ámbito correcto.

    Te recomendamos que crees el grupo de nodos con el ámbito gke-default. Este ámbito proporciona acceso a los siguientes ámbitos:

    • https://www.googleapis.com/auth/devstorage.read_only
    • https://www.googleapis.com/auth/logging.write
    • https://www.googleapis.com/auth/monitoring
    • https://www.googleapis.com/auth/service.management.readonly
    • https://www.googleapis.com/auth/servicecontrol
    • https://www.googleapis.com/auth/trace.append

    Si el ámbito gke-default no es adecuado, concede al grupo de nodos el ámbito devstorage.read_only, que permite acceder a los datos de solo lectura.

    gke-default

    Crea un grupo de nodos con el permiso gke-default:

    gcloud container node-pools create NODE_POOL_NAME \
        --cluster=CLUSTER_NAME \
        --location=CONTROL_PLANE_LOCATION \
        --scopes="gke-default"
    

    Haz los cambios siguientes:

    • NODE_POOL_NAME: el nombre del nuevo grupo de nodos.
    • CLUSTER_NAME: el nombre del clúster.
    • CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.

    devstorage.read_only

    Crea un grupo de nodos con el permiso devstorage.read_only:

    gcloud container node-pools create NODE_POOL_NAME \
        --cluster=CLUSTER_NAME \
        --location=CONTROL_PLANE_LOCATION \
        --scopes="https://www.googleapis.com/auth/devstorage.read_only"
    

    Haz los cambios siguientes:

    • NODE_POOL_NAME: el nombre del nuevo grupo de nodos.
    • CLUSTER_NAME: el nombre del clúster.
    • CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.

Verificar la configuración de Controles de Servicio de VPC para acceder a Artifact Registry

Si usas Controles de Servicio de VPC, asegúrate de que los perímetros de servicio permitan el acceso a Artifact Registry. Para obtener más información, consulta el artículo Proteger repositorios en un perímetro de servicio de la documentación de Artifact Registry.

Investigar la conectividad de red

Durante una extracción de imágenes, la conectividad de red puede impedir que se complete el proceso.

Para comprobar si los problemas de conectividad de red están provocando un problema de extracción de imágenes, realiza las investigaciones que se detallan en las siguientes secciones:

  1. Investiga la resolución de DNS.
  2. Investiga la configuración de tu cortafuegos.
  3. Investiga la conectividad a Internet de los endpoints de registro externos.
  4. Investiga si se está agotando el tiempo de espera de la conexión con las APIs de Google.

Investigar la resolución de DNS

Si ves un error de extracción de imágenes server misbehaving, puede que la resolución de DNS sea la causa del fallo.

Para investigar problemas con la resolución de DNS, prueba las siguientes soluciones:

  1. Soluciona problemas del servidor de metadatos. El servidor de metadatos del nodo resuelve todas las consultas de DNS. Cualquier problema que afecte a este servidor puede interrumpir la resolución de nombres, lo que impide la conexión con el repositorio y provoca que falle la extracción de la imagen.
  2. Si usas Cloud DNS para la resolución de DNS, asegúrate de que tus zonas privadas gestionadas, zonas de reenvío, zonas de peering y políticas de respuesta de Cloud DNS estén configuradas correctamente. Las configuraciones incorrectas en estas áreas pueden interrumpir la resolución de DNS. Para obtener más información sobre Cloud DNS, consulta el artículo Usar Cloud DNS para GKE. Para obtener información sobre cómo solucionar problemas de Cloud DNS en GKE, consulta el artículo Solucionar problemas de Cloud DNS en GKE.
  3. Si usas kube-dns para la resolución de DNS, asegúrate de que funcione correctamente. Para obtener consejos sobre cómo solucionar problemas de kube-dns, consulta el artículo Solucionar problemas de kube-dns en GKE.
  4. Si los nodos del clúster no tienen direcciones IP externas (lo que es habitual si usas el aislamiento de red), habilita Acceso privado de Google en la subred que usa el clúster y asegúrate de que cumples los requisitos de red. Si usas Cloud NAT, Trusted Cloud by S3NS habilita Acceso privado de Google automáticamente.

Investiga la configuración de tu cortafuegos

Si se produce un problema con tu firewall que provoca que falle la extracción de la imagen, es posible que veas el siguiente mensaje de error:

Failed to start Download and install k8s binaries and configurations

Diagnosticar problemas con tu cortafuegos

Si usas un clúster estándar y quieres confirmar si un problema con tu firewall está provocando problemas con las extracciones de imágenes, sigue estos pasos:

  1. Usa SSH para conectarte al nodo que tiene problemas:

    gcloud compute ssh NODE_NAME --zone=ZONE_NAME
    

    Haz los cambios siguientes:

  2. Envía los registros más recientes de los servicios kube-node-installation.service y kube-node-configuration.service a archivos de texto llamados kube-node-installation_status.txt y kube-node-configuration_status.txt:

    systemctl status kube-node-installation.service > kube-node-installation_status.txt
    systemctl status kube-node-configuration.service > kube-node-configuration_status.txt
    

    Si estos registros no incluyen información sobre el momento en el que se produjo un error al extraer la imagen, genera una copia completa de los registros:

    sudo journalctl -u kube-node-installation.service > kube-node-installation_logs.txt
    sudo journalctl -u kube-node-configuration.service > kube-node-configuration_logs.txt
    
  3. Revisa el contenido de kube-node-installation_status.txty kube-node-configuration_status.txt y los archivos. Si ves i/o timeout en el resultado, es probable que el problema esté relacionado con tu firewall.

Resolver problemas con la configuración del cortafuegos

Para solucionar los problemas con tu cortafuegos, prueba las siguientes soluciones:

  1. Identifique y resuelva las reglas de cortafuegos que estén bloqueando el tráfico de red. Por ejemplo, puede tener una regla que bloquee el tráfico al registro que almacena su imagen.

    1. Accede a los registros de flujo de VPC:

      1. En la Trusted 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="gce_subnetwork"
        logName="projects/PROJECT_ID/logs/[compute.googleapis.com%2Fvpc_flows](http://compute.googleapis.com%2Fvpc_flows)"
        resource.labels.subnetwork_name="SUBNET_NAME",
        

        Haz los cambios siguientes:

        • PROJECT_ID: el ID de tu proyecto de Trusted Cloud .
        • SUBNET_NAME: el nombre de tu subred.

        Para obtener más información, consulta el artículo Acceder a los registros de flujo mediante consultas de la documentación de VPC.

    2. Si encuentra alguna regla de cortafuegos que esté bloqueando el tráfico necesario, actualícela.

  2. Si los nodos del clúster no tienen direcciones IP externas (lo que es habitual si usas el aislamiento de red), habilita Acceso privado de Google en la subred que usa el clúster y asegúrate de que cumples los requisitos de red. Si usas Cloud NAT, Trusted Cloud by S3NS habilita Acceso privado de Google automáticamente.

Investigar la conectividad a Internet de los endpoints de registro externos

Si la configuración de tu red dirige el tráfico a través de un endpoint de registro externo, es posible que ese endpoint no tenga conexión a Internet. Si el endpoint no tiene acceso, es posible que la extracción de la imagen falle y que se produzca un i/o timeout error de extracción de la imagen.

Para comprobar la conectividad de red desde el endpoint del registro externo al registro, usa ping o traceroute:

ping REGISTRY_ENDPOINT

O

traceroute REGISTRY_ENDPOINT

Sustituye REGISTRY_ENDPOINT por el endpoint del registro. Este valor puede ser un nombre de host o una dirección IP.

Si detectas un error de conectividad, revisa las rutas de VPC:

  1. En la Trusted Cloud consola, ve a Rutas.

    Ir a Rutas

  2. Revisa la columna Prioridad y asegúrate de que la ruta con la prioridad más alta vaya a una fuente que tenga acceso al registro. Las rutas con valores más bajos tienen prioridad.

Investigar si se está agotando el tiempo de espera de la conexión con las APIs de Google

Si usas el aislamiento de red, es posible que se produzca un error en el que se agote el tiempo de espera de la conexión a las APIs y los servicios de Google, lo que provocará un error de extracción de la imagen i/o timeout.

Este error se produce porque tus nodos no han podido acceder a una de las siguientes APIs cuando han intentado extraer imágenes del registro:

  • containerregistry.googleapis.com
  • artifactregistry.googleapis.com

Para asegurarte de que puedes conectarte a las APIs necesarias, prueba las siguientes soluciones:

  1. Habilita Acceso privado de Google. Los nodos sin direcciones IP externas necesitan Acceso privado de Google para llegar a las direcciones IP externas de las APIs y los servicios de Google.
  2. Usa un dominio admitido.
  3. Revisa tus políticas de cortafuegos:

    1. En la Trusted Cloud consola, ve a Políticas de cortafuegos.

      Ir a Políticas de cortafuegos

    2. Verifica si tienes alguna regla que bloquee el tráfico TCP de salida en el puerto 443 a 199.36.153.4/30, 199.36.153.8/30 o cualquier intervalo de direcciones IP que use el dominio que hayas elegido para las APIs y los servicios de Google. Los intervalos de direcciones IP 199.36.153.4/30 y 199.36.153.8/30 se usan para el acceso privado de Google y el acceso restringido de Google, respectivamente. El tráfico TCP en el puerto 443 a estos intervalos se usa para acceder a las APIs y los servicios de Google.

      Si encuentras alguna de estas reglas, crea una regla de cortafuegos de salida para permitir ese tráfico.

  4. Si usas Artifact Registry, asegúrate de que tu entorno cumpla los requisitos para usar Artifact Registry con aislamiento de red.

  5. Comprueba que las direcciones IP virtuales (VIPs) (199.36.153.4/30 o 199.36.153.8/30) tengan configuradas rutas de VPC:

    1. En la Trusted Cloud consola, ve a Redes de VPC.

      Ir a redes de VPC

    2. En la columna Nombre, haga clic en predeterminado.

    3. En la página de detalles de la red de VPC, haz clic en la pestaña Rutas.

    4. Revisa la tabla de rutas.

      Si tu red VPC contiene una ruta predeterminada (destino 0.0.0.0/0 o ::0/0) y el siguiente salto de esa ruta es la pasarela de Internet predeterminada (Red predeterminada), usa esa ruta para que las IPs virtuales accedan a las APIs y los servicios de Google.

      Si has sustituido una ruta predeterminada por una ruta personalizada cuyo siguiente salto no es la pasarela de Internet predeterminada, cumple los requisitos de enrutamiento de las APIs y los servicios de Google usando el enrutamiento personalizado.

Investiga por qué kubelet no encuentra tu imagen

Si el kubelet no encuentra tu imagen, es posible que veas un image not found error y que se produzcan fallos al extraer la imagen.

Para ayudar a kubelet a encontrar tu imagen, prueba las siguientes soluciones:

  1. Revisa el manifiesto de tu pod y asegúrate de que el nombre y la etiqueta de la imagen estén escritos correctamente. Si hay errores ortográficos o de formato, la extracción de la imagen fallará.
  2. Comprueba que la imagen siga estando en el registro en el que la almacenaste. Si la imagen tiene una ruta de registro completa, comprueba que existe en el registro de Docker que utilizas. Si solo proporcionas el nombre de la imagen, consulta el registro de Docker Hub.
  3. Si tu clúster usa aislamiento de red, prueba las siguientes soluciones:
    1. Habilita el Acceso privado de Google.
    2. Verifica que tu perímetro de servicio esté configurado correctamente.

Investiga por qué se agota el tiempo de espera de la extracción de imágenes o por qué la extracción de imágenes es lenta

Si usas una imagen muy grande para tu carga de trabajo de GKE, es posible que se agote el tiempo de espera de la extracción de la imagen y se produzca un error context cancelled. Aunque las imágenes no tienen un límite de tamaño definido, el error context cancelled suele indicar que el tamaño de la imagen es el motivo.

También puede que observes que las solicitudes de imágenes no fallan, pero tardan mucho más de lo habitual. Si quieres tener una referencia de los tiempos de extracción de imágenes habituales, consulta la entrada de registro Successfully pulled image. Por ejemplo, el siguiente mensaje de registro muestra que la extracción de la imagen ha tardado 30,313387996 segundos:

Successfully pulled image "IMAGE_ADDRESS" in 30.313387996s.

Los tiempos de espera y las extracciones de imágenes lentas comparten muchas de las mismas causas. Para solucionar estos problemas, prueba las siguientes soluciones:

  1. Comprueba si hay interrupciones. Si solo ha detectado este problema durante un periodo concreto, compruebe si ha habido alguna Trusted Cloud by S3NS interrupción del servicio.
  2. Comprueba el rendimiento del disco. Una E/S de disco lenta puede aumentar los tiempos de extracción de imágenes. Te recomendamos que actualices a discos persistentes con SSDs (pd-ssd) o que uses discos más grandes para mejorar el rendimiento. Para obtener más consejos, consulta Solucionar problemas de rendimiento de los discos.
  3. Reduce el tamaño de la imagen. Por ejemplo, puedes mover algunos datos de las imágenes de contenedor a volúmenes persistentes.
  4. Aprovecha el almacenamiento en caché de imágenes para que los pods se inicien rápidamente. GKE almacena en caché las imágenes en los nodos. Durante la extracción de una imagen, el tiempo de ejecución del contenedor solo descarga las capas que aún no están presentes en la caché. Para maximizar la eficacia de este mecanismo de almacenamiento en caché y minimizar los tiempos de extracción de imágenes, estructura tu archivo Dockerfile de forma que las partes de la imagen que cambien con frecuencia (como el código de tu aplicación) se encuentren al final del archivo y usa imágenes base más pequeñas.
  5. Habilita la transmisión de imágenes. Esta función puede acelerar el inicio de los pods y la descarga de imágenes. Para obtener más información, consulta Usar streaming de imágenes para extraer imágenes de contenedor.
  6. Asegúrate de que la cuenta de servicio predeterminada tenga los permisos necesarios. Si modificas los roles asignados a la cuenta de servicio predeterminada, se pueden interrumpir las cargas de trabajo, incluidas las extracciones de imágenes. Para obtener más información, consulta Identificar clústeres con cuentas de servicio de nodos a las que les faltan permisos críticos.
  7. Examina las configuraciones de proxy. Si hay un proxy entre tu clúster de GKE y un repositorio no gestionado por Google, podría producirse latencia.
  8. Comprueba el software de terceros. Algunos programas de terceros pueden interferir en las extracciones de imágenes. Investiga si alguna herramienta instalada recientemente puede estar causando conflictos.

Verifica que el manifiesto de la imagen use la arquitectura correcta

Si la imagen que estás intentando extraer se ha creado para una arquitectura de ordenador diferente a la que usan tus grupos de nodos, la extracción de la imagen fallará.

Para confirmar si el manifiesto de la imagen usa la arquitectura correcta, sigue estos pasos:

  1. Para confirmar qué arquitectura usa tu imagen, consulta el manifiesto de tu imagen. Por ejemplo, para ver una imagen de Docker, ejecuta el siguiente comando:

    docker manifest inspect --verbose IMAGE_NAME
    

    Sustituye IMAGE_NAME por el nombre de la imagen que quieras ver.

    El resultado debería ser similar al siguiente:

    ...
    "Platform": {
              "architecture": "amd64",
              "os": "linux"
      }
    ...
    

    En este ejemplo, la arquitectura admitida es amd64.

  2. Revisa el tipo de máquina que usan tus grupos de nodos:

    gcloud container node-pools list --cluster CLUSTER_NAME --location CONTROL_PLANE_LOCATION
    

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster en el que se ejecuta el pod con errores de extracción de imágenes.
    • CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.

    El resultado debería ser similar al siguiente:

    NAME: example-node-pool
    MACHINE_TYPE: e2-standard-2
    DISK_SIZE_GB: 100
    NODE_VERSION: 1.30.8-gke.1162000
    

    En este ejemplo, el tipo de máquina es e2-standard-2.

  3. Compara los valores de los campos architecture y MACHINE_TYPE y asegúrate de que ambos valores sean compatibles. Por ejemplo, si la imagen tiene una arquitectura amd64, sería compatible con un grupo de nodos que utilice e2-standard-2 como tipo de máquina. Sin embargo, si el grupo de nodos usara t2a-standard-1 (un tipo de máquina basado en Arm), este tipo de máquina provocaría un error.

  4. Si la arquitectura de la imagen no es compatible con el tipo de máquina del grupo de nodos, vuelve a compilar la imagen para que se ajuste a la arquitectura necesaria.

Verificar la compatibilidad de la versión del esquema de imagen

Si se usa containerd 2.0 con una imagen de esquema de Docker v1, se producirá un error al extraer la imagen, ya que containerd 2.0 ha dejado de admitir la extracción de imágenes de esquema de Docker 1 en GKE 1.33. Si este problema es la causa del error al extraer la imagen, puede que veas el siguiente mensaje de error:

Failed to get converter for "IMAGE_ADDRESS": Pulling Schema 1 images have been deprecated and disabled by default since containerd v2.0. As a workaround you may set an environment variable `CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE=1`, but this will be completely removed in containerd v2.1.

Para solucionar este problema, identifique y migre estas imágenes siguiendo las instrucciones que se indican en Migrar de imágenes de Docker Schema 1.

Siguientes pasos