Solucionar problemas de Cloud Run

En esta página se describe cómo solucionar los errores que pueden surgir al usar Cloud Run. Personalized Service Health publica todos los incidentes de Cloud Run que se derivan de la infraestructura Google Cloud subyacente para identificar las interrupciones del servicio Google Cloud que afectan a tus proyectos. También deberías configurar alertas sobre eventos de estado del servicio personalizado. Para obtener información sobre los incidentes que afectan a todos los servicios de Google Cloud , consulta el panel de control Google Cloud Estado del servicio.

Consulta si hay problemas o abre nuevos problemas en las herramientas públicas de seguimiento de incidencias.

Si recibes otros mensajes de error que no aparecen en esta página, consulta los problemas conocidos de Cloud Run. Si sigues teniendo problemas incluso después de seguir los pasos de esta guía, ponte en contacto con el equipo de Asistencia.

Consulta las siguientes secciones para obtener información sobre cómo resolver problemas en Cloud Run:

Errores de implementación

En esta sección se describen los errores de implementación habituales en Cloud Run y los métodos para solucionarlos.

No se ha podido iniciar el contenedor

Se produce el siguiente error al intentar implementar:

Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

Para solucionar este problema, sigue estos pasos:

  1. Verifica que puedes ejecutar tu imagen de contenedor de forma local. Si la imagen de tu contenedor no se puede ejecutar de forma local, primero debes diagnosticar y solucionar el problema de forma local.

  2. Comprueba si tu contenedor está escuchando solicitudes en el puerto correcto. Tu contenedor debe recibir solicitudes en el puerto definido por Cloud Run y proporcionado en la variable de entorno PORT. Para obtener instrucciones sobre cómo especificar el puerto,consulta Configurar contenedores para servicios.

  3. Comprueba si tu contenedor está escuchando en todas las interfaces de red, que se suelen denotar como 0.0.0.0. En concreto, tu contenedor no debe escuchar en 127.0.0.1.

  4. Verifica que tu imagen de contenedor se haya compilado para Linux de 64 bits, tal como se indica en el contrato de tiempo de ejecución del contenedor.

  5. Usa Cloud Logging para buscar errores de aplicaciones en los registros de stdout o stderr. También puedes buscar los fallos registrados en Informes de errores.

    Es posible que tengas que actualizar tu código o la configuración de la revisión para corregir errores o fallos. También puedes solucionar problemas de tu servicio a nivel local.

Error de importación del contenedor

Se produce el siguiente error al intentar implementar:

The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.

Para solucionar este problema, sigue estos pasos:

  1. Asegúrese de que el sistema de archivos del contenedor no incluya caracteres que no sean UTF-8.

  2. Algunas imágenes Docker basadas en Windows usan capas externas. El plano de control de Cloud Run no admite capas externas. Para resolver este problema, prueba a definir la marca --allow-nondistributable-artifacts en el daemon de Docker.

La función no está disponible

Se produce el siguiente error al llamar a la API Admin de Cloud Run:

The feature is not supported in the declared launch stage

Este error se produce cuando llamas directamente a la API de administrador de Cloud Run y usas una función beta sin especificar una anotación o un campo de fase de lanzamiento.

Para solucionar este problema, añade el campo de fase de lanzamiento a las solicitudes.

Consulta los siguientes ejemplos para añadir referencias de fase de lanzamiento al usar la API REST v1 o v2:

  • Anotación de la fase de lanzamiento en una solicitud de cliente mediante JSON y la API REST v1:

      "annotations": {
    "run.googleapis.com/launch-stage": "BETA"
  }

  • Referencia de LaunchStage a una solicitud de cliente mediante JSON y la API REST v2:

    "launchStage": "BETA"

  • Anotación de la fase de lanzamiento de una solicitud de servicio mediante YAML y la API REST v1:

    kind: Service
metadata:
annotations:
  run.googleapis.com/launch-stage: BETA

No se ha encontrado el usuario root

Se produce el siguiente error cuando las claves de encriptado gestionadas por el cliente se especifican mediante un parámetro --key:

ERROR: "User \"root\""not found in /etc/passwd

Para solucionar este problema, especifica USER 0 en lugar de USER root en el archivo Dockerfile.

Se elimina la cuenta de servicio predeterminada de Compute Engine

Se produce el siguiente error durante la implementación:

ERROR: (gcloud.run.deploy) User EMAIL_ADDRESS does not have permission to access namespace NAMESPACE_NAME (or it may not exist): Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).

Este problema se produce en cualquiera de los siguientes casos:

  • La cuenta de servicio predeterminada de Compute Engine no existe en el proyecto y no se ha especificado ninguna cuenta de servicio con la marca --service-account en el momento de la implementación.

  • El desarrollador o la entidad que despliega el servicio no tiene los permisos necesarios para que la cuenta de servicio predeterminada de Compute Engine se pueda desplegar.

Para solucionar este problema, sigue estos pasos:

  1. Especifica una cuenta de servicio con la marca --service-account:

    gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT

  2. Verifica que la cuenta de servicio que especifiques tenga los permisos necesarios para desplegar.

Para comprobar si el agente de servicio predeterminado de Compute Engine existe en tu Google Cloud proyecto, sigue estos pasos:

  1. En la consola, ve a la página Permisos de Gestión de Identidades y Accesos: Google Cloud

    Ve a Permisos.

  2. Selecciona la casilla Incluir concesiones de roles proporcionadas por Google.

  3. En la lista Principales, busca el ID del agente de servicio de Compute Engine, que sigue el formato PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Problemas con la cuenta de servicio de Cloud Build

El siguiente error se produce durante las implementaciones de origen cuando la cuenta de servicio de Cloud Build no tiene los permisos necesarios o está inhabilitada:

ERROR: (gcloud.run.deploy) NOT_FOUND: Build failed. The service has encountered an internal error. Please try again later. This command is authenticated as EMAIL_ADDRESS which is the active account specified by the [core/account] property.

