Soluciona problemas de Cloud Run

En esta página, se muestra cómo solucionar problemas de mensajes de error y resolver problemas cuando usas Cloud Run.

También puedes verificar los problemas existentes o abrir problemas nuevos desde la herramienta pública de seguimiento de errores.

Para otros mensajes de error que no aparecen en esta página, consulta la página de problemas conocidos.

Errores en la implementación

En esta sección, se enumeran los errores que puedes encontrar con la implementación y se proporcionan sugerencias 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 este problema, descarta las siguientes causas posibles:

  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 esperado, como se documenta en el contrato de entorno de ejecución de contenedores. Tu contenedor debe detectar las solicitudes entrantes en el puerto que define Cloud Run y que se proporciona en la variable de entorno PORT. Consulta Configura contenedores a fin de obtener instrucciones para especificar el puerto.

  3. Verifica si el contenedor escucha en todas las interfaces de red, que suelen denominarse 0.0.0.0.

  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.

Se produjo un error interno, ya que se superó el plazo de preparación de los recursos

El siguiente error ocurre cuando intentas implementar o intentar llamar a otra API de Google Cloud:

The server has encountered an internal error. Please try again later. Resource readiness deadline exceeded.

Este problema puede ocurrir cuando el agente de servicio de Cloud Run no existe o cuando no tiene la función de agente de servicio de Cloud Run (roles/run.serviceAgent).

Para verificar que el agente de servicio de Cloud Run exista en tu proyecto de Google Cloud y tenga la función necesaria, sigue estos pasos:

  1. Abre la consola de Google Cloud:

    Ir a la página Permisos

  2. En la esquina superior derecha de la página Permisos, selecciona la casilla de verificación Incluir asignaciones de roles proporcionadas por Google.

  3. En la lista Principales, busca el ID del agente de servicio de Cloud Run, que usa el ID
    service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com.

  4. Verifica que el agente de servicio tenga el rol de Agente de servicio de Cloud Run. Si el agente de servicio no tiene el rol, asignalo.

No se encontró el usuario “root” en /etc/passwd

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

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

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

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 cuando intentas realizar una 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:

Para solucionar este problema, sigue estos pasos:

  1. Especifica una cuenta de servicio con la marca --service-account gcloud.
  2. Verifica que la cuenta de servicio que especifiques tenga los permisos necesarios para implementar.

Si deseas verificar si el agente de servicio predeterminado de Compute Engine existe en tu proyecto de Google Cloud, realiza los siguientes pasos:

  1. Abre la consola de Google Cloud:

    Ir a la página Permisos

  2. En la esquina superior derecha de la página Permisos, selecciona la casilla de verificación Incluir asignaciones de roles proporcionadas por Google.

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

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

El siguiente error ocurre cuando intentas implementar desde PROJECT-ID mediante una imagen que se almacena en Container Registry en PROJECT-ID-2:

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.

Para resolver este problema, sigue estas recomendaciones:

  • Sigue las instrucciones para implementar imágenes de contenedores de otros proyectos de Google Cloud 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.

Errores en la 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 este problema, descarta las siguientes causas posibles:

  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. Aunque Container Registry no muestra un error cuando hay capas externas presentes, el plano de control de Cloud Run no las admite. Para solucionar este problema, puedes intentar configurar la marca --allow-nondistributable-artifacts en el daemon de Docker.

Entrega errores

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

HTTP 401: El cliente no se autenticó correctamente

El siguiente error ocurre durante la entrega:

The request was not authorized to invoke this service

