Soluciona problemas de Cloud Run

En esta página, se describe cómo solucionar los problemas que puedes encontrar cuando usas Cloud Run. Personalized Service Health publica todos los incidentes de Cloud Run que provienen de la infraestructura subyacente de Google Cloud para identificar Google Cloud interrupciones del servicio que afectan tus proyectos. También debes considerar configurar alertas en los eventos de Personalized Service Health. Para obtener información sobre los incidentes que afectan a todos los Google Cloud servicios, consulta el panel Google Cloud Service Health.

Verifica si hay problemas existentes o abre problemas nuevos en las herramientas públicas de seguimiento de errores.

Para otros mensajes de error que no aparecen en esta página, consulta Problemas conocidos de Cloud Run. Si sigues encontrando errores incluso después de seguir los pasos de esta guía, comunícate con el equipo de asistencia.

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

Errores en la implementación

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

No se pudo iniciar el contenedor

El siguiente error ocurre cuando intentas realizar una implementación:

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

Para resolver el problema, sigue estos pasos:

  1. Verifica que puedas ejecutar la 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. Verifica si el contenedor está escuchando solicitudes en el puerto correcto. Tu contenedor debe detectar las solicitudes entrantes en el puerto que define Cloud Run y que se proporciona en la variable de entorno PORT. Para obtener instrucciones sobre cómo especificar el puerto,consulta Configura contenedores para servicios.

  3. Verifica si el contenedor escucha en todas las interfaces de red, que suelen denominarse 0.0.0.0. En particular, tu contenedor no debería escuchar en 127.0.0.1.

  4. Verifica que la imagen de contenedor se compile para Linux de 64 bits según lo requiere el contrato de entorno de ejecución de contenedores.

  5. Usa Cloud Logging para buscar errores de aplicación en los registros stdout o stderr. También puedes buscar fallas capturadas en Error Reporting.

    Es posible que debas actualizar el código o la configuración de revisión para corregir errores o fallas. También puedes solucionar problemas de tu servicio de forma local.

Error de importación de contenedores

El siguiente error ocurre cuando intentas realizar una implementación:

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

Para resolver el problema, sigue estos pasos:

  1. Asegúrate de que el sistema de archivos del contenedor no contenga caracteres que no sean utf8.

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

La función no es compatible

El siguiente error ocurre cuando llamas a la API de Cloud Run Admin:

The feature is not supported in the declared launch stage

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

Para resolver este problema, agrega el campo de etapa de lanzamiento a las solicitudes.

Consulta los siguientes ejemplos para agregar referencias de etapa de lanzamiento cuando uses la API de REST v1 o v2:

  • Anotación de etapa de lanzamiento a una solicitud del cliente con JSON y la API de REST v1:

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

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

    "launchStage": "BETA"

  • Anotaciones de etapa de lanzamiento a una solicitud de servicio con YAML y la API de REST v1:

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

No se encontró el usuario root

El siguiente error se produce cuando las claves de encriptación administradas por el cliente se especifican con un parámetro --key:

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

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

Se borra la cuenta de servicio predeterminada de Compute Engine

El siguiente error ocurre 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 ocurre en una de las siguientes situaciones:

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

  • El desarrollador o principal que implementa el servicio no tiene los permisos necesarios para implementar la cuenta de servicio predeterminada de Compute Engine.

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

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

  1. En la consola de Google Cloud, ve a la página Permisos de la administración de identidades y accesos:

    Ir a Permisos

  2. Selecciona la casilla de verificación Incluir asignaciones de funciones 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 cambió el comportamiento predeterminado de la forma en que Cloud Build usa cuentas de servicio en proyectos nuevos. Esto se detalla en Cambio de la cuenta de servicio predeterminada de Cloud Build. Como resultado de este cambio, es posible que los proyectos nuevos que se implementen en Cloud Run desde el código fuente por primera vez usen una cuenta de servicio predeterminada de Cloud Build con permisos insuficientes para la implementación desde la fuente.