Cloud Build ha cambiado el comportamiento predeterminado de cómo usa las cuentas de servicio en los proyectos nuevos. Puedes consultar más detalles en el artículo sobre el cambio en la cuenta de servicio predeterminada de Cloud Build. Como resultado de este cambio, es posible que los proyectos nuevos que se desplieguen en Cloud Run desde el código fuente por primera vez utilicen una cuenta de servicio de Cloud Build predeterminada con permisos insuficientes para desplegar desde el código fuente.

Para solucionar este problema, sigue estos pasos:

  • Consulta las directrices de Cloud Build sobre los cambios en la cuenta de servicio predeterminada y rechaza estos cambios.

  • Asigna el rol Cloud Run Builder (roles/run.builder) a la cuenta de servicio de compilación.

El agente de servicio de Cloud Run no tiene permiso para leer la imagen

Se produce el siguiente error cuando intentas implementar desde un proyecto con una imagen almacenada en Artifact Registry, usando el dominio gcr.io en otro proyecto:

Google Cloud Run Service Agent must have permission to read the image, gcr.io/PROJECT-ID/IMAGE-NAME. Ensure that the provided container image URL is correct and that above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that PROJECT-ID/IMAGE-NAME is not in project PROJECT-ID-2. Permission must be granted to the Google Cloud Run Service Agent from this project.

También puede aparecer el siguiente error al intentar implementar desde un proyecto con una imagen almacenada en Artifact Registry en otro proyecto:

ERROR: (gcloud.run.deploy) PERMISSION_DENIED: User must have permission to read
the image, REGION.pkg.dev/PROJECT_ID/ARTIFACT_REGISTRY_REPO/IMAGE:latest. Ensure that the provided container image URL is correct
and that the above account has permission to access the image. If you just enabled
the Cloud Run API, the permissions might take a few minutes to propagate. Note
that the image is from project PROJECT_ID, which is not the same as
this project PROJECT_ID.

Para solucionar este problema, sigue estas recomendaciones:

  • Sigue las instrucciones para desplegar imágenes de contenedor de otros Google Cloud proyectos para asegurarte de que tus principales tienen los permisos necesarios.

  • Este problema también puede producirse si el proyecto está en un perímetro de Controles de Servicio de VPC con una restricción en la API Cloud Storage que prohíbe las solicitudes del agente de servicio de Cloud Run. Para corregir este problema, haz lo siguiente:

    1. Abre Explorador de registros en la Google Cloud consola. No uses la página Registros de la página de Cloud Run:

      Ir a Explorador de registros

    2. Introduce el siguiente texto en el campo de consulta:

      protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
severity=ERROR
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
protoPayload.authenticationInfo.principalEmail="service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com"

    3. Si ves alguna entrada de registro después de usar esta consulta, examínala para determinar si tienes que actualizar tus políticas de Controles de Servicio de VPC. Puede que indiquen que debes añadir service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com a una política de acceso ya creada.

Faltan permisos para las implementaciones de origen

Al implementar desde la fuente, pueden producirse los siguientes errores:

ERROR: (gcloud.run.deploy) EMAIL_ADDRESS does not have permission
to access namespaces instance PROJECT_ID (or it may not exist): Google
Cloud Run Service Agent does not have permission to get access tokens for
the service account SERVICE_ACCOUNT. Please give SERVICE_ACCOUNT
permission iam.serviceAccounts.getAccessToken on the service account.

Alternatively, if the service account is unspecified or in the same project you
are deploying in, ensure that the Service Agent is assigned the Google
Cloud Run Service Agent role roles/run.serviceAgent. This
command is authenticated as EMAIL_ADDRESS, which is the active account
specified by the [core/account] property.

Cada servicio de Cloud Run está asociado a una cuenta de servicio que actúa como su identidad cuando el servicio accede a otros recursos. Esta cuenta de servicio puede ser la cuenta de servicio predeterminada (PROJECT_NUMBER-compute@developer.gserviceaccount.com) o una cuenta de servicio gestionada por el usuario.

En entornos en los que varios servicios acceden a diferentes recursos, puedes usar identidades por servicio con diferentes cuentas de servicio gestionadas por el usuario en lugar de la cuenta de servicio predeterminada.

Para resolver este problema, asigna a la cuenta de implementación el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser) en la cuenta de servicio que se usa como identidad de servicio. Este rol predefinido contiene el permiso iam.serviceAccounts.actAs, que es necesario para adjuntar una cuenta de servicio al servicio o a la revisión. A los usuarios que crean una cuenta de servicio gestionada por el usuario se les concede automáticamente el permiso iam.serviceAccounts.actAs. Sin embargo, otros implementadores deben tener este permiso concedido por el usuario que crea la cuenta de servicio gestionada por el usuario.

Para obtener más información sobre los requisitos de acceso de las cuentas de servicio que crees, consulta el artículo Recibir recomendaciones para crear cuentas de servicio específicas.

El usuario no tiene permisos suficientes para completar las implementaciones de fuentes

Se produce el siguiente error cuando la cuenta de implementación no tiene los permisos necesarios en tu proyecto:

ERROR: (gcloud.run.deploy) 403 Could not upload file EMAIL_ADDRESS does
not have storage.objects.create access to the Google Cloud Storage object. Permission storage.objects.create denied on resource (or it may not exist). This
command is authenticated as EMAIL_ADDRESS which is the active account.

Para solucionar este error, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos:

Error al desplegar un servicio de Cloud Run desde otros proyectos de Google Cloud

Se produce el siguiente error al implementar un servicio de Cloud Run desde un proyecto de origen en un proyecto de destino:

Failed to create service.
Operation failed due to missing permissions.

