Las conexiones SSH fallan cuando se inicia en frío un servicio de Cloud Run con varios contenedores

Cuando una conexión SSH inicia en frío un servicio de Cloud Run de varios contenedores con un orden de inicio del contenedor (container-dependencies), la solicitud se enruta antes de que el entorno del contenedor esté listo. Cloud Run devuelve un error 500 de HTTP y detiene de inmediato la instancia nueva. Si te conectas con Google Cloud CLI, el comando falla.

Para solucionar este problema, conéctate con SSH solo cuando una instancia ya esté en ejecución. Por ejemplo, envía primero una solicitud al servicio para iniciar una instancia o configura instancias mínimas.

Es posible que las operaciones de larga duración para habilitar o inhabilitar SSH en instancias de Cloud Run se completen antes de lo esperado

Las operaciones de larga duración (LRO) para habilitar o inhabilitar SSH en instancias de Cloud Run pueden devolverse antes de que se complete la operación.

Las conexiones SSH pueden fallar ocasionalmente después de habilitar o inhabilitar SSH

Las conexiones SSH pueden fallar ocasionalmente, en especial después de habilitar o inhabilitar SSH. Si falla una conexión, vuelve a intentarlo.

La política de reinicio Always detiene las instancias de Cloud Run cuando un contenedor sale con el código 0

Cuando una instancia de Cloud Run con varios contenedores tiene su política de reinicio establecida en Always y cualquier contenedor sale con el código 0, Cloud Run detiene la instancia en lugar de reiniciarla.

La marca de dependencia del contenedor dependsOn no funciona para las instancias de Cloud Run

La marca dependsOn para las instancias de Cloud Run con varios contenedores no funciona. Las dependencias especificadas entre contenedores en instancias de varios contenedores no se aplican durante el inicio del contenedor.

Recuperación demorada del servicio después de quitar un límite de inversión excedido o volver a habilitar la facturación

Si tu proyecto superó su límite de inversión o se inhabilitó la facturación, es posible que tus recursos de Cloud Run experimenten una demora de hasta 30 minutos antes de reanudar la publicación de tráfico después de que quites el límite de inversión o vuelvas a habilitar la facturación. Durante este período, es posible que las solicitudes fallen con errores 429 o 503 (con registros que indican "The request was aborted because there was no available instance") o que las instancias no se puedan iniciar.

No hay solución alternativa manual. Debes esperar hasta 30 minutos para que tus recursos vuelvan a estar en buen estado.

Los conectores de VPC para grupos de trabajadores no están listos para producción

Los conectores de acceso a VPC sin servidores con grupos de trabajadores de Cloud Run están disponibles en versión preliminar y solo se admiten a través de Terraform con la API de Cloud Run v2. No hay compatibilidad en la consola de Cloud de Confiance , Google Cloud CLI, YAML ni la API de Cloud Run v1. Además, no se admiten componentes de preparación para la producción, como las métricas de supervisión.

Aumento lineal en la métrica de latencia de entrada a la región

Es posible que observes un aumento lineal artificial en la métrica run.googleapis.com/request_latency/ingress_to_region, lo que suele ocurrir cuando colocas un servicio detrás de un balanceador de cargas de aplicaciones externo que usa el protocolo HTTP/2 y se reutilizan las conexiones. Esto ocurre porque es posible que la marca de tiempo de la solicitud inicial no se actualice para las solicitudes posteriores en la misma conexión, mientras que la hora de llegada regional sigue avanzando.

Este patrón es una anomalía en los informes de métricas. Este problema no representa la latencia real del plano de datos, que suele ser baja. La métrica se corrige cuando se cierra la conexión o se restablece el contador.

Latencia de implementación alta en algunas regiones

La creación o actualización de recursos de Cloud Run podría ser más lenta de lo esperado en algunas regiones, como us-central1. Si la latencia de implementación es un problema en una región en particular, Google recomienda realizar la implementación en otra región.

Las tareas de trabajo de Cloud Run pueden marcarse como falsas para reintentarse

En algunas situaciones, puede marcarse que una tarea se reintentó, incluso cuando la tarea se realizó de forma correcta en el primer intento. Hasta que se resuelva este problema, Google recomienda mantener el parámetro --max-retries en 3 o superior para evitar fallas de ejecución falsas.

