Cómputo en Google Cloud: GKE, Cloud Run y Compute Engine

Google Cloud ofrece las mismas tres maneras de correr código que AWS: máquinas virtuales, Kubernetes administrado y contenedores sin servidores. Los nombres cambian, y también algunos comportamientos de alta disponibilidad que darías por hechos en AWS. Esta lección te ayuda a elegir entre Compute Engine, GKE y Cloud Run, y a diseñar cada uno para que sobreviva a la caída de una zona.

Compute Engine y las familias de máquinas

Compute Engine es el EC2 de Google Cloud. Los tipos de máquina se agrupan en familias: de uso general (series E2, N2, N4, C3 o C4, por ejemplo), optimizadas para cómputo, para memoria, para almacenamiento y con aceleradores. Revisa el catálogo al diseñar: las series cambian más rápido que esta lección. Tres diferencias con EC2:

• Tipos personalizados: en varias series eliges vCPU y memoria a la medida, en vez de saltar al siguiente tamaño.
• Migración en vivo: durante el mantenimiento del host, Google mueve la VM a otro host sin reiniciarla en la mayoría de los tipos. En EC2 recibes un evento programado y tú reaccionas.
• Discos regionales: Persistent Disk regional y Hyperdisk Balanced High Availability replican de forma síncrona entre dos zonas. EBS no tiene equivalente; en AWS replicas en la aplicación.

Las plantillas de instancia cumplen el papel de las launch templates, y las Spot VMs el de las instancias Spot.

Grupos de instancias administrados

Un MIG (managed instance group) crea VMs idénticas desde una plantilla, como un Auto Scaling group. Puede ser zonal o regional; el regional reparte VMs entre zonas, tres por defecto, y las zonas no se cambian después. La forma de distribución decide cómo: EVEN (por defecto) mantiene el mismo número por zona, BALANCED prefiere zonas con capacidad, ANY y ANY_SINGLE_ZONE sirven para lotes.

El autohealing usa un health check de aplicación y recrea la VM que no responde. Es distinto del health check del balanceador: el del balanceador saca la VM del tráfico; el de autohealing la destruye y la recrea. Hazlo más tolerante que el del balanceador, o un pico de latencia reciclará media flota.

Criterio	MIG regional	Auto Scaling group
Reparto entre zonas	Forma de distribución EVEN, BALANCED, ANY o ANY_SINGLE_ZONE	Rebalanceo entre las AZ de las subredes elegidas
Si cae una zona	Las demás siguen sirviendo; no crea VMs en otras zonas salvo que haya autoescalado	Lanza reemplazos en las AZ sanas
Reemplazo de VMs enfermas	Autohealing con health check de aplicación	Health check de EC2 o del ELB
Actualización	Rolling update con maxSurge y maxUnavailable; canario con dos plantillas	Instance refresh
Escalado	CPU, uso del balanceador, métricas de Cloud Monitoring, horarios	Seguimiento de objetivo, pasos, programado, predictivo

Si tu MIG regional de tres zonas no tiene autoescalado, sobredimensiona: Google recomienda al menos un 50 % extra para que perder una zona deje el 100 % de la capacidad. Compáralo con Auto Scaling.

GKE: Standard, Autopilot y clústeres regionales

GKE Standard te deja administrar los node pools: tipos de máquina, tamaños y actualizaciones. GKE Autopilot administra los nodos por ti y cobra por los recursos que piden los pods, cerca de lo que hace EKS Auto Mode. La decisión de alta disponibilidad más importante es otra: un clúster regional replica el plano de control en varias zonas y reparte los nodos; un clúster zonal tiene el plano de control en una sola zona. Autopilot siempre es regional, y un clúster regional no se puede convertir en zonal.