Google Cloud Run Service Agent does not have permission to get access
tokens for the service account SERVICE_ACCOUNT. Please give
SERVICE_ACCOUNT permission iam.serviceAccounts.getAccessToken
on the service account. Alternatively, if the service account is unspecified or
in the same project you are deploying in, ensure that the Service Agent is
assigned the Google Cloud Run Service Agent role roles/run.serviceAgent.

Para solucionar este problema, sigue estos pasos:

  1. Asigna el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser) a la cuenta de servicio que uses como identidad de servicio en tu proyecto de destino.

  2. Asigna el rol Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) a la cuenta de servicio de Cloud Run en el proyecto de destino. Añade el correo del agente de servicio de Cloud Run (service-PROJECT_NUMBER@SERVICE_DOMAIN.iam.gserviceaccount.com) como principal del proyecto de origen.

  3. Desactiva la política de organización iam.disableCrossProjectServiceAccountUsage.

Para obtener instrucciones detalladas, consulta Configurar la identidad de servicio para los servicios.

Errores al desplegar el código fuente de Python en Cloud Run

Cuando despliegas un servicio de Cloud Run desde el código fuente con el tiempo de ejecución de Python, se produce uno de los siguientes errores:

  • Revision REVISION_NAME is not ready and cannot serve traffic.
The user provided container failed to start and listen on port defined by PORT=8080
environment variable within the allocated timeout. This can happen if the port is
misconfigured or if the timeout is too short. The healthcheck timeout can be extended.
  • La implementación se realiza correctamente, pero aparecen códigos de error HTTP 500 en los registros.

El paquete de compilación de Python define el punto de entrada predeterminado para los despliegues de origen de Cloud Run. En Python 3.13 y versiones posteriores, el buildpack de Python define el punto de entrada en función de la configuración del servicio web en el archivo requirements.txt. Si no especificas un servidor web o un framework en el archivo requirements.txt o usas la versión 3.12 o una anterior de Python, el paquete de compilación de Python define el punto de entrada predeterminado como gunicorn -b :8080 main:app. Para obtener más información, consulta Crear una aplicación de Python.

Puedes solucionar este problema de varias formas. Por ejemplo, puede especificar uno de los siguientes servidores web en su archivo requirements.txt:

  • gunicorn:

      # https://pypi.org/project/gunicorn/
  gunicorn==21.2.0

  • fastapi y uvicorn:

    
# https://pypi.org/project/fastapi
fastapi[standard]==0.116.1

# https://pypi.org/project/uvicorn
uvicorn==0.35.0

También puedes seguir cualquiera de estos pasos para resolver los errores de implementación:

  • Especifica el punto de entrada ejecutando el siguiente comando de implementación de origen:

    gcloud run deploy SERVICE --source .  --set-build-env-vars GOOGLE_ENTRYPOINT="ENTRYPOINT"

    Haz los cambios siguientes:

    • SERVICE: el nombre del servicio en el que quieras implementar la aplicación.
    • ENTRYPOINT: el punto de entrada predeterminado que quieras usar para tu código fuente.

  • Usa un Procfile para definir un punto de entrada.

Errores de publicación

En esta sección se enumeran los problemas que puede encontrar al servir anuncios y se ofrecen sugerencias para solucionarlos.

HTTP 404: No encontrado

El siguiente problema se produce durante el servicio:

`HTTP 404`:Not found

Es posible que se produzcan errores HTTP 404 en los siguientes casos:

  1. Si la URL de la solicitud o el código de la aplicación no son correctos, se devuelven errores 404. Para solucionar este problema, sigue estos pasos:

    1. Comprueba si la URL que has solicitado es correcta. Puedes verificar la URL en la página de detalles del servicio de la Google Cloud consola o ejecutando el siguiente comando:

      gcloud run services describe SERVICE_NAME | grep URL

    2. Inspecciona dónde devuelve tu aplicación códigos de error 404. Si tu aplicación devuelve 404, puedes encontrarlo en Cloud Logging. Además, comprueba que la aplicación no devuelva un código de error 404 cuando la ejecutes de forma local.

    3. Asegúrate de que tu aplicación no empiece a escuchar en el puerto configurado antes de que esté lista para recibir solicitudes.

  2. La solicitud no llega al contenedor, lo que provoca un error 404 en los siguientes casos:

    • Una solicitud no cumple la restricción de red especificada, sobre todo cuando la configuración de entrada del servicio de Cloud Run se establece en Internal (Interno) o Internal and Cloud Load Balancing (Interno y balanceo de carga de Cloud).

    • La URL predeterminada run.app del servicio de Cloud Run está inhabilitada y un cliente intenta acceder al servicio a través de esa URL run.app.

    En ambos casos, no encontrarás el error 404 en Cloud Logging, aunque apliques el siguiente filtro:

    resource.type="cloud_run_revision"
log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests"
httpRequest.status=404

  3. Con los mismos ajustes de entrada, Controles de Servicio de VPC puede bloquear la solicitud en función del contexto de la persona que llama, incluido el proyecto y la dirección IP. Para comprobar si se ha infringido una política de Controles de Servicio de VPC, sigue estos pasos:

    1. Abre Explorador de registros en la Google Cloud consola:

      Ir a Explorador de registros

    2. Introduce el siguiente texto en el campo de consulta:

      resource.type="audited_resource"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
resource.labels.method="run.googleapis.com/HttpIngress"

    3. Si ves alguna entrada de registro después de usar esta consulta, examínala para determinar si tienes que actualizar tus políticas de Controles de Servicio de VPC.

  4. Accede al endpoint de tu servicio con un balanceador de carga mediante el tiempo de ejecución de Python. Para solucionar este problema, verifique la máscara de URL de su balanceador de carga y asegúrese de que la ruta de URL que especifique para el balanceador de carga coincida con la ruta de su código fuente de Python.

No hay instancias de contenedor disponibles

Se produce el siguiente error durante el servicio:

HTTP 429
The request was aborted because there was no available instance.
The Cloud Run service might have reached its maximum container instance
limit or the service was otherwise not able to scale to incoming requests.
This might be caused by a sudden increase in traffic, a long container startup time or a long request processing time.

Para solucionar este problema, compruebe la métrica Número de instancias de contenedor de su servicio y considere la posibilidad de aumentar este límite si su uso se acerca al máximo. Para obtener más información, consulta Definir el número máximo de instancias de los servicios y, si necesitas más instancias, solicita un aumento de cuota.

Cloud Run no ha podido gestionar la tasa de tráfico

El siguiente error se produce durante el servicio o cuando el servicio no ha alcanzado su límite máximo de instancias de contenedor:

HTTP 500
The request was aborted because there was no available instance

Para solucionar este problema, sigue estos pasos:

  1. Aborda las siguientes posibles causas:

    • Un aumento repentino y enorme del tráfico.
    • Un tiempo de arranque en frío prolongado.
    • Un tiempo de procesamiento de solicitudes largo o un aumento repentino del tiempo de procesamiento de solicitudes.
    • El servicio alcanza el límite máximo de instancias de contenedor (HTTP 429).
    • Factores transitorios atribuidos al servicio de Cloud Run.

  2. Implementa un tiempo de espera exponencial y reintentos para las solicitudes que el cliente no debe descartar. Un aumento breve y repentino del tráfico o del tiempo de procesamiento de las solicitudes solo se puede ver en Cloud Monitoring si amplías la resolución a 10 segundos.

  3. Si la causa principal del problema es un periodo de errores transitorios elevados atribuibles únicamente a Cloud Run, ponte en contacto con el equipo de Asistencia.

La operación no se ha implementado

Se produce el siguiente error cuando especificas un REGION incorrecto al invocar tu trabajo de Cloud Run, por ejemplo, cuando implementas un trabajo en la región asia-southeast1 e invocas tu trabajo con southeast1-asia o asia-southeast:

HTTP 501
Operation is not implemented, or supported, or enabled.

Para ver la lista de regiones admitidas, consulta Ubicaciones de Cloud Run.

No se han encontrado las credenciales predeterminadas

El siguiente error se produce cuando tu aplicación no se autentica correctamente porque faltan archivos, las rutas de las credenciales no son válidas o las asignaciones de las variables de entorno son incorrectas:

HTTP 503: System.InvalidOperationException System.InvalidOperationException your Default
credentials were not found.

Para solucionar este problema, sigue estos pasos:

  1. Instala e inicializa gcloud CLI.

  2. Configura las credenciales predeterminadas de la aplicación (ADC) con las credenciales asociadas a tu cuenta de Google. Configura ADC mediante:

      gcloud auth application-default login

    Aparecerá una pantalla de inicio de sesión. Después de iniciar sesión, tus credenciales se almacenan en el archivo de credenciales local, que usa ADC.

  3. Usa la variable de entorno GOOGLE_APPLICATION_CREDENTIALS para proporcionar la ubicación de un archivo JSON de credenciales en tu proyecto Google Cloud .

    Para obtener más información, consulta Configurar credenciales predeterminadas de la aplicación.

Las instancias de contenedor superan los límites de memoria

Se produce el siguiente error HTTP 500 o HTTP 503 durante el servicio en Cloud Logging:

While handling this request, the container instance was found to be using too much memory and was terminated. This is likely to cause a new container instance to be used for the next request to this revision. If you see this message frequently, you may have a memory leak in your code or may need more memory. Consider creating a new revision with more memory.

Para solucionar este problema, sigue estos pasos:

  1. Determina si tus instancias de contenedor están superando la memoria disponible. Busca errores relacionados en los registros varlog/system.
  2. Si las instancias superan la memoria disponible, considera la posibilidad de aumentar el límite de memoria.