Para solucionar este problema, sigue estos pasos:

  • Si la invoca una cuenta de servicio, la reclamación del público (aud) del token de ID firmado por Google se debe establecer en lo siguiente:

    • La URL de Cloud Run del servicio receptor, con el formato https://service-xyz.run.app.
      • El servicio de Cloud Run debe requerir autenticación.
      • El servicio de Cloud Run se puede invocar a través de la URL de Cloud Run o de una URL del balanceador de cargas.
    • El ID de cliente de OAuth 2.0 con el tipo de aplicación web, con el formato nnn-xyz.apps.googleusercontent.com.
    • Un público personalizado configurado con los valores exactos proporcionados. Por ejemplo, si el público personalizado es service.example.com, el valor de la reclamación del público (aud) también debe ser service.example.com. 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.

  • La herramienta jwt.io sirve para verificar las reclamaciones en un JWT.

  • Si el token de autenticación tiene un formato no válido, se produce un error 401. Si el token tiene un formato válido y al miembro de IAM que se usó para generarlo le falta el permiso run.routes.invoke, se produce un error 403.

  • Cuando usas el servidor de metadatos para recuperar tokens de ID y de acceso a fin de autenticar solicitudes con el servicio de Cloud Run o la identidad de trabajo con un proxy HTTP para enrutar el tráfico de salida, y obtienes tokens no válidos, asegúrate de agregar los siguientes hosts a las excepciones de proxy HTTP:

    • 169.254.* o 169.254.0.0/16
    • *.google.internal

    Este error 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, los siguientes resultados del comportamiento se mostrarán:

    • Si el servicio o trabajo de Cloud Run y el proxy HTTP se alojan en diferentes cargas de trabajo de Google Cloud, incluso si las bibliotecas cliente de Google Cloud pueden obtener credenciales, los tokens se generan para la cuenta de servicio asignada a la carga de trabajo del proxy HTTP, que podría no tener los permisos necesarios para realizar las operaciones previstas de la API de Google Cloud. En este caso, los tokens se recuperan desde la vista del servidor de metadatos de la carga de trabajo del proxy HTTP, en lugar de la de Cloud Run.

    • Si el proxy HTTP no se aloja en Google Cloud y las solicitudes del servidor de metadatos se enrutan mediante el proxy, las solicitudes de tokens fallarán y las operaciones de las APIs de Google Cloud se anularán.

HTTP 403: El cliente no está autorizado a invocar o llamar al servicio

El siguiente error puede o no estar en Cloud Logging con resource.type = “cloud_run_revision”:

The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header

El siguiente error está presente en la respuesta HTTP que se mostró al cliente:

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

Para resolver este problema cuando el error resource.type = "cloud_run_revision" está presente:

  • Si se pretende que cualquiera pueda invocar el servicio, actualiza su configuración de IAM para que el servicio sea público.
  • Si se pretende que solo determinadas identidades puedan invocar el servicio, asegúrate de invocarlo con el token de autorización adecuado.
    • Si es invocado por un desarrollador o es invocado por un usuario final: Asegúrate de que el desarrollador o el usuario tengan el permiso run.routes.invoke, que puedes proporcionar a través de los roles Administrador de Cloud Run (roles/run.admin) e Invocador de Cloud Run (roles/run.invoker).
    • Si la invoca una cuenta de servicio: Asegúrate de que la cuenta de servicio sea miembro del servicio de Cloud Run y que tenga el rol Invocador de Cloud Run (roles/run.invoker).
    • Las llamadas a las que les falta un token de autenticación o con un token de autenticación que tiene un formato válido, pero en las que el miembro de IAM que se usó para generar el token no tiene el permiso run.routes.invoke, genera este error 403.

Para resolver este problema cuando el error resource.type = "cloud_run_revision" no está presente:

  • Se puede mostrar un código de estado 403 cuando un servicio tiene la entrada configurada en All, pero se bloqueó debido a los Controles del servicio de VPC. Consulta la siguiente sección sobre errores 404 para obtener más información sobre la solución de problemas de denegación de los Controles del servicio de VPC.

HTTP 403: 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, elige una de las siguientes soluciones:

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

  • Como solución alternativa temporal, puedes acceder a tu servicio a través de un navegador web con el proxy de Cloud Run en Google Cloud CLI. Puedes usar un proxy de un servicio de forma local con lo siguiente:

    gcloud run services proxy SERVICE --project PROJECT-ID

    Después de ejecutar este comando, 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.

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

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 proyecto de Google Cloud.

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: Respuesta con formato incorrecto o problema de conexión de la instancia de contenedor

Uno de los siguientes errores ocurre durante la entrega: 

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

Para resolver este problema, sigue estas recomendaciones:

  • Verifica Cloud Logging Usa Cloud Logging para buscar errores de memoria insuficiente en los registros. Si ves mensajes de error relacionados con las instancias de contenedores que superan los límites de memoria, sigue las recomendaciones para resolver este problema.

  • Tiempos de espera a nivel de app 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, es posible que debas actualizar la configuración del tiempo de espera de la solicitud para tu framework de lenguaje:

  • Cuello de botella de la red descendente: En algunas instancias, un código de error 503 puede dar como resultado 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.

  • Límite de solicitudes entrantes a un solo contenedor Hay un problema conocido en el que hay porcentajes de solicitudes altos por contenedor que generan este error 503. Si una instancia de contenedor recibe más de 800 solicitudes por segundo, los sockets TCP disponibles se pueden agotar. Para solucionar este problema, prueba alguna de las siguientes opciones:

    1. Activa HTTP/2 para el servicio y realiza los cambios necesarios en el servicio para que sea compatible con HTTP/2.

    2. Evita enviar más de 800 solicitudes por segundo a una sola instancia de contenedor mediante la disminución de la simultaneidad configurada. Usa la siguiente ecuación para obtener una estimación del porcentaje de solicitudes por instancia de contenedor: requests/sec/container_instance ~= concurrency * (1sec / median_request_latency)

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:

