Cómo solucionar problemas relacionados con la extracción de imágenes


En esta página, se muestra cómo resolver problemas con el proceso de extracción de imágenes en Google Kubernetes Engine (GKE). Si usas la transmisión de imágenes, consulta Soluciona problemas de la transmisión de imágenes para obtener asesoramiento. En esta página, se explican las extracciones de imágenes estándar.

Esta página está dirigida a los desarrolladores de aplicaciones que desean asegurarse de que sus apps se implementen correctamente, y a los administradores y operadores de la plataforma que desean comprender la causa raíz de las fallas en la extracción de imágenes y verificar la configuración de la plataforma. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Trusted Cloud by S3NS , consulta Tareas y roles comunes de los usuarios de GKE.

El proceso de extracción de imágenes es la forma en que Kubernetes y, por lo tanto, GKE, recuperan imágenes de contenedor de un registro. Cuando falla la extracción de una imagen, es posible que notes lentitud en tu app o que esta no funcione en absoluto.

Para determinar si las extracciones de imágenes son la causa de que tu app no funcione, esta página te ayuda a diagnosticar las fallas en la extracción de imágenes, ya que te permite encontrar y comprender los mensajes de error pertinentes. Luego, aprenderás a abordar las siguientes causas comunes de errores de extracción de imágenes:

  • 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 se puede conectar al registro debido a problemas de DNS, reglas de firewall o falta de acceso a Internet en clústeres que usan aislamiento de red.
  • No se encontró la imagen en el registro: El nombre o la etiqueta de la imagen especificados son incorrectos, la imagen se borró o el registro no está disponible.
  • Limitaciones de rendimiento: El tamaño grande de la imagen, la lentitud de la E/S del disco o la congestión de la red pueden provocar extracciones lentas o tiempos de espera.
  • Arquitectura de imagen incompatible: La imagen se compiló para una arquitectura de CPU diferente a la de tu grupo de nodos de GKE.
  • Versiones de esquema incompatibles: Es posible que estés usando containerd 2.0 o una versión posterior con un esquema de Docker v1, que no es compatible.

Si ya viste un mensaje de evento específico, búscalo en esta página y sigue los pasos para solucionar el problema que se indican. Si no viste un mensaje, sigue las instrucciones de las siguientes secciones en orden. Si el problema persiste, comunícate con Atención al cliente de Cloud.

Información sobre la extracción de imágenes

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

Ciclo de vida de la imagen

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, kubelet verifica el tiempo de ejecución del contenedor para ver si la imagen está presente. Kubelet también verifica 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 dirige el entorno de ejecución del contenedor (containerd) para que extraiga la imagen especificada del registro. Si no se puede extraer la imagen, el contenedor del Pod no se iniciará.

Después de una extracción de imagen exitosa, el entorno de ejecución del contenedor descomprime la imagen 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 vuelve apta para la recolección de elementos no utilizados y kubelet la quita con el tiempo.

Opciones de alojamiento de imágenes

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

  • Artifact Registry: Artifact Registry es el administrador de paquetes completamente administrado de Google. Artifact Registry se integra estrechamente con otros servicios de Trusted Cloud by S3NSy ofrece un control de acceso detallado. Para obtener más información, consulta Trabaja con imágenes de contenedor en la documentación de Artifact Registry.

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

Diagnostica la falla en la extracción de imágenes

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

  1. Ver el estado y los eventos del Pod
  2. Comprende el significado del estado.
  3. Usa los mensajes de eventos para encontrar la causa de la falla en la extracción de imágenes.
  4. Visualiza los registros del Explorador de registros.

Cómo ver el estado y los eventos del Pod

Para ayudarte a verificar que falló la extracción de una imagen, GKE registra los siguientes estados para los Pods:

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

ImagePullBackOff y ErrImagePull son los más comunes de estos estados.

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

Para confirmar si la extracción de la imagen falla, busca mensajes de estado y, luego, lee los mensajes de eventos seleccionando una de las siguientes opciones:

Console