En Cloud Run, los archivos escritos en el sistema de archivos local se tienen en cuenta para la memoria disponible. Esto también incluye los archivos de registro que se escriben en ubicaciones distintas de /var/log/* y /dev/log.

No se pueden procesar algunas solicitudes debido a una configuración de simultaneidad alta

Se produce el siguiente error cuando las instancias de tu contenedor usan una carga de CPU alta para procesar solicitudes y, como resultado, no pueden procesar todas las solicitudes:

HTTP 503
The Cloud Run service probably has reached its maximum container instance limit. Consider increasing this limit.

Para solucionar este problema, sigue estos pasos:

  1. Aumenta el número máximo de instancias de contenedor de tu servicio.

  2. Reduce la concurrencia del servicio. Para obtener más información, consulta Definir el número máximo de solicitudes simultáneas por instancia.

Errores de Cloud Logging relacionados con cancelaciones de solicitudes de colas pendientes

Se produce uno de los siguientes errores cuando Cloud Run no puede aumentar la escala lo suficientemente rápido para gestionar el tráfico:

  • The request was aborted because there was no available instance:
severity=WARNING ( Response code: 429 ) Cloud Run cannot
scale due to the max-instances limit you set
during configuration.

  • severity=ERROR ( Response code: 500 ) Cloud Run intrinsically
cannot manage the rate of traffic.

Para solucionar este problema, sigue estos pasos:

  1. Aborda las causas principales que pueden provocar errores de escalado, como las siguientes:

    • Un aumento repentino y enorme del tráfico.
    • Tiempo de arranque en frío prolongado.
    • Tiempo de procesamiento de solicitudes largo.
    • Tasa de errores de código fuente alta.
    • Alcanzar el límite máximo de instancias e impedir que el sistema se escale.
    • Factores transitorios atribuidos al servicio de Cloud Run.

    Para obtener más información sobre cómo resolver problemas de escalado y optimizar el rendimiento, consulta las sugerencias generales para desarrolladores.

  2. En el caso de los servicios o las funciones basados en activadores HTTP, el cliente debe implementar un retroceso exponencial y reintentos para las solicitudes que no se deban descartar. Si activas servicios desde Workflows, puedes usar la sintaxis try/retry para hacerlo.

  3. En el caso de los servicios o funciones en segundo plano o basados en eventos, Cloud Run admite la entrega al menos una vez. Aunque no habilites explícitamente los reintentos, Cloud Run vuelve a enviar el evento automáticamente y reintenta la ejecución. Para obtener más información, consulta Reintentar funciones basadas en eventos.

  4. Si tienes problemas con los arranques en frío, configura las instancias mínimas para reducir el número de arranques en frío con una mayor implicación en la facturación.

  5. Si la causa principal del problema es un periodo de errores transitorios elevados atribuidos únicamente a Cloud Run o si necesitas ayuda con tu problema, ponte en contacto con el equipo de Asistencia.

Firma del token de identidad redactada por Google

Se produce el siguiente error durante las fases de desarrollo y prueba:

SIGNATURE_REMOVED_BY_GOOGLE

Este error puede producirse en los siguientes casos:

  • El usuario inicia sesión con la CLI de Google Cloud o Cloud Shell.

  • El usuario genera un token de ID mediante comandos gcloud.

  • El usuario intenta usar el token de ID para invocar un servicio de Cloud Run no público.

Este es el comportamiento predeterminado esperado. Google elimina la firma del token debido a problemas de seguridad para evitar que ningún servicio de Cloud Run no público reproduzca tokens de ID generados de esta forma.

Para solucionar este problema, invoca tu servicio privado con un nuevo token de ID. Para obtener más información, consulta Probar tu servicio privado.

Advertencia de OpenBLAS en los registros

Si usas bibliotecas basadas en OpenBLAS, como NumPy, con el entorno de ejecución de primera generación, es posible que veas la siguiente advertencia en tus registros:

OpenBLAS WARNING - could not determine the L2 cache size on this system,
assuming 256k`

La advertencia de OpenBLAS se produce cuando el sandbox del contenedor que usa el entorno de ejecución de primera generación no expone funciones de hardware de bajo nivel. Esta advertencia no afecta a tu servicio. Para evitar que se registren advertencias de OpenBLAS, cambia al entorno de ejecución de segunda generación.

Spark falla al obtener la dirección IP de la máquina a la que enlazarse

Si Spark falla al obtener la dirección IP de la máquina de enlace, se produce uno de los siguientes errores:

assertion failed: Expected hostname (not IP) but got <IPv6 ADDRESS>
 
assertion failed: Expected hostname or IPv6 IP enclosed in [] but got <IPv6 ADDRESS>

Para solucionar este problema, asigna el valor 127.0.0.1 a la variable de entorno SPARK_LOCAL_IP en tu archivo Dockerfile. Por ejemplo, ENV SPARK_LOCAL_IP="127.0.0.1". Si no defines la variable de entorno SPARK_LOCAL_IP, se usará su contraparte IPv6 en lugar de localhost. Además, Spark no reconoce la variable de entorno definida como RUN export SPARK_LOCAL_IP="127.0.0.1".

No se puede acceder a los archivos mediante NFS

Error Medida correctora sugerida
mount.nfs: Protocol not supported Faltan algunas imágenes base, como debian y adoptopenjdk/openjdk11, en la dependencia nfs-kernel-server.
mount.nfs: Connection timed out Si se agota el tiempo de espera de la conexión, asegúrate de que estás proporcionando la dirección IP correcta de la instancia de filestore.
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE Si el servidor ha denegado el acceso, asegúrese de que el nombre del recurso compartido de archivos sea correcto.

No se puede acceder a los archivos mediante Cloud Storage FUSE

Consulta la guía de solución de problemas de Cloud Storage FUSE.

Latencia alta cuando el uso de CPU es bajo

Es posible que tu servicio experimente latencias de solicitud altas o que no pueda aumentar la capacidad en condiciones de carga, aunque Cloud Monitoring muestre que la utilización media de la CPU está muy por debajo del objetivo de escalado típico del 60 %.

Posible causa:

Esto puede ocurrir si tu aplicación es de un solo hilo para tareas vinculadas a la CPU, pero se ha implementado en una instancia con varias vCPUs. Es posible que tu aplicación alcance el máximo de un núcleo de vCPU mientras que los demás núcleos permanezcan inactivos en su mayoría. El escalador automático de Cloud Run usa el uso medio de CPU en todas las vCPUs. En estos casos, la media puede ser baja, lo que impide el escalado basado en la CPU.

Soluciones:

  • En el caso de las aplicaciones de un solo subproceso:
    • Te recomendamos que configures tu servicio con 1 vCPU si se pueden cumplir sus requisitos de memoria (consulta Límites de memoria y mínimos de CPU). De esta forma, las métricas de utilización de la CPU reflejan la carga con precisión.
    • Si se necesitan varias vCPUs debido a que las necesidades de memoria son elevadas y superan los límites de 1 vCPU, es probable que el autoescalado basado en CPU sea menos eficaz. En este caso, reduce el ajuste de simultaneidad máxima para fomentar el escalado antes en función del rendimiento de las solicitudes. Consulta Configuración de la simultaneidad.
  • En el caso de las configuraciones con varias vCPUs, asegúrate de que tu aplicación esté diseñada para utilizar de forma eficaz todas las vCPUs asignadas (por ejemplo, mediante varios procesos o hilos de trabajo).

Errores de conectividad y seguridad

En esta sección se describen los errores de conectividad y seguridad habituales en Cloud Run, así como los métodos para solucionarlos.

El cliente no está autenticado correctamente

Se produce el siguiente error durante el servicio:

HTTP 401: The request was not authorized to invoke this service

Para solucionar este problema, sigue estos pasos:

  1. Si una cuenta de servicio invoca tu servicio de Cloud Run, define la reclamación de audiencia (aud) del token de ID firmado por Google como lo siguiente:

    • Si asignas el valor aud a la URL del servicio receptor con el formato https://SERVICE.run.app o https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION, tu servicio debe requerir autenticación. Invoca tu servicio de Cloud Run mediante la URL de Cloud Run o a través de una URL de balanceador de carga. Para ver ejemplos de cómo enviar solicitudes autenticadas, consulta Invocar con una solicitud HTTPS.

    • Si asignas el valor aud al ID de cliente de OAuth 2.0 de tipo Aplicación web con el formato nnn-xyz.apps.googleusercontent.com, puedes invocar tu servicio de Cloud Run a través de un balanceador de carga HTTPS protegido por IAP. Recomendamos este enfoque para los balanceadores de carga de aplicaciones respaldados por varios servicios de Cloud Run en diferentes regiones.

    • Si asigna el aud a una audiencia personalizada configurada, use los valores exactos proporcionados. Por ejemplo, si la audiencia personalizada es https://service.example.com, el valor de la reclamación de audiencia también debe ser https://service.example.com.

  2. Asegúrate de que tus solicitudes incluyan un encabezado Authorization: Bearer ID_TOKEN o un encabezado X-Serverless-Authorization: Bearer ID_TOKEN para la autorización personalizada, y de que el token sea un token de ID, no un token de acceso o de actualización. Puede producirse un error 401 en los siguientes casos debido a un formato de autorización incorrecto:

    • El token de autorización tiene un formato no válido.

    • El encabezado de autorización no es un JSON Web Token (JWT) con una firma válida.

    • El encabezado de autorización contiene varios JWTs.

    • Hay varios encabezados de autorización en la solicitud.

    Para comprobar las reclamaciones de un JWT, usa la herramienta jwt.io.

  3. Si obtienes tokens no válidos al usar el servidor de metadatos para obtener tokens de ID y de acceso con el fin de autenticar solicitudes con la identidad de servicio o de trabajo de Cloud Run con un proxy HTTP para enrutar el tráfico de salida, añade los siguientes hosts a las excepciones del proxy HTTP:

    • 169.254.* o 169.254.0.0/16

    • *.google.internal

  4. Un error 401 suele producirse cuando las bibliotecas de cliente de Cloud usan el servidor de metadatos para obtener las credenciales predeterminadas de la aplicación y autenticar las invocaciones de REST o gRPC. Si no defines las excepciones del proxy HTTP, se producirá lo siguiente:

    • Si diferentes Google Cloud cargas de trabajo alojan un servicio o un trabajo de Cloud Run y el proxy HTTP, aunque las bibliotecas cliente de Cloud obtengan las credenciales, la cuenta de servicio asignada a la carga de trabajo del proxy HTTP generará los tokens. Es posible que los tokens no tengan los permisos necesarios para realizar las operaciones de la Google Cloud API. Esto se debe a que la cuenta de servicio obtiene los tokens de la vista del servidor de metadatos de la carga de trabajo del proxy HTTP, en lugar del servicio o del trabajo de Cloud Run.

    • Si el proxy HTTP no está alojado en Google Cloudy enrutas las solicitudes del servidor de metadatos mediante el proxy, las solicitudes de token fallarán y las operaciones de las Google Cloud APIs no se autenticarán.

  5. Vuelve a implementar tu servicio para permitir el acceso público si tu organización lo admite. Esto resulta útil para hacer pruebas.

El cliente no tiene autorización para invocar el servicio

Se produce uno de los siguientes errores al invocar tu servicio:

HTTP 403: The request was not authenticated. Either allow public access or set the proper Authorization header
 
HTTP 403: Forbidden: Your client does not have permission to get URL from this server.

Puede producirse un error 403 cuando el miembro de IAM que se ha usado para generar el token de autorización no tiene el permiso run.routes.invoke. Concede este permiso al usuario que genera el token.

Además, si hay una entrada del error con el formato resource.type = "cloud_run_revision" en Cloud Logging, sigue estos pasos para resolverlo:

  1. Para que cualquier persona pueda invocar tu servicio, actualiza la configuración de gestión de identidades y accesos y haz que el servicio sea público.

  2. Para que solo puedan invocar tu servicio determinadas identidades, invócalo con el token de autorización adecuado:

    • Si un desarrollador o un usuario final invoca tu servicio, concede el permiso run.routes.invoke. Puede conceder este permiso mediante los roles Administrador de Cloud Run (roles/run.admin) e Invocador de Cloud Run (roles/run.invoker).

    • Si una cuenta de servicio invoca tu servicio, asegúrate de que la cuenta de servicio sea miembro del servicio de Cloud Run y asigna el rol de invocador de Cloud Run (roles/run.invoker).

    • Las llamadas que no incluyan un token de autorización pueden provocar el error 403. Si las llamadas con un token de autenticación válido siguen dando el error 403, concede al miembro de IAM que genera el token el permiso run.routes.invoke.

Si se produce un error 403 y no encuentras la entrada de registro resource.type = "cloud_run_revision", puede deberse a que Controles de Servicio de VPC bloquea un servicio de Cloud Run que tiene la configuración de entrada definida en All. Para obtener más información sobre cómo solucionar problemas de denegaciones de Controles de Servicio de VPC, consulta Errores 404.

Error al acceder al servicio desde un navegador web

Se produce el siguiente problema cuando accedes a un servicio de Cloud Run desde un navegador web:

403 Forbidden
Your client does not have permission to get URL from this server.

Cuando invocas un servicio de Cloud Run desde un navegador web, el navegador envía una solicitud GET al servicio. Sin embargo, la solicitud no contiene el token de autorización del usuario que llama. Para solucionar este problema, sigue estos pasos:

  1. Usa Identity-Aware Proxy (IAP) con Cloud Run. IAP te permite establecer una capa de autorización central para las aplicaciones a las que se accede a través de HTTPS. Con IAP, puedes usar un modelo de control de acceso a nivel de aplicación en lugar de cortafuegos a nivel de red. Para obtener más información sobre cómo configurar Cloud Run con IAP, consulta el artículo Habilitar Identity-Aware Proxy para Cloud Run.

  2. Como solución alternativa temporal, accede a tu servicio a través de un navegador web mediante el proxy de Cloud Run en la CLI de Google Cloud. Para crear un proxy de un servicio localmente, ejecuta el siguiente comando:

    gcloud run services proxy SERVICE --project PROJECT-ID

    Cloud Run proxyiza el servicio privado a http://localhost:8080 (o al puerto que especifiques con --port) y proporciona el token de la cuenta activa u otro token que especifiques. Esta es la forma recomendada de probar de forma privada un sitio web o una API en tu navegador. Para obtener más información, consulta Probar servicios privados.

  3. Permite el acceso público a tu servicio. Esto es útil para hacer pruebas o cuando tu servicio es una API o un sitio web públicos.

Conexión cancelada por la otra parte

Se produce uno de los siguientes errores cuando un peer de la red cierra inesperadamente la conexión TCP establecida por la aplicación:

Connection reset by peer
 
asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
 
grpc.StatusRuntimeException: UNAVAILABLE: io exception
 
psycopg.OperationalError: the connection is closed
 
ECONNRESET

Para solucionar este problema, sigue estos pasos:

  • Si quieres realizar tareas en segundo plano con limitación de CPU, usa la opción de facturación basada en instancias.

  • Asegúrate de que te encuentras dentro de los tiempos de espera de las solicitudes salientes. Si tu aplicación mantiene alguna conexión en estado inactivo más allá de este umbral, la pasarela debe cerrar la conexión.

  • De forma predeterminada, la opción de socket TCP keepalive está inhabilitada en Cloud Run. No hay ninguna forma directa de configurar la opción keepalive a nivel de servicio. Para habilitar la opción keepalive en cada conexión de socket, proporcione las opciones de socket necesarias al abrir una nueva conexión de socket TCP, en función de la biblioteca de cliente que utilice para esta conexión en su aplicación.

  • En ocasiones, se restablecen las conexiones salientes debido a actualizaciones de la infraestructura. Si tu aplicación reutiliza conexiones de larga duración, te recomendamos que la configures para que vuelva a establecer las conexiones y así evitar que se reutilice una conexión inactiva.

  • Si utilizas un proxy HTTP para enrutar el tráfico de salida de tus servicios o trabajos de Cloud Run, y el proxy aplica una duración máxima de conexión, es posible que el proxy cierre silenciosamente las conexiones TCP de larga duración, como las que se establecen mediante la agrupación de conexiones. Esto provoca que los clientes HTTP fallen al reutilizar una conexión que ya se ha cerrado. Si tienes previsto enrutar el tráfico de salida a través de un proxy HTTP, debes implementar la validación de conexiones, los reintentos y la retirada exponencial. En el caso de los grupos de conexiones, configure los valores máximos de antigüedad de la conexión, conexiones inactivas y tiempo de espera de inactividad de la conexión.

Tiempos de espera de conexión

Los siguientes errores se producen cuando una aplicación intenta crear una conexión TCP con un host remoto y la conexión tarda demasiado en establecerse:

java.io.IOException: Connection timed out
 
ConnectionError: HTTPSConnectionPool
 
dial tcp REMOTE_HOST:REMOTE_PORT: i/o timeout / context error
 
Error: 4 DEADLINE_EXCEEDED: Deadline exceeded

Para solucionar los problemas de tiempo de espera de la conexión, sigue estos pasos:

  1. Si enruta todo el tráfico de salida a través de una red VPC, ya sea mediante conectores VPC o salida de VPC directa, siga estos pasos:

    • Define todas las reglas de cortafuegos necesarias para permitir el tráfico de entrada de los conectores de VPC.

    • Las reglas de cortafuegos de VPC deben permitir el tráfico de entrada desde los conectores de VPC o la subred de salida de VPC directa para llegar al host o la subred de destino.

    • Asegúrate de que tienes todas las rutas necesarias para permitir que el tráfico se dirija correctamente a los hosts de destino y viceversa. Esto es importante cuando se enruta el tráfico de salida a través del emparejamiento entre redes de VPC o de la conectividad de nube híbrida, ya que los paquetes atraviesan varias redes antes de llegar al host remoto.

  2. Si usas un proxy HTTP para enrutar todo el tráfico de salida de tus servicios o trabajos de Cloud Run, se debe poder acceder a los hosts remotos mediante el proxy.

    El tráfico que se enruta a través de un proxy HTTP puede retrasarse en función de la utilización de recursos del proxy. Si enrutas el tráfico de salida HTTP mediante un proxy, implementa reintentos, un tiempo de espera exponencial o disyuntores.

Configurar excepciones de proxy HTTP

Cuando utilices un proxy HTTP para enrutar el tráfico de salida de tus servicios o trabajos de Cloud Run, añade excepciones para las APIs de Cloud y otros hosts y subredes sin proxy para evitar la latencia, los tiempos de espera de conexión, los restablecimientos de conexión y los errores de autenticación.

Los hosts y las subredes no proxy deben incluir, como mínimo, lo siguiente:

  • 127.0.0.1
  • 169.254.* o 169.254.0.0/16
  • localhost
  • *.google.internal
  • *.googleapis.com

Opcionalmente, los hosts sin proxy pueden incluir lo siguiente:

  • *.appspot.com
  • *.run.app
  • *.cloudfunctions.net
  • *.gateway.dev
  • *.googleusercontent.com
  • *.pkg.dev
  • *.gcr.io

Para definir excepciones de proxy HTTP para la red de salida, configure lo siguiente:

  • Variables de entorno: NO_PROXY o no_proxy.

  • Marca de máquina virtual Java http.nonProxyHosts:

    • No se ha definido la propiedad del sistema https.nonProxyHosts. Esta propiedad del sistema se aplica tanto a HTTP como a HTTPS.

    • La propiedad del sistema http.nonProxyHosts no admite la notación CIDR. Debes usar expresiones de coincidencia de patrones.

Respuesta con formato incorrecto o problema de conexión de la instancia de contenedor

Se produce el siguiente error cuando hay un problema de conexión con una instancia de contenedor:

HTTP 503
The request failed because either the HTTP response was malformed or connection to the instance had an error.

Para solucionar este problema, sigue estos pasos:

  1. Consulta Cloud Logging para ver si se han producido los siguientes errores:

    • Errores de falta de memoria. Si los registros contienen mensajes de error relacionados con instancias de contenedor que superan los límites de memoria, consulta las recomendaciones de la sección Las instancias de contenedor superan los límites de memoria.

    • Fallos de la comprobación de actividad con el siguiente error en los registros:

      LIVENESS HTTP probe failed 1 time consecutively for container CONTAINER_NAME on port 8080. The instance has been shut down.

      Si tu instancia no responde correctamente a la comprobación en el periodo de tiempo de espera, sigue estos pasos:

  2. Si las solicitudes finalizan con el código de error 503 antes de alcanzar el tiempo de espera de la solicitud definido en Cloud Run, actualiza el ajuste del tiempo de espera de la solicitud de tu framework de lenguaje:

  3. En algunos casos, puede producirse un código de error 503 debido a un cuello de botella de la red de nivel inferior, como durante las pruebas de carga. Por ejemplo, si tu servicio enruta el tráfico a través de un conector de acceso a VPC sin servidor, asegúrate de que el conector no supere su umbral de rendimiento siguiendo estos pasos:

    1. Abre Acceso a VPC sin servidor en la Google Cloud consola:

      Ir a Acceso a VPC sin servidor

    2. Comprueba si hay barras rojas en el histograma del gráfico de rendimiento. Si hay una barra roja, considera la posibilidad de aumentar el número máximo de instancias o el tipo de instancia que usa tu conector. También puedes comprimir el tráfico enviado a través de un conector de Acceso a VPC sin servidor.

  4. Si una instancia de contenedor recibe más de 800 solicitudes por segundo, es posible que se agoten los sockets TCP disponibles. Para solucionar este problema, activa HTTP/2 en tu servicio y haz los cambios necesarios para que sea compatible con HTTP/2.

Error de tiempo de espera de la pasarela

El siguiente error se produce cuando tu servicio no devuelve una respuesta en un plazo determinado y la solicitud finaliza:

HTTP 504
The request has been terminated because it has reached the maximum request timeout.

Para obtener más información sobre este error, consulta el contrato de tiempo de ejecución del contenedor.

Para solucionar este problema, sigue estos pasos:

  • Si tu servicio está procesando solicitudes largas, aumenta el tiempo de espera de las solicitudes.

  • Registra y monitoriza los instrumentos para saber dónde dedica tiempo tu aplicación antes de superar el tiempo de espera de solicitud configurado.

  • Las conexiones salientes se restablecen de vez en cuando debido a actualizaciones de la infraestructura. Si tu aplicación reutiliza conexiones de larga duración, te recomendamos que la configures para que vuelva a establecer las conexiones y así evitar que se reutilice una conexión inactiva.

    En función de la lógica o la gestión de errores de tu aplicación, un error 504 puede indicar que tu aplicación está intentando reutilizar una conexión inactiva y que la solicitud se bloquea hasta que se agota el tiempo de espera configurado. Usa una prueba de vivacidad para finalizar una instancia que devuelva errores persistentes.

  • Los errores de falta de memoria que se producen en el código de la aplicación, como java.lang.OutOfMemoryError, no tienen por qué finalizar una instancia de contenedor. Si el uso de memoria no supera el límite de memoria del contenedor, Cloud Run no finalizará la instancia. En función de cómo gestione la aplicación los errores de falta de memoria a nivel de aplicación, es posible que las solicitudes no se completen hasta que superen el tiempo de espera de la solicitud configurado.

    Para finalizar la instancia del contenedor, sigue estos pasos:

    • Configura el límite de memoria de la aplicación para que sea superior al límite de memoria del contenedor.

    • Usa una sonda de vivacidad para ayudar a finalizar una instancia que devuelva errores persistentes.

El dominio personalizado se queda bloqueado durante el aprovisionamiento del certificado

Se produce uno de los siguientes errores al asignar un dominio personalizado:

The domain is available over HTTP.  Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin and to accept HTTP traffic.
 
Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin.

Para solucionar este problema, sigue estos pasos:

  1. Espera al menos 24 horas. El aprovisionamiento del certificado SSL suele tardar unos 15 minutos, pero puede llevar hasta 24 horas.

  2. Verifica que has actualizado correctamente los registros DNS en el registrador de tu dominio con la herramienta dig de la Caja de herramientas de Google Admin. Los registros DNS de tu registrador de dominios deben coincidir con lo que laGoogle Cloud consola te pide que añadas.

  3. Verifica la raíz del dominio de tu cuenta mediante uno de los siguientes métodos:

  4. Comprueba que el certificado del dominio no haya caducado. Para encontrar los límites de vencimiento, usa el siguiente comando:

    echo | openssl s_client -servername 'ROOT_DOMAIN' -connect 'ROOT_DOMAIN:443' 2>/dev/null | openssl x509 -startdate -enddate -noout

La desconexión del cliente no se propaga a Cloud Run

Cuando usas HTTP/1.1 en Cloud Run, los eventos de desconexión del cliente no se propagan al contenedor de Cloud Run.

Para solucionar este problema, usa WebSockets o HTTP/2.0, que propagan las desconexiones de los clientes.