Las activaciones de volumen no son compatibles con Config Connector

Si implementas tu servicio o trabajo de Cloud Run con Config Connector, las activaciones de volumen no se conservarán la próxima vez que realices la implementación. También es posible que tengas problemas para usar Config Connector con servicios o trabajos que ya tengan activaciones de volumen aplicadas.

La variable de entorno HOME se configura como /home en el entorno de ejecución de primera generación

El entorno de ejecución de primera generación de Cloud Run establece la variable de entorno HOME en /home. El entorno de ejecución de segunda generación establece la variable HOME en el valor de /etc/passwd para el usuario en ejecución o recurre a /home si /etc/passwd no existe o si no se puede encontrar al usuario en /etc/passwd.

No puedes activar secrets en /tmp en el entorno de ejecución de primera generación

Si usas el entorno de ejecución de primera generación, no puedes activar secrets directamente en /tmp. Sin embargo, puedes activar secrets en cualquier subdirectorio de /tmp.

Latencia de solicitud alta con dominios personalizados cuando se invoca desde algunas regiones

Las solicitudes a los servicios de Cloud Run que usan dominios personalizados pueden tener una latencia muy alta desde algunas ubicaciones. Este problema es más pronunciado en los servicios de Cloud Run en asia-northeast1 y us-east4. Si observas este problema, puedes lograr un mayor rendimiento con Cloud Load Balancing usando un NEG sin servidores.

A veces, se puede enviar una solicitud a las instancias antes de que se conozcan los resultados del sondeo de inicio

Cloud Run podría usar la solicitud enviada al extremo del servicio para iniciar una instancia. Antes de que se conozcan los resultados del sondeo de inicio, Cloud Run también puede asignar la solicitud a la instancia. Si el sondeo se aprueba, la instancia procesará la solicitud en el receiveTimestamp que aparece en el registro de solicitudes de Cloud Run. Si el sondeo falla, Cloud Run registra el error sin ingresar el código del servicio.

Las asignaciones de dominios personalizados requieren URLs de s3nsrun.fr habilitadas

Solo puedes asignar dominios personalizados a servicios de Cloud Run que tengan una URL s3nsrun.fr predeterminada. Hasta que se resuelva este problema, si inhabilitaste la URL s3nsrun.fr predeterminada, te recomendamos que habilites la URL s3nsrun.fr predeterminada, asignes el dominio personalizado y, luego, vuelvas a inhabilitar la URL s3nsrun.fr predeterminada.

El Acceso a VPC sin servidores no admite IPv6

No puedes usar IPv6 cuando envías tráfico a través de conectores de Acceso a VPC sin servidores. IPv6 es compatible cuando la salida de VPC directa usa subredes de pila doble o cuando se accede a extremos que no son de VPC mientras vpc-egress se configura como private-ranges-only.

Direcciones IP que no están identificadas con claridad cuando la usan sin servidores

Cuando usas la salida de VPC directa, puedes identificar las direcciones IP reservadas por Cloud Run que están en uso actualmente, que se muestran como None en lugar de Serverless en la página de direcciones IP de la consola de Cloud de Confiance .

Rutas de URL reservadas

• Rutas de acceso que comienzan con /_ah/.
• Algunas rutas que terminan con z. Para evitar conflictos con las rutas reservadas, te recomendamos que evites todas las rutas que terminen en z.

Algunos caracteres de URL codificados están decodificados

Cloud Run decodifica algunos caracteres codificados en la URL de los servicios de Cloud Run antes de llegar a la instancia de contenedor. Por ejemplo, %41 se decodifica automáticamente en A.

Servicios no admitidos

Envío HTTP/2

Cloud Run admite HTTP/2, pero no HTTP/2 Server Push.

Métodos HTTP

Cloud Run no admite solicitudes con métodos HTTP como TRACE y CONNECT. Como resultado, los servicios que se ejecutan en Cloud Run no reciben estos métodos.

Las conexiones integradas de Cloud SQL no están disponibles para los trabajos de Cloud Run que se ejecutan con varios contenedores.

La función de Cloud Run para conectarse a instancias de Cloud SQL no es compatible con los trabajos de Cloud Run que se ejecutan con varios contenedores. Tus trabajos seguirán ejecutándose, pero Cloud Run no activará el directorio /cloudsql dentro de los contenedores.