Completa los siguientes pasos:

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

    Ir a Cargas de trabajo

  2. Elige la carga de trabajo que deseas investigar. Si no sabes qué carga de trabajo debes examinar, revisa 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, busca la sección Pods administrados y haz clic en el nombre del Pod con un estado que indique una falla en la extracción de la imagen.

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

  5. Revisa la información de la tabla. En la columna Mensaje, se enumeran los eventos de Kubernetes, que muestran más información sobre las extracciones de imágenes fallidas. En la columna Motivo, se indica el estado del Pod.

kubectl

Completa los siguientes pasos:

  1. Consulta el estado de tus Pods:

    kubectl get pods -n NAMESPACE
    

    Reemplaza NAMESPACE por el espacio de nombres en el que se ejecutan tus Pods.

    El resultado es similar a este:

    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 experimentaron una falla en la extracción de imágenes.

  2. Visualiza los eventos de los Pods con errores de extracción de imágenes:

    kubectl describe POD_NAME -n NAMESPACE
    

    Reemplaza POD_NAME por el nombre del Pod que identificaste en el paso anterior.

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

    El resultado es similar a este:

    ...
    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 del estado

Para comprender mejor el significado de los diferentes estados, consulta las siguientes descripciones:

  • ImagePullBackOff: Kubelet no pudo extraer la imagen, pero seguirá reintentando con una demora (o retraso) cada vez mayor de hasta cinco minutos.
  • ErrImagePull: Es un error general y no recuperable durante el proceso de extracción de la imagen.
  • ImageInspectError: El entorno de ejecución del contenedor detectó un problema al intentar inspeccionar la imagen del contenedor.
  • InvalidImageName: El nombre de la imagen del contenedor especificado en la definición del Pod no es válido.
  • RegistryUnavailable: No se puede acceder al registro. Por lo general, se trata de un problema de conectividad de red.
  • SignatureValidationFailed: No se pudo verificar la firma digital de la imagen del contenedor.

Usa mensajes de eventos para encontrar la causa de la falla en la extracción de imágenes

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

Los mensajes relacionados con errores de recuperació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: Es la dirección completa de la imagen. Por ejemplo, us-west1-docker.pkg.dev/my-project/my-repo/test:staging.
  • CODE: Es un código de error asociado al mensaje de registro. Por ejemplo, NotFoundUnknown.

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

Mensaje del 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 encontró 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.

Visualiza los registros del Explorador de registros

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

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

    Ir al Explorador de registros

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

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

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

Investiga la configuración de autenticación

En las siguientes secciones, se te ayudará a verificar que tu entorno de GKE tenga la configuración de autenticación adecuada para extraer imágenes del repositorio.

Para verificar si tienes problemas de autenticación que causan 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 el estado activo de la cuenta de servicio del nodo.
  4. Verifica el permiso de acceso del nodo para el repositorio privado de Artifact Registry
  5. Verifica la configuración de los Controles del servicio de VPC para acceder a Artifact Registry.

Verifica el acceso a la imagen

Si encuentras un error de extracción de la imagen 403 Forbidden, verifica que los componentes necesarios puedan acceder a la imagen del contenedor.

El método para verificar y aplicar los roles necesarios para otorgar el acceso requerido difiere según el tipo de repositorio en el que se almacenan tus imágenes. Para verificar y otorgar acceso, selecciona una de las siguientes opciones:

Artifact Registry

Si usas un imagePullSecret, la cuenta de servicio vinculada con el Secret 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 IAM para ver las funciones asignadas a tu cuenta de servicio.
  2. Si tu cuenta de servicio no tiene el rol de IAM de lector de Artifact Registry (roles/artifactregistry.reader), otórgale el rol:

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

    Reemplaza lo siguiente:

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

Container Registry

Si usas un imagePullSecret, la cuenta de servicio vinculada con el Secret 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 IAM para ver las funciones asignadas a tu cuenta de servicio.
  2. Si tu cuenta de servicio no tiene el rol de IAM Visualizador de objetos de almacenamiento (roles/storage.objectViewer), otórgale el rol para que la cuenta de servicio pueda leer desde el bucket:

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

    Reemplaza lo siguiente:

    • SERVICE_ACCOUNT_EMAIL: Es el correo electrónico de la cuenta de servicio requerida. Puedes enumerar todas las cuentas de servicio de tu proyecto con el comando gcloud iam service-accounts list.
    • BUCKET_NAME: es el nombre del bucket de Cloud Storage que contiene tus imágenes. Puedes enumerar todos los buckets de tu proyecto con el comando gcloud storage ls.

