Tema 3 de 10
Revisiones, tráfico y escalado en Cloud Run
Tres puntos del temario: desplegar versiones nuevas de una aplicación de Cloud Run, ajustar el reparto de tráfico (en Cloud Run, Cloud Run functions y GKE) y configurar el autoescalado de una aplicación de Cloud Run. El reparto de tráfico en GKE con Gateway API está en el artículo de operación de GKE.
Contenido
Revisiones
Cada despliegue o cambio de configuración de un servicio crea una revisión inmutable. El servicio decide qué revisiones reciben tráfico y en qué porcentaje, lo que permite volver atrás, desplegar de forma gradual y repartir tráfico entre varias.
- Los cambios de tráfico no son instantáneos: las peticiones en curso terminan y no se pierden.
- Si repartes tráfico o lo asignas a una revisión antigua, ese patrón se mantiene en los siguientes despliegues. Para volver a usar solo la última revisión, envíale todo el tráfico.
- La pestaña Revision history del servicio lista las revisiones y permite gestionar el tráfico.
Desplegar una versión nueva
gcloud run deploy myservice --image us-docker.pkg.dev/PROJECT/repo/app:2.0 --region us-central1
Por defecto, la revisión nueva recibe el 100 % del tráfico cuando está lista. Roles para gestionar servicios desplegados desde una imagen:
- Cloud Run Developer (
roles/run.developer) en el servicio. - Service Account User en la identidad del servicio.
- Artifact Registry Reader en el repositorio de la imagen, si aplica.
- Desde código fuente: Cloud Run Source Developer y Service Usage Consumer en el proyecto, y el rol Cloud Run Builder para la cuenta de servicio de Cloud Build.
Volver a una revisión anterior
gcloud run services update-traffic myservice --to-revisions myservice-00004-abc=100
En la consola: Revision history → menú de la revisión → Manage traffic → Send all traffic to one revision. También se puede editar el bloque traffic del YAML del servicio y aplicarlo con gcloud run services replace.
Ojo
Al devolver el tráfico a una revisión, Cloud Run actualiza el enrutamiento de inmediato sin volver a ejecutar las comprobaciones de estado del despliegue ni verificar dependencias externas.
Despliegue gradual y reparto de tráfico
Desplegar sin tráfico: gcloud run deploy myservice --image IMAGE --no-traffic
Mandar un porcentaje pequeño: gcloud run services update-traffic myservice --to-revisions NUEVA=10,ANTIGUA=90
Subir el porcentaje mientras vigilas las métricas: NUEVA=50, luego NUEVA=100
Volver a «siempre la última»: gcloud run services update-traffic myservice --to-latest
Para la última revisión se puede usar el alias LATEST, por ejemplo LATEST=5. Con afinidad de sesión activada, el reparto se ve afectado; la documentación lo trata aparte.
Cloud Run functions
Las funciones se despliegan como servicios de Cloud Run, así que tienen las mismas revisiones, el mismo reparto de tráfico y el mismo autoescalado. Se gestionan con los mismos comandos gcloud run.
Cómo autoescala Cloud Run
Cada revisión escala automáticamente al número de instancias necesario para las peticiones, los eventos o el uso de CPU. Sin tráfico, escala a cero.
Uso de CPU
Uso medio de CPU del último minuto dividido por las CPU por instancia y por el objetivo.
Concurrencia de peticiones
Peticiones simultáneas medias (1 y 10 minutos) divididas por la concurrencia máxima y por el objetivo.
- Toma el mayor número de instancias que pida cualquiera de los dos factores.
- Objetivo por defecto: 60 % de CPU y de concurrencia. Mantiene las instancias mientras el uso esté a ±10 % del objetivo (entre 54 % y 66 %) y redondea hacia arriba.
- No escala por memoria.
- Las instancias pueden quedar inactivas un tiempo tras atender peticiones (hasta 15 minutos, 10 con GPU).
- Alternativa: el escalado manual, con un número fijo de instancias.
Concurrencia
La concurrencia máxima es cuántas peticiones simultáneas atiende una instancia. Con gcloud o Terraform, por defecto es 80 por cada vCPU. Influye mucho en cómo escala el servicio: si tu aplicación no aguanta varias peticiones a la vez, se baja.
gcloud run services update myservice --concurrency=1
Instancias mínimas y máximas
Mínimas
- Por defecto 0. Mantienen instancias calientes para evitar arranques en frío.
- Son un objetivo de mejor esfuerzo, no una garantía.
- Tienen coste: con facturación por peticiones, las inactivas se cobran a una tarifa menor; con facturación por instancia, a la tarifa normal. Google sugiere CUD porque es un coste previsible.
- Si el servicio usa CPU aunque no haya peticiones, Google recomienda al menos 1.
Máximas
- Por defecto 100 instancias por revisión; se puede subir.
- Sirven para controlar costes o no saturar sistemas posteriores, como una base de datos.
# A nivel de servicio (recomendado): sin desplegar revisión nueva gcloud run services update myservice --min 2 --max 50 # A nivel de revisión: se aplica al desplegar gcloud run services update myservice --min-instances 2 --max-instances 50
Google recomienda fijarlas a nivel de servicio y no mezclar ajustes de servicio y de revisión.
Escenarios de examen
| Situación | Respuesta | Por qué |
|---|---|---|
| La versión recién desplegada da errores | gcloud run services update-traffic SERVICE --to-revisions REV_ANTERIOR=100 | Cambia el enrutamiento de inmediato. |
| Desplegar una versión sin que reciba tráfico todavía | gcloud run deploy --no-traffic --tag green | La revisión queda accesible solo por su URL de etiqueta. |
| Enviar el 10 % del tráfico a la versión nueva | update-traffic --to-revisions NUEVA=10,ANTIGUA=90 | Reparto por porcentajes entre revisiones. |
| Volver a enviar todo a la última revisión tras un reparto | update-traffic --to-latest | Los repartos se mantienen en los siguientes despliegues. |
| Evitar arranques en frío en una API de baja latencia | Instancias mínimas a nivel de servicio | Mantiene instancias calientes, con coste. |
| Proteger una base de datos de demasiadas conexiones | Limitar las instancias máximas | Acota cuántas instancias pueden crearse. |
| Un servicio de un solo hilo se satura con varias peticiones a la vez | Bajar la concurrencia máxima | Menos peticiones simultáneas por instancia. |
Trampas frecuentes del examen
❓ ¿Cloud Run escala según la memoria?
No. Escala por uso de CPU y concurrencia de peticiones.
❓ ¿Cuántas instancias máximas tiene una revisión por defecto?
100. Se puede aumentar.
❓ ¿Las instancias mínimas son gratis?
No. Las instancias mantenidas se cobran, aunque con facturación por peticiones a una tarifa menor cuando están inactivas.
❓ Tras repartir tráfico 90/10, ¿el siguiente despliegue recibe el 100 %?
No. El patrón de reparto se mantiene; hay que usar --to-latest para volver a enviar todo a la última.
❓ ¿Qué hace --no-traffic?
Despliega la revisión sin enviarle tráfico. Con --tag queda accesible por su URL de etiqueta.
❓ ¿Cuál es la concurrencia máxima por defecto con gcloud?
80 por cada vCPU de la instancia.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un equipo quiere probar la versión 2 de su servicio de Cloud Run con usuarios internos antes de darle tráfico real, y después pasarle el 20 % del tráfico. ¿Qué hace?
¿Listo para poner a prueba "Revisiones, tráfico y escalado en Cloud Run"?
Preguntas originales, cada una con su explicación.
Empezar un simulacro