Para resolver el problema, sigue estos pasos:

  • Revisa la guía de Cloud Build sobre los cambios en la cuenta de servicio predeterminada y, también, inhabilita estos cambios.

  • Otorga el rol de Creador de Cloud Run (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

El siguiente error ocurre cuando intentas implementar desde un proyecto con una imagen que se almacena en Artifact Registry, con el dominio gcr.io en un proyecto diferente:

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 es posible que veas el siguiente error cuando intentes implementar desde un proyecto mediante una imagen que se almacena en Artifact Registry en un proyecto diferente:

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 resolver este problema, sigue estas recomendaciones:

  • Sigue las instrucciones para implementar imágenes de contenedores de otros Google Cloud proyectos a fin de asegurarte de que las principales tengan los permisos necesarios.

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

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

      Ir al Explorador de registros

    2. Ingresa 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 entradas de registro después de usar esta consulta, examina las entradas de registro para determinar si necesitas actualizar tus políticas de Controles de servicio de VPC. Pueden indicar que necesitas agregar service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com a una política de acceso preexistente.

Faltan permisos para las implementaciones de origen

Los siguientes errores pueden ocurrir cuando se implementa desde la fuente:

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 con una cuenta de servicio que funciona 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 administrada por el usuario.

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

Para resolver este problema, otorga a la cuenta del implementador el rol de usuario de cuenta de servicio (roles/iam.serviceAccountUser) en la cuenta de servicio que se usa como identidad del servicio. Este rol predefinido contiene el permiso iam.serviceAccounts.actAs, que se requiere para conectar una cuenta de servicio al servicio o la revisión. Un usuario que crea una cuenta de servicio administrada por el usuario recibe automáticamente el permiso iam.serviceAccounts.actAs. Sin embargo, el usuario que crea la cuenta de servicio administrada por el usuario debe otorgar este permiso a otros implementadores.

Para obtener más información sobre los requisitos de acceso de las cuentas de servicio nuevas que crees, consulta Obtén recomendaciones para crear cuentas de servicio dedicadas.

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

El siguiente error se produce cuando a la cuenta del implementador le faltan 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 resolver este error, pídele a tu administrador que te otorgue los siguientes roles de Identity and Access Management:

Entrega errores

En esta sección, se enumeran los errores que puedes encontrar al entregar y se proporcionan sugerencias para solucionarlos.

HTTP 404: No encontrado

El siguiente problema ocurre durante la entrega:

Se produce un error HTTP 404.

Para solucionar este problema, sigue estos pasos:

  1. Verifica que la URL que solicitas sea correcta. Para ello, verifica la página de detalles del servicio en la consola de Google Cloud o ejecuta el siguiente comando:

    gcloud run services describe SERVICE_NAME | grep URL

  2. Inspecciona dónde es posible que la lógica de tu aplicación muestre códigos de error 404. Si la app muestra el 404, será visible en Cloud Logging.

  3. Asegúrate de que la app no comience a escuchar en el puerto configurado antes de poder recibir solicitudes.

  4. Verifica que la app no muestre un código de error 404 cuando la ejecutes de forma local.

Se muestra una 404 cuando la configuración de entrada del servicio de Cloud Run está configurada como “Interno” o “Interno y Cloud Load Balancing”, y una solicitud no cumple con los requisitos la restricción de red especificada. Esto también puede ocurrir si la URL run.app predeterminada del servicio de Cloud Run está inhabilitada y un cliente intenta conectarse al servicio en esa URL run.app. En cualquier caso, la solicitud no llega al contenedor y 404 no está presente en Cloud Logging con el siguiente filtro:

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

Con la misma configuración de entrada, es posible que los Controles del servicio de VPC bloqueen la solicitud según el contexto del emisor, incluidos el proyecto y la dirección IP. Para verificar si hay un incumplimiento de la política de los Controles del servicio de VPC, haz lo siguiente:

  1. Abre el explorador de registros en la consola de Google Cloud (no la página Registros en Cloud Run):

    Ir al Explorador de registros

  2. Ingresa 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 entradas de registro después de usar esta consulta, examina las entradas de registro para determinar si necesitas actualizar las políticas de los Controles del servicio de VPC.

También es posible que veas un error 404 cuando accedas a tu extremo de servicio con un balanceador de cargas mediante el entorno de ejecución de Python. Para resolver este problema, verifica la máscara de URL de tu balanceador de cargas y asegúrate de que la ruta de URL que especifiques para el balanceador de cargas coincida con la ruta de tu código fuente de Python.

HTTP 429: No hay instancias de contenedor disponibles

El siguiente error ocurre durante la entrega:

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 resolver este problema, verifica la métrica “Recuento de instancias de contenedor” en tu servicio y considera aumentar este límite si tu uso se acerca al máximo. Consulta Configuración de “instancias máximas” y, si necesitas más instancias, solicita un aumento de la cuota.

HTTP 500: Cloud Run no pudo administrar la tasa de tráfico

El siguiente error ocurre durante la entrega y también puede ocurrir cuando el servicio no alcanzó su límite máximo de instancias de contenedor:

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

Este error puede deberse a uno de los siguientes problemas:

  • Un gran incremento repentino del tráfico.
  • Un tiempo de inicio en frío largo.
  • Un tiempo largo de procesamiento de la solicitud o un aumento repentino en el tiempo de procesamiento de la solicitud.
  • El servicio alcanza su límite máximo de instancias de contenedor (HTTP 429).
  • Factores transitorios atribuidos al servicio de Cloud Run.

Para solucionar este problema, resuelve los problemas mencionados anteriormente.

Además de solucionar estos problemas, como solución alternativa, puedes implementar una retirada exponencial y reintentos para las solicitudes que el cliente no debe descartar.

Ten en cuenta que un aumento corto y repentino en el tráfico o el tiempo de procesamiento de las solicitudes solo puede ser visible en Cloud Monitoring si te acercas a una resolución de 10 segundos.

Cuando la causa raíz del problema es un período de errores transitorios elevados que solo se pueden atribuir a Cloud Run, puedes comunicarte con el equipo de asistencia.

HTTP 501: La operación no está implementada

El siguiente error ocurre durante la entrega:

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

Este problema ocurre cuando especificas un REGION incorrecto mientras invocas tu trabajo de Cloud Run. Por ejemplo, este error puede ocurrir cuando implementas un trabajo en la región asia-southeast1 y lo invocas con southeast1-asia o asia-southeast. Para obtener la lista de las regiones compatibles, consulta Ubicaciones de Cloud Run.

HTTP 503: No se encontraron las credenciales predeterminadas

El siguiente error ocurre durante la entrega:

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

Este problema se produce cuando tu aplicación no se autentica correctamente debido a que faltan archivos, hay rutas de acceso de credenciales no válidas o hay asignaciones incorrectas de variables de entorno.

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 con tu Cuenta de Google. Configura ADC con lo siguiente:

      gcloud auth application-default login

    Aparecerá una pantalla de acceso. Después de acceder, 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 dentro de tu Google Cloud proyecto.

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

HTTP 500 / HTTP 503: Las instancias de contenedor exceden los límites de memoria

El siguiente error ocurre durante la entrega:

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 las instancias de contenedor exceden la memoria disponible. Busca errores relacionados en los registros varlog/system.
  2. Si las instancias exceden la memoria disponible, considera aumentar el límite de memoria.

Ten en cuenta que en Cloud Run, los archivos escritos en el sistema de archivos local se consideran en la memoria disponible. Esto también incluye cualquier archivo de registro que se escriba en ubicaciones distintas de /var/log/* y /dev/log.

HTTP 503: No se pueden procesar algunas solicitudes debido a la alta configuración de simultaneidad

Los siguientes errores ocurren durante la entrega:

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

Este problema se produce cuando las instancias de contenedor usan mucha CPU para procesar las solicitudes y, como resultado, las instancias de contenedor no pueden procesar todas las solicitudes, por lo que algunas muestran un código de error 503.

Para resolver este problema, prueba una o más de las siguientes opciones:

Errores de Cloud Logging relacionados con la anulación de solicitudes pendientes en cola

Uno de los siguientes errores ocurre cuando Cloud Run no escala con la suficiente rapidez como para administrar 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 resolver el problema, sigue estos pasos:

  1. Soluciona las causas raíz que podrían causar fallas de escalamiento, como las siguientes:

    • Un gran incremento repentino del tráfico.
    • Tiempo de inicio en frío largo.
    • Tiempo de procesamiento de solicitudes largo.
    • Tasa alta de errores de código fuente.
    • Alcanzar el límite máximo de instancias y evitar que el sistema escale.
    • Factores transitorios atribuidos al servicio de Cloud Run.

    Para obtener más información sobre cómo resolver problemas de escalamiento y optimizar el rendimiento, consulta Sugerencias generales para el desarrollo.

  2. Para los servicios o funciones basados en activadores HTTP, haz que el cliente implemente una retirada exponencial y vuelva a intentar las solicitudes que no se deben descartar. Si activas servicios desde Workflows, puedes usar la sintaxis try/retry para lograrlo.

  3. Para las funciones o los servicios en segundo plano o controlados por eventos, Cloud Run admite la entrega al menos una vez. Incluso sin habilitar explícitamente el reintento, Cloud Run vuelve a entregar el evento y reintenta la ejecución de forma automática. Consulta Reintenta las funciones controladas por eventos para obtener más información.

  4. Para los problemas relacionados con los inicios en frío, configura instancias mínimas para reducir la cantidad de inicios en frío con una implicación de facturación más alta.

  5. Si la causa raíz del problema es un período de errores transitorios prolongados atribuidos solo a Cloud Run o si necesitas ayuda con tu problema, comunícate con el equipo de asistencia.

Firma de token de identidad oculta por Google

El siguiente error ocurre durante la entrega:

SIGNATURE_REMOVED_BY_GOOGLE

Esto puede ocurrir durante el desarrollo y las pruebas en las siguientes circunstancias:

  1. El usuario accede con Google Cloud CLI o Cloud Shell.
  2. El usuario genera un token de ID mediante los comandos gcloud.
  3. El usuario intenta usar el token de ID para invocar un servicio no público de Cloud Run.

Se diseñó de este modo. Google quita la firma del token debido a problemas de seguridad para evitar que cualquier servicio no público de Cloud Run repita los tokens de ID que se generan de esta manera.

Para resolver este problema, invoca tu servicio privado con un token de ID nuevo. Para obtener más información, consulta Prueba la autenticación en el servicio.

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

Esto no afecta tu servicio. Esta advertencia se produce porque la zona de pruebas del contenedor que usa el entorno de ejecución de primera generación no expone funciones de hardware de bajo nivel. De manera opcional, puedes cambiar al entorno de ejecución de segunda generación si no deseas tener estas advertencias en tus registros.

Spark falla cuando se obtiene una dirección IP de máquina a la que se debe vincular

Uno de los siguientes errores ocurre durante la entrega:

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, sigue estos pasos:

Para cambiar el valor de la variable de entorno y resolver el problema, establece ENV SPARK_LOCAL_IP="127.0.0.1" en tu Dockerfile. En Cloud Run, si la variable SPARK_LOCAL_IP no está configurada, se usará de forma predeterminada su contraparte IPv6 en lugar de localhost. La configuración de RUN export SPARK_LOCAL_IP="127.0.0.1" no está disponible en el entorno de ejecución y Spark actúa como si no se hubiese establecido.

No se puede acceder a los archivos con NFS

Error Solución sugerida
mount.nfs: Protocol not supported A algunas imágenes base, como debian y adoptopenjdk/openjdk11, les falta la dependencia nfs-kernel-server.
mount.nfs: Connection timed out Si se agota el tiempo de espera de la conexión, asegúrate de proporcionar la dirección IP correcta de la instancia de Filestore.
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE Si el servidor rechazó el acceso, verifica que el nombre del archivo compartido sea correcto.

No se puede acceder a los archivos con Cloud Storage FUSE

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

Errores de conectividad y seguridad

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

El cliente no se autenticó correctamente

El siguiente error ocurre durante la entrega:

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, establece la reclamación de público (aud) del token de ID firmado por Google en lo siguiente:

    • Si configuras aud en la URL del servicio receptor con el formato https://SERVICE.run.app, tu servicio debe requerir autenticación. Puedes invocar tu servicio de Cloud Run a través de la URL de Cloud Run o de una URL del balanceador de cargas.

    • Si configuras aud en el ID de cliente de OAuth 2.0 con el 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 cargas HTTPS protegido por IAP. Recomendamos este enfoque para un balanceador de cargas de aplicaciones respaldado por varios servicios de Cloud Run en diferentes regiones.

    • Si configuras aud en un público personalizado configurado, usa los valores exactos proporcionados. Por ejemplo, si el público personalizado es https://service.example.com, el valor de la reclamación del público también debe ser https://service.example.com.

  2. Es posible que se produzca un error 401 en las siguientes situaciones debido a un formato de autorización incorrecto:

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

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

    • El encabezado de autorización contiene varios JWT.

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

    Para verificar las reclamaciones en un JWT, usa la herramienta jwt.io.

  3. Si obtienes tokens no válidos cuando usas el servidor de metadatos para recuperar tokens de ID y de acceso para autenticar solicitudes con el servicio de Cloud Run o la identidad de trabajo con un proxy HTTP para enrutar el tráfico de salida, agrega los siguientes hosts a las excepciones de proxy HTTP:

    • 169.254.* o 169.254.0.0/16

    • *.google.internal

  4. Un error 401 suele ocurrir cuando las bibliotecas cliente de Cloud usan el servidor de metadatos para recuperar las credenciales predeterminadas de la aplicación para autenticar invocaciones de REST o gRPC. Si no defines las excepciones de proxy HTTP, se mostrará el siguiente comportamiento:

    • Si diferentes Google Cloud cargas de trabajo alojan un servicio o trabajo de Cloud Run y el proxy HTTP, incluso si las bibliotecas cliente de Cloud recuperan las credenciales, la cuenta de servicio asignada a la carga de trabajo del proxy HTTP genera los tokens. Es posible que los tokens no tengan los permisos necesarios para realizar las operaciones de la API deGoogle Cloud previstas. Esto se debe a que la cuenta de servicio recupera los tokens desde la vista del servidor de metadatos de la carga de trabajo del proxy HTTP, en lugar del servicio o trabajo de Cloud Run.

    • Si el proxy HTTP no se aloja en Google Cloudy enrutas las solicitudes del servidor de metadatos con el proxy, las solicitudes de tokens fallarán y las operaciones de las APIs deGoogle Cloud no se autenticarán.

El cliente no está autorizado a invocar el servicio

Se produce uno de los siguientes errores cuando se invoca tu servicio:

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

Es posible que se produzca un error 403 cuando al miembro de IAM que se usó para generar el token de autorización le falte el permiso run.routes.invoke. Otorga este permiso al usuario que genera el token.

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

  1. Para que cualquiera pueda invocar tu servicio, actualiza la configuración de IAM y haz que el servicio sea público.

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

    • Si un desarrollador o un usuario final invoca tu servicio, otorga el permiso run.routes.invoke. Puedes proporcionar este permiso a través de 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 sea miembro del servicio de Cloud Run y que tenga el rol de Invocador de Cloud Run (roles/run.invoker).

    • Las llamadas a las que les falta un token de autenticación pueden causar el error 403. Si las llamadas con un token de autenticación válido siguen generando el error 403, otorga el permiso run.routes.invoke al miembro de IAM que genera el token.

Cuando encuentres un error 403 y no encuentres la entrada de registro resource.type = "cloud_run_revision", es posible que se deba a que los Controles del servicio de VPC bloquean un servicio de Cloud Run que tiene la configuración de entrada configurada en All. Para obtener más información sobre la solución de problemas de denegación de los Controles del servicio de VPC, consulta Errores 404.

Error al acceder al servicio desde un navegador web

El siguiente problema ocurre 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, este envía una solicitud GET al servicio. Sin embargo, la solicitud no contiene el token de autorización del usuario que realiza la llamada. Para resolver 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 la aplicación en lugar de firewalls a nivel de red. Para obtener más detalles sobre la configuración de Cloud Run con IAP, consulta Habilita Identity-Aware Proxy para Cloud Run.

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

    gcloud run services proxy SERVICE --project PROJECT-ID

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

  3. Permite invocaciones no autenticadas a tu servicio. Esto es útil para realizar pruebas o cuando tu servicio es una API pública o un sitio web.

Un par restableció la conexión

Uno de los siguientes errores ocurre cuando un par de la red cierra de forma inesperada la conexión TCP que estableció 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 resolver el problema, sigue estos pasos:

  • Si intentas realizar un trabajo en segundo plano con limitación de CPU, usa la configuración de facturación basada en instancias.

  • Asegúrate de estar dentro de los tiempos de espera de las solicitudes salientes. Si tu aplicación mantiene cualquier conexión en un estado inactivo más allá de este límite, la puerta de enlace debe obtener la conexión.

  • De forma predeterminada, la opción de socket TCP keepalive está inhabilitada para Cloud Run. No hay una forma directa de configurar la opción keepalive a nivel del servicio. Para habilitar la opción keepalive para cada conexión de socket, proporciona las opciones de socket requeridas cuando abras una nueva conexión de socket TCP, según la biblioteca cliente que uses para esta conexión en tu aplicación.

  • En ocasiones, las conexiones salientes se restablecen debido a actualizaciones de infraestructura. Si tu aplicación vuelve a usar conexiones de larga duración, te recomendamos entonces que configures tu aplicación para restablecer las conexiones para evitar la reutilización de una conexión inactiva.

  • Si usas un proxy HTTP para enrutar el tráfico de salida de tus servicios o trabajos de Cloud Run y el proxy aplica la duración máxima de la conexión, el proxy puede descartar de forma silenciosa las conexiones TCP de larga duración, como las establecidas mediante la agrupación de conexiones. Esto hace que los clientes HTTP fallen cuando se reutiliza una conexión ya cerrada. Si pretendes 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. Para los grupos de conexiones, configura los valores máximos de antigüedad de la conexión, las conexiones inactivas y el 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 un 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 resolver los problemas de tiempo de espera de la conexión, sigue estos pasos:

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

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

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

    • Asegúrate de tener todas las rutas necesarias para permitir el enrutamiento correcto de tráfico a los hosts de destino y de regreso. Esto es importante cuando se enruta el tráfico de salida a través del intercambio de tráfico entre redes de VPC o 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, los hosts remotos deben ser accesibles mediante el proxy.

    El tráfico enrutado a través de un proxy HTTP puede retrasarse según el uso de recursos del proxy. Si enrutas el tráfico de salida HTTP con un proxy, implementa reintentos, retirada exponencial o disyuntores.

Configura excepciones de proxy HTTP

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

Los hosts y las subredes sin 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

De forma opcional, los hosts sin proxy pueden incluir lo siguiente:

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

Para establecer excepciones de proxy HTTP para las redes de salida, configura lo siguiente:

  • Variables de entorno: NO_PROXY o no_proxy.

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

    • No se definió la propiedad del sistema https.nonProxyHosts. Esta propiedad del sistema se aplica a HTTP y 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

El siguiente error ocurre cuando hay un problema de conexión de la instancia del contenedor:

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

Para resolver el problema, sigue estos pasos:

  1. Verifica los siguientes errores en Cloud Logging:

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

    • Fallas del sondeo de funcionamiento 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.

      Cuando tu instancia no responda correctamente a la sonda dentro del tiempo de espera, sigue estos pasos:

  2. Si las solicitudes terminan con el código de error 503 antes de que se alcance el tiempo de espera de la solicitud establecido en Cloud Run, actualiza la configuración del tiempo de espera de la solicitud para tu framework de lenguaje:

  3. En algunas situaciones, es posible que se produzca un código de error 503 debido a un cuello de botella en la red descendente, por ejemplo, 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 servidores, asegúrate de que el conector no haya superado su límite de capacidad de procesamiento mediante estos pasos:

    1. Abre el Acceso a VPC sin servidores en la consola de Google Cloud:

      Ir a Acceso a VPC sin servidores

    2. Verifica si hay barras red en el histograma del gráfico de capacidad de procesamiento. Si hay una barra roja, considera aumentar el número máximo de instancias o el tipo de instancia que usa tu conector. De forma alternativa, comprime el tráfico enviado a través de un conector de Acceso a VPC sin servidores.

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

Error de tiempo de espera de la puerta de enlace

El siguiente error se produce cuando tu servicio no muestra una respuesta dentro de un tiempo especificado y finaliza la solicitud:

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 del entorno de ejecución de contenedores.

Para solucionar este problema, sigue estos pasos:

  • Si tu servicio procesa solicitudes largas, aumenta el tiempo de espera de la solicitud.

  • Instrumenta el registro y el seguimiento para comprender dónde la app pasa tiempo antes de exceder el tiempo de espera configurado de la solicitud.

  • Las conexiones salientes se restablecen de vez en cuando, debido a actualizaciones de infraestructura. Si tu aplicación vuelve a usar conexiones de larga duración, te recomendamos entonces que configures tu aplicación para restablecer las conexiones para evitar la reutilización de una conexión inactiva.

    Según la lógica de la app o el manejo de errores, un error 504 puede ser un indicador de que la aplicación intenta reutilizar una conexión inactiva y la solicitud se bloquea hasta que se agote el tiempo de espera de la solicitud configurada. Usa un sondeo de capacidad de respuesta para finalizar una instancia que muestra errores persistentes.

  • Los errores de memoria insuficiente que ocurren dentro del código de la app, por ejemplo, java.lang.OutOfMemoryError, no necesariamente finalizan una instancia de contenedor. Si el uso de memoria no excede el límite de memoria del contenedor, Cloud Run no finalizará la instancia. Según cómo la app maneje los errores de memoria insuficiente de la app, es posible que las solicitudes no se envíen hasta que excedan el tiempo de espera de la solicitud configurada.

    Para finalizar la instancia del contenedor, sigue estos pasos:

    • Configura el límite de memoria a nivel de la app para que sea mayor que el límite de memoria del contenedor.

    • Usa un sondeo de capacidad de respuesta para finalizar una instancia que muestra errores persistentes.

El dominio personalizado se bloqueó mientras se aprovisionaba el certificado

Uno de los siguientes errores ocurre cuando asignas 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 demorar unos 15 minutos, pero puede tardar hasta 24 horas.

  2. Verifica que hayas actualizado de forma correcta los registros DNS en el registrador de dominios mediante la herramienta de resumen de la Consola del administrador de Google. Los registros DNS de tu registrador de dominios deben coincidir con lo que te solicita agregar la consola de Google Cloud.

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

  4. Verifica que el certificado del dominio no haya vencido. 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 resolver este problema, usa WebSockets o HTTP/2.0, que propagan las desconexiones del cliente.

Problemas del sistema de archivos de red

Obtén más información para usar sistemas de archivos de red NBD, 9P, CIFS/Samba y Ceph.