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:
- Consulta el estado y los eventos de los pods.
- Entender el significado de los estados.
- Usa los mensajes de eventos para encontrar la causa del error de extracción de imágenes.
- 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:
En la Trusted Cloud consola, ve a la página Cargas de trabajo.
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.
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.
En la página Detalles del pod, haz clic en la pestaña Eventos.
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:
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.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
oUnknown
.
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 | |
|
|
|
|
Conectividad de red | |
|
|
|
|
|
|
No se ha encontrado la imagen | |
|
|
Tiempo de espera de la imagen | |
|
|
Esquema incompatible | |
|
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:
En la Trusted Cloud consola, ve a la página Explorador de registros.
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.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:
- Verifica el acceso a la imagen.
- Verifica la configuración de imagePullSecret y la especificación de Deployment.
- Verifica que la cuenta de servicio del nodo esté activa.
- Verifica el ámbito de acceso del nodo al repositorio privado de Artifact Registry
- 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 Forbidden
error 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.
- Sigue las instrucciones de la documentación de gestión de identidades y accesos para ver los roles asignados a tu cuenta de servicio.
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 comandogcloud 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.
- Sigue las instrucciones de la documentación de gestión de identidades y accesos para ver los roles asignados a tu cuenta de servicio.
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 comandogcloud 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 comandogcloud 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
Busca el nombre de la cuenta de servicio que usan tus nodos:
En la Trusted Cloud consola, ve a la página Clusters.
En la lista de clústeres, haga clic en el nombre del clúster que quiera inspeccionar.
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:
- Haz clic en la pestaña Nodos.
- 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.
- 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 esdefault
, tus nodos usan una cuenta de servicio personalizada.
Comprueba si la cuenta de servicio del nodo está inhabilitada:
En la Trusted Cloud consola, ve a la página Cuentas de servicio.
Selecciona un proyecto.
Busca el nombre de la cuenta de servicio que has identificado en el paso anterior.
Consulta la columna Estado de esa cuenta. Si la cuenta de servicio está inhabilitada, tendrá el estado
Disabled
.
gcloud
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 esdefault
, tus nodos usan una cuenta de servicio personalizada.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:
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.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.
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 ámbitodevstorage.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:
- Investiga la resolución de DNS.
- Investiga la configuración de tu cortafuegos.
- Investiga la conectividad a Internet de los endpoints de registro externos.
- 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:
- 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.
- 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.
- 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.
- 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:
Usa SSH para conectarte al nodo que tiene problemas:
gcloud compute ssh NODE_NAME --zone=ZONE_NAME
Haz los cambios siguientes:
NODE_NAME
: el nombre del nodo.ZONE_NAME
: la zona de Compute Engine en la que se creó el nodo.
Envía los registros más recientes de los servicios
kube-node-installation.service
ykube-node-configuration.service
a archivos de texto llamadoskube-node-installation_status.txt
ykube-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
Revisa el contenido de
kube-node-installation_status.txt
ykube-node-configuration_status.txt
y los archivos. Si vesi/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:
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.
Accede a los registros de flujo de VPC:
En la Trusted Cloud consola, ve a la página Explorador de registros.
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.
Si encuentra alguna regla de cortafuegos que esté bloqueando el tráfico necesario, actualícela.
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:
En la Trusted Cloud consola, ve a Rutas.
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:
- 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.
- Usa un dominio admitido.
Revisa tus políticas de cortafuegos:
En la Trusted Cloud consola, ve a Políticas de cortafuegos.
Verifica si tienes alguna regla que bloquee el tráfico TCP de salida en el puerto
443
a199.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 IP199.36.153.4/30
y199.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 puerto443
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.
Si usas Artifact Registry, asegúrate de que tu entorno cumpla los requisitos para usar Artifact Registry con aislamiento de red.
Comprueba que las direcciones IP virtuales (VIPs) (
199.36.153.4/30
o199.36.153.8/30
) tengan configuradas rutas de VPC:En la Trusted Cloud consola, ve a Redes de VPC.
En la columna Nombre, haga clic en predeterminado.
En la página de detalles de la red de VPC, haz clic en la pestaña Rutas.
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:
- 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á.
- 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.
- Si tu clúster usa aislamiento de red, prueba las siguientes soluciones:
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:
- 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.
- 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. - Reduce el tamaño de la imagen. Por ejemplo, puedes mover algunos datos de las imágenes de contenedor a volúmenes persistentes.
- 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.
- 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.
- 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.
- 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.
- 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:
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
.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
.Compara los valores de los campos
architecture
yMACHINE_TYPE
y asegúrate de que ambos valores sean compatibles. Por ejemplo, si la imagen tiene una arquitecturaamd64
, sería compatible con un grupo de nodos que utilicee2-standard-2
como tipo de máquina. Sin embargo, si el grupo de nodos usarat2a-standard-1
(un tipo de máquina basado en Arm), este tipo de máquina provocaría un error.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
Si no encuentras una solución a tu problema en la documentación, consulta la sección Obtener asistencia para obtener más ayuda, incluidos consejos sobre los siguientes temas:
- Abrir un caso de asistencia poniéndose en contacto con el equipo de Atención al Cliente de Cloud.
- Obtener asistencia de la comunidad haciendo preguntas en Stack Overflow
y usando la etiqueta
google-kubernetes-engine
para buscar problemas similares. También puedes unirte al#kubernetes-engine
canal de Slack para obtener más ayuda de la comunidad. - Abrir errores o solicitudes de funciones mediante el seguimiento de problemas público.