HTTP 504: Error de tiempo de espera de la puerta de enlace

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

Si tu servicio procesa solicitudes largas, puedes aumentar el tiempo de espera de la solicitud. Si tu servicio no muestra una respuesta dentro del tiempo especificado, la solicitud finaliza y el servicio muestra un error HTTP 504, como se documenta en el contrato del entorno de ejecución de contenedores.

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

  • 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 a fin de 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.
    • Puedes usar un sondeo de capacidad de respuesta para ayudar a 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, no se finalizará la instancia. Según cómo la app maneje los errores de memoria insuficiente de la app, las solicitudes pueden quedar en espera hasta que excedan el tiempo de espera de la solicitud configurada.

    • Si quieres que la instancia de contenedor se cierre en la situación anterior, configura el límite de memoria a nivel de la app para que sea mayor que el límite de memoria del contenedor.
    • Puedes usar un sondeo de capacidad de respuesta para finalizar una instancia que muestra errores persistentes.

Un par restableció la conexión

Uno de los siguientes errores ocurre durante la entrega:

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

Este error ocurre cuando una aplicación tiene una conexión TCP establecida con un par de red, y ese par cierra la conexión de forma inesperada.

Para solucionar este problema, sigue estos pasos:

  • Si intentas realizar un trabajo en segundo plano con limitación de CPU, intenta usar la configuración de asignación de CPU “La CPU siempre está asignada”.

  • 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 estos límites, 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 en Cloud Run a nivel de servicio, pero puedes habilitar la opción keepalive para cada conexión de socket si proporcionas las opciones de socket correctas cuando abres una conexión de socket TCP nueva, 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 a fin de 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, asegúrate de considerar esta situación implementando 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 errores de latencia o uno de los siguientes errores se producen cuando hay tiempos de espera de conexión cuando se realiza una solicitud a un host remoto:

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

Este tipo de errores se producen cuando una aplicación intenta crear un TCP con un host remoto y la conexión tarda demasiado.

  • 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, asegúrate que:

    • Definiste todas las reglas de firewall necesarias para permitir la entrada para los conectores de VPC.

    • Las reglas de firewall de VPC permiten que el tráfico de entrada de los conectores de VPC o la subred de salida de VPC directa llegue al host o la subred de destino.

    • Tienes 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.

  • Si usas un proxy HTTP para enrutar todo el tráfico de salida de tus servicios o trabajos de Cloud Run, asegúrate de que se pueda acceder a los hosts remotos 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 se pretende enrutar el tráfico de salida HTTP con un proxy, asegúrate de tener en cuenta esta situación mediante la implementación de los reintentos, la retirada exponencial o los 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, asegúrate de agregar excepciones para las APIs de Cloud y otros hosts y subredes sin proxy para evitar que 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

Formas comunes de configurar las excepciones del Proxy HTTP para las redes de salida incluyen lo siguiente:

  • Variables de entorno: NO_PROXY o no_proxy.

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

    • La propiedad del sistema https.nonProxyHosts no está definida, por lo que http.nonProxyHosts se aplica a HTTP y HTTPS.
    • La propiedad del sistema http.nonProxyHosts no admite la notación CIDR, por lo que debes usar expresiones de coincidencia de patrones.

Firma de token de identidad oculta por Google

Los siguientes errores ocurren 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 es solo una advertencia y 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. Ten en cuenta que la configuración de RUN export SPARK_LOCAL_IP="127.0.0.1" no estará disponible en el entorno de ejecución y Spark funcionará como si no se hubiese establecido.

Asigna dominios personalizados

El dominio personalizado está atascado en el estado de aprovisionamiento de certificados

Uno de los siguientes errores ocurre cuando intentas 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:

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

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

  • Confirma que la raíz del dominio se verifique en tu cuenta mediante uno de los siguientes métodos:

  • 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

API de Admin

La función no es compatible con la etapa de lanzamiento declarada

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. A continuación, se muestran ejemplos de la API de REST v1 y la API de REST v2:

En el siguiente ejemplo, se agrega una 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"
    }

En el siguiente ejemplo, se agrega una referencia de LaunchStage a una solicitud del cliente con JSON y la API de REST v2:

  "launchStage": "BETA"

En el siguiente ejemplo, se agrega una anotación 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

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.

La solución es usar WebSockets o HTTP/2.0, que propagan las desconexiones del cliente.

Solución de problemas del sistema de archivos de red

Obtén más información para usar sistemas de archivos de red.

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.