Para que los pods llamen a APIs de Google sin llaves usa Workload Identity Federation for GKE: la cuenta de servicio de Kubernetes recibe roles de IAM, como con EKS Pod Identity o IRSA. Para varios clústeres, regístralos en una flota (fleet) y usa Gateways multiclúster, que programan un balanceador global sobre servicios exportados de varios clústeres. Multi Cluster Ingress es la API anterior; para diseños nuevos, Gateway.

Criterio	GKE	EKS
Plano de control	Multizona solo en clústeres regionales	Siempre multi-AZ
Nodos administrados	Autopilot, o node pools en Standard	EKS Auto Mode, Fargate o grupos de nodos administrados
Identidad de pods	Workload Identity Federation for GKE	EKS Pod Identity o IRSA
Varios clústeres	Flotas y Gateways multiclúster con un balanceador global	Balanceadores por clúster y Global Accelerator o Route 53
Actualizaciones	Canales de versiones (rapid, regular, stable) con actualización automática	Actualización del plano de control que tú inicias; soporte estándar y extendido

Cloud Run: servicios, jobs y multirregión

Cloud Run corre contenedores sin servidores. Un servicio atiende HTTP, escala según solicitudes, puede bajar a cero y procesa varias solicitudes por instancia. Un job corre tareas hasta terminar, como un lote. Las Cloud Run functions son la forma de función, el equivalente de Lambda. Un servicio es regional y Google ya lo reparte entre zonas de la región. Con instancias mínimas evitas arranques en frío en la ruta crítica.

Para varias regiones, despliega el servicio en cada una o como servicio multirregión con --regions, y ponlo detrás de un Application LB externo global con un NEG serverless por región. Ojo: el balanceador no deja de mandar tráfico a una región cuyo servicio responde mal. Para eso configura el service health de Cloud Run con sondas de disponibilidad, o detección de valores atípicos en el balanceador.

# Clúster regional de GKE en modo Autopilot (siempre regional)
gcloud container clusters create-auto pagos-prod \
  --region=us-east1 --release-channel=regular

# Cloud Run en dos regiones como servicio multirregión
gcloud run deploy pagos-api \
  --image=us-docker.pkg.dev/pagos-prod-7f3a/apps/pagos-api@sha256:3b1f... \
  --regions=us-east1,us-central1 --min-instances=2

Criterio	Cloud Run	Fargate (ECS)	App Runner
Unidad	Servicio o job	Tarea o servicio de ECS	Servicio
Escala a cero	Sí	No por solicitudes: el servicio mantiene sus tareas deseadas	No: sin tráfico cobra la memoria de las instancias aprovisionadas
Solicitudes por instancia	Varias, configurable	Las que maneje tu proceso	Varias, configurable
Varias zonas	Automático en la región	Según las subredes del servicio	Automático en la región
Varias regiones	Servicio multirregión + balanceador global	Un servicio por región + Route 53 o Global Accelerator	Un servicio por región + Route 53

Artifact Registry y las imágenes en dos nubes

Artifact Registry guarda imágenes de contenedor y paquetes. Un repositorio es regional o multirregional (us, europe, asia). Un repositorio regional no se replica solo a otra región; el multirregional reparte los datos y puede seguir funcionando si cae una de sus regiones. Los repositorios remotos funcionan como la caché de extracción de ECR, contra Docker Hub u otros registros por HTTPS, y los virtuales agrupan varios repositorios detrás de una sola URL.

1. 1

   Construye una vez

   El pipeline produce una imagen y su digest. Ese digest es la identidad de lo que corre, en cualquier nube.
2. 2

   Publica en las dos nubes

   Empuja el mismo digest a ECR y a Artifact Registry desde el pipeline, con identidades federadas y sin llaves.
3. 3

   Despliega por digest

   Cloud Run, GKE y EKS referencian @sha256:..., no una etiqueta que alguien puede mover.
4. 4

   Sin dependencias cruzadas en ejecución

   GKE no descarga de ECR ni EKS de Artifact Registry: si una nube cae, la otra debe poder arrancar pods nuevos.