Si tu administrador de registros configuró repositorios de gcr.io en Artifact Registry para almacenar imágenes del dominio gcr.io en lugar de Container Registry, debes otorgar acceso de lectura a Artifact Registry en lugar de Container Registry.

Registro autoalojado

Según cómo hayas configurado tu registro autoalojado, es posible que necesites claves, certificados o ambos para acceder a la imagen.

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

Para proteger la conexión HTTPS a tu registro, es posible que también necesites certificados que verifiquen la integridad de la conexión al servidor remoto. Te recomendamos que uses Secret Manager para administrar tu propia entidad certificadora autofirmada. Para obtener más información, consulta Accede a registros privados con certificados de la AC privados.

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

Si usas un imagePullSecret, asegúrate de haber creado un objeto Secret que contenga las credenciales de autenticación para extraer imágenes y de que todas las implementaciones especifiquen el objeto Secret que definiste. Para obtener más información, consulta Cómo especificar imagePullSecrets en un Pod en la documentación de Kubernetes.

Verifica el estado activo de la cuenta de servicio del nodo

Si encuentras un error 401 Unauthorized de extracción de imágenes, verifica que la cuenta de servicio del nodo esté activa. Incluso si los permisos están configurados correctamente, una cuenta inhabilitada mostrará este error. Para verificar el estado activo de la cuenta de servicio del nodo, selecciona una de las siguientes opciones:

Console

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

    1. En la consola de Trusted Cloud , ve a la página Clústeres.

      Ir a los clústeres

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

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

      • Para los clústeres en modo Autopilot, en la sección Seguridad, busca el campo Cuenta de servicio.
      • Para los clústeres en modo Standard, haz 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 usan 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. Verifica si la cuenta de servicio del nodo está inhabilitada:

    1. En la consola de Trusted Cloud , 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 identificaste en el paso anterior.

    4. Verifica 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:

    • Para los clústeres en modo Autopilot, ejecuta el siguiente comando:
    gcloud container clusters describe CLUSTER_NAME \
        --location=LOCATION \
        --flatten=autoscaling.autoprovisioningNodePoolDefaults.serviceAccount
    
    • Para 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. Verifica 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 permiso de acceso del nodo para el 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 permiso de acceso correcto. Cuando esto sucede, es posible que observes un error de extracción de la imagen 401 Unauthorized.

Para verificar el permiso de acceso y otorgarlo si es necesario, sigue estos pasos:

  1. Identifica el nodo que ejecuta el Pod:

    kubectl describe pod POD_NAME | grep "Node:"
    

    Reemplaza POD_NAME por el nombre del Pod que experimenta una falla en la extracción de la imagen.

  2. Verifica que el nodo que identificaste en el paso anterior tenga el permiso de almacenamiento correcto:

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

    Reemplaza lo siguiente:

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

    El resultado debe contener al menos uno de los siguientes permisos 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 permisos, la extracción de la imagen falla.

  3. Vuelve a crear el grupo de nodos al que pertenece el nodo con permiso suficiente. No puedes modificar los nodos existentes, debes volver a crear el nodo con el permiso correcto.

    Te recomendamos que crees el grupo de nodos con el permiso gke-default. Este alcance proporciona acceso a los siguientes alcances:

    • 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 alcance gke-default no es adecuado, otorga al grupo de nodos el alcance devstorage.read_only, que permite el acceso solo a los datos de 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"
    

    Reemplaza lo siguiente:

    • NODE_POOL_NAME: el nombre del grupo de nodos nuevo
    • CLUSTER_NAME: Es el nombre del clúster existente.
    • CONTROL_PLANE_LOCATION: Es 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"
    

    Reemplaza lo siguiente:

    • NODE_POOL_NAME: el nombre del grupo de nodos nuevo
    • CLUSTER_NAME: Es el nombre del clúster existente.
    • CONTROL_PLANE_LOCATION: Es 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.

Verifica la configuración de los Controles del servicio de VPC para acceder a Artifact Registry

Si usas los Controles del 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 Protege repositorios en un perímetro de servicio en la documentación de Artifact Registry.

Investiga la conectividad de red

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

Para verificar si los problemas de conectividad de red están causando 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 del firewall.
  3. Investiga la conectividad a Internet de los extremos del registro externo.
  4. Investiga si se agota el tiempo de espera de la conexión a las APIs de Google.

Investiga la resolución de DNS

Si ves un error de extracción de la imagen server misbehaving, es posible que la resolución de DNS sea la causa de la falla en la extracción de la imagen.

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

  1. Soluciona problemas con el servidor de metadatos. El servidor de metadatos del nodo resuelve todas las consultas de DNS. Cualquier problema que involucre a este servidor puede interrumpir la resolución de nombres, lo que impide la conexión al 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 administradas, zonas de reenvío, zonas de intercambio de tráfico y políticas de respuesta de Cloud DNS estén configuradas correctamente. Los errores de configuración en estas áreas pueden interrumpir la resolución de DNS. Si deseas obtener más información sobre Cloud DNS, consulta Usa Cloud DNS para GKE. Para obtener asesoramiento sobre cómo solucionar problemas de Cloud DNS en GKE, consulta Soluciona 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 asesoramiento sobre la solución de problemas de kube-dns, consulta Soluciona problemas de kube-dns en GKE.
  4. Si los nodos del clúster no tienen direcciones IP externas (lo que es común si usas aislamiento de red), habilita el Acceso privado a Google en la subred que usa el clúster y asegúrate de cumplir con los requisitos de red. Si usas Cloud NAT,Trusted Cloud by S3NS habilita el Acceso privado a Google automáticamente.

Investiga la configuración del firewall

Cuando un problema con tu firewall hace 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

Diagnostica problemas con tu firewall

Si usas un clúster estándar y quieres confirmar si un problema con tu firewall está causando 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
    

    Reemplaza lo siguiente:

  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 del momento en que falló la extracción de 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 los archivos kube-node-installation_status.txt y kube-node-configuration_status.txt. Si ves i/o timeout en el resultado, es probable que el problema esté relacionado con tu firewall.

Cómo resolver problemas con la configuración del firewall

Para resolver problemas con tu firewall, prueba las siguientes soluciones:

  1. Identifica y resuelve las reglas de firewall que bloquean el tráfico de red. Por ejemplo, es posible que tengas una regla que bloquee el tráfico al registro que almacena tu 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 al Explorador de registros

      2. En el panel de consultas, ingresa 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",
        

        Reemplaza lo siguiente:

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

        Para obtener más información, consulta Cómo acceder a los registros de flujo con consultas en la documentación de VPC.

    2. Si encuentras reglas de firewall que bloquean el tráfico requerido, actualízalas.

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

Investiga la conectividad a Internet de los extremos del registro externo

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

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

ping REGISTRY_ENDPOINT

O

traceroute REGISTRY_ENDPOINT

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

Si encuentras un error con la conectividad, revisa las rutas de VPC:

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

    Ir a Rutas

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

Investiga si se agota el tiempo de espera de la conexión a las APIs de Google

Si usas el aislamiento de red, es posible que experimentes 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 generará un error de extracción de la imagen de i/o timeout.

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

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

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

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

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

      Ir a Políticas de firewall

    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 rango de direcciones IP que use el dominio que elegiste para las APIs y los servicios de Google. Los rangos de direcciones IP 199.36.153.4/30 y 199.36.153.8/30 se usan para el acceso privado a Google y el acceso restringido a Google, respectivamente. El tráfico de TCP en el puerto 443 a estos rangos se utiliza para acceder a los servicios y las APIs de Google.

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

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

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

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

      Ir a las redes de VPC

    2. En la columna Nombre, haz 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 de VPC contiene una ruta predeterminada (destino 0.0.0.0/0 o ::0/0) y el siguiente salto para esa ruta es la puerta de enlace de Internet predeterminada (Predeterminado de la red), usa esa ruta para que las VIP accedan a los servicios y las APIs de Google.

      Si reemplazaste una ruta predeterminada por una ruta personalizada cuyo siguiente salto no es la puerta de enlace de Internet predeterminada, cumple con los requisitos de enrutamiento para los servicios y las APIs de Google usando el enrutamiento personalizado.

Investiga por qué kubelet no puede encontrar tu imagen

Cuando kubelet no puede encontrar tu imagen, es posible que veas un error de image not found y experimentes fallas en la extracción de imágenes.

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. Cualquier error ortográfico o de formato hace que falle la extracción de la imagen.
  2. Verifica que la imagen aún exista en el registro en el que la almacenaste. Si la imagen tiene una ruta de registro completa, verifica que exista en el registro de Docker que usas. Si proporcionas solo el nombre de la imagen, verifica el registro de Docker Hub.
  3. Si tu clúster usa aislamiento de red, prueba las siguientes soluciones:
    1. Habilita el Acceso privado a Google.
    2. Verifica que tu perímetro de servicio esté configurado correctamente.

Investiga por qué se agota el tiempo de espera de la recuperación de imágenes o por qué esta 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. Si bien 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 la causa.

También es posible que notes que las extracciones de imágenes no fallan, pero tardan mucho más de lo habitual. Si deseas tener una referencia de los tiempos de extracción de imágenes habituales, revisa la entrada de registro Successfully pulled image. Por ejemplo, el siguiente mensaje de registro muestra que la extracción de la imagen tardó 30.313387996 segundos:

Successfully pulled image "IMAGE_ADDRESS" in 30.313387996s.

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

  1. Verifica si hay interrupciones. Si solo notaste este problema durante un período específico, verifica si hubo alguna Trusted Cloud by S3NS interrupción.
  2. Verifica el rendimiento del disco. La E/S de disco lenta puede aumentar los tiempos de recuperación de imágenes. Considera actualizar a discos persistentes con SSD (pd-ssd) o usar discos más grandes para mejorar el rendimiento. Para obtener más sugerencias, consulta Soluciona problemas relacionados con el rendimiento del disco.
  3. Reduce el tamaño de la imagen. Por ejemplo, es posible que puedas 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 entorno 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 Dockerfile de modo que las partes de la imagen que cambian con frecuencia (como el código de tu aplicación) se encuentren hacia el 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 del Pod y las descargas de imágenes. Para obtener más información, consulta Usa la transmisión de imágenes para extraer imágenes de contenedor.
  6. Asegúrate de que la cuenta de servicio predeterminada tenga los permisos necesarios. Modificar los roles asignados a la cuenta de servicio predeterminada puede interrumpir las cargas de trabajo, incluidas las extracciones de imágenes. Para obtener más sugerencias, consulta Cómo identificar clústeres con cuentas de servicio de nodos a las que les faltan permisos críticos.
  7. Examina la configuración del proxy. Si existe un proxy entre tu clúster de GKE y un repositorio administrado que no es de Google, podría producirse latencia.
  8. Verifica el software de terceros. Algunos software de terceros pueden interferir con la extracción de imágenes. Investiga si alguna herramienta instalada recientemente podría estar causando conflictos.

Verifica que el manifiesto de la imagen use la arquitectura correcta

Si la imagen que intentas extraer se compiló para una arquitectura de computadora diferente de 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 la imagen. Por ejemplo, para ver una imagen de Docker, ejecuta el siguiente comando:

    docker manifest inspect --verbose IMAGE_NAME
    

    Reemplaza IMAGE_NAME por el nombre de la imagen que deseas ver.

    El resultado es similar a este:

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

    Reemplaza lo siguiente:

    • CLUSTER_NAME: Es el nombre del clúster en el que se ejecuta el Pod con errores de extracción de imágenes.
    • CONTROL_PLANE_LOCATION: Es 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 es similar a este:

    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 en 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 use e2-standard-2 como su 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 causaría una falla.

  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 dirija a la arquitectura requerida.

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

El uso de containerd 2.0 con una imagen de esquema de Docker v1 hace que falle la extracción de imágenes, ya que containerd 2.0 quitó la compatibilidad con la extracción de imágenes de esquema 1 de Docker en GKE 1.33. Cuando este problema es la causa del error de extracción de la imagen, es posible 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 resolver este problema, identifica y migra estas imágenes siguiendo las instrucciones que se indican en Migra desde imágenes de Docker Schema 1.

¿Qué sigue?