Semana 2 · Módulo 2 de 12

Cómputo: Compute Engine, MIG, GKE, Cloud Run y cuándo usar cada uno

Recorres todas las plataformas de cómputo de Google Cloud, desde la VM que gestionas tú hasta el contenedor serverless que escala a cero, y aprendes a elegir entre ellas con criterios de arquitecto. Es una de las decisiones que más se repiten en el examen.

Reparto de la semana

Por qué importa

La guía del examen pide, en el apartado 1.3, «mapear las necesidades de cómputo a los productos de la plataforma (GKE, Cloud Run, Cloud Run functions)» y «elegir recursos de cómputo (Spot VMs, custom machine types, cargas especializadas)». En el 2.3 pide saber aprovisionarlos: volatilidad (Spot frente a estándar), redes de cómputo (Compute Engine, GKE, serverless, VMware Engine), orquestación, parches, contenedores y serverless.

En la práctica, muchísimas preguntas se reducen a «qué plataforma de cómputo uso» con matices de coste, operación, portabilidad y requisitos heredados. Al final del módulo tienes una tabla y un árbol para decidir en segundos.

El espectro, de más control a más gestión:

flowchart LR
  A["Compute Engine: VMs"] --> B["MIG: grupos de VMs gestionados"]
  B --> C["GKE Standard: Kubernetes, tú gestionas nodos"]
  C --> D["GKE Autopilot: Kubernetes, Google gestiona nodos"]
  D --> E["Cloud Run: contenedores serverless"]
  E --> F["Cloud Run functions: funciones"]

Hacia la izquierda, más control y más trabajo operativo; hacia la derecha, menos operación, escalado a cero y más restricciones.

Compute Engine

Compute Engine es el servicio de máquinas virtuales (IaaS). Tú eliges el tipo de máquina, el sistema operativo, los discos y la red; tú instalas y parcheas el software. Es la opción cuando necesitas control total: sistemas operativos concretos, software con licencias ligadas al hardware, aplicaciones heredadas que no se pueden contenerizar o migraciones lift and shift.

Una VM es un recurso zonal: vive en una zona concreta, con sus discos zonales.

Familias, series y tipos de máquina

Los tipos de máquina se agrupan en familias (para qué están optimizadas) y series (generación y procesador). El nombre de un tipo de máquina sigue el patrón serie-categoría-vCPUs: e2-standard-4, n4-highmem-8, c4-highcpu-16. Las categorías habituales son standard (equilibrado), highmem (más memoria por vCPU) y highcpu (menos memoria por vCPU).

No memorices la tabla entera: el examen pregunta por la familia («una base de datos en memoria de varios TB» → memory-optimized; «entrenar un modelo grande» → accelerator-optimized; «web de coste mínimo» → E2), no por cada serie.

Detalles útiles:

• E2 shared-core (e2-micro, e2-small, e2-medium): comparten núcleo físico y usan ráfagas. Muy baratas; perfectas para labs, desarrollo y cargas pequeñas.
• Custom machine types (tipos de máquina personalizados): eliges vCPUs y memoria exactos. Están disponibles para las series N y E de uso general, con un recargo del 5 % sobre el precio equivalente. Úsalos cuando ningún tipo predefinido encaja y sobrarían muchos recursos (por ejemplo, 6 vCPU y 40 GB, o una aplicación con licencias por núcleo que necesita pocas vCPU y mucha memoria). También existe la memoria extendida para superar la proporción memoria/vCPU normal en ciertas series.
• Algunas series ofrecen variantes con SSD local incluido (sufijos -lssd) y variantes bare metal (-metal) sin hipervisor.
• Para rendimiento de red y de disco, las series modernas se apoyan en Titanium, el sistema de descarga de trabajo de Google.

Discos: Hyperdisk, Persistent Disk y Local SSD

Regla: si el enunciado dice «los datos deben sobrevivir», Local SSD no es la respuesta aunque sea el más rápido. Si pide conmutación por error de una VM a otra zona sin perder datos, piensa en discos replicados entre zonas (Regional PD o Hyperdisk Balanced High Availability).

Los discos se facturan por capacidad provisionada (y, en Hyperdisk, también por rendimiento provisionado) desde que se crean hasta que se borran, aunque la VM esté parada. Es una fuente clásica de gasto olvidado.

Mantenimiento del host y live migration

Google mantiene el hardware sin avisarte casi nunca, gracias a la live migration: mueve la VM en ejecución a otro host de la misma zona sin reiniciarla ni cambiar su IP. La política de mantenimiento (onHostMaintenance) puede ser MIGRATE (por defecto en la mayoría) o TERMINATE. No pueden migrarse en caliente, entre otras, las VMs con GPU (reciben un aviso previo y se detienen), las Spot y la mayoría de Confidential VMs. Por eso las cargas con GPU se diseñan para tolerar reinicios.

Spot VMs frente a VMs estándar

Las Spot VMs usan capacidad sobrante de Google con descuentos de hasta el 91 %, a cambio de que Google puede reclamarlas (preempt) en cualquier momento:

• Al ser reclamadas, reciben una señal de apagado y tienen un periodo de cierre de hasta 30 segundos (de mejor esfuerzo). Opcionalmente puedes configurar un aviso previo de 120 segundos.
• La acción al reclamarlas es STOP (por defecto) o DELETE.
• No tienen SLA ni live migration, y la disponibilidad no está garantizada.
• No tienen duración máxima. Las antiguas VMs preemptible (su predecesoras) se paraban como mucho a las 24 horas; hoy se usan las Spot.
• Se crean con --provisioning-model=SPOT y funcionan dentro de MIGs, que recrean las reclamadas cuando vuelve a haber capacidad.

gcloud compute instances create lote-01 \
  --zone=europe-southwest1-a --machine-type=e2-standard-2 \
  --provisioning-model=SPOT --instance-termination-action=DELETE

Imágenes, snapshots e instance templates

• Imagen (image): plantilla de disco de arranque. Hay públicas (Debian, Ubuntu, RHEL, Windows Server… mantenidas por Google o el fabricante) y personalizadas (las creas a partir de un disco). Las familias de imágenes (--image-family=debian-12) apuntan siempre a la última versión no obsoleta. Las imágenes son recursos globales y se pueden compartir entre proyectos. Crear una imagen «dorada» con el software preinstalado reduce el tiempo de arranque de un MIG.
• Snapshot: copia de seguridad incremental de un disco (solo guarda lo que cambió desde la anterior). Tipos: estándar, archive (más barata, para retención larga) e instant (la más rápida de restaurar, pero vive en la misma zona o región que el disco y desaparece con él). Se pueden programar con snapshot schedules. Por defecto se guardan en ubicación multirregional.
• Machine image: captura toda la VM (configuración, metadatos, permisos y todos sus discos). Útil para clonar o respaldar una VM completa.
• Instance template: guarda la configuración de una VM (tipo de máquina, imagen, discos, red, metadatos, script de arranque, cuenta de servicio). Es inmutable: para cambiarla creas otra. Puede ser regional (recomendada salvo que necesites reutilizarla en varias regiones) o global. Es obligatoria para crear un MIG.

La gestión de parches del sistema operativo (apartado 2.3) se hace con VM Manager (parcheo del SO, inventario y políticas del SO para flotas de VMs) o, en MIGs, sustituyendo las VMs con una nueva imagen mediante una actualización progresiva, que es la opción más «nube nativa».

Sole-tenant nodes y GPUs

• Sole-tenant nodes: servidores físicos dedicados en exclusiva a tus VMs. Se definen con una plantilla de nodo, un grupo de nodos y etiquetas de afinidad para colocar las VMs. Casos: licencias BYOL por núcleo o por socket físico (Windows Server, SQL Server, Oracle), requisitos de aislamiento físico por cumplimiento, y control del hardware. Se paga por nodo completo, con recargo.
• GPUs: en las series accelerator-optimized (A y G) la GPU viene incluida en el tipo de máquina; en N1 puedes añadir ciertos modelos (T4, P4, V100). Recuerda: sin live migration, y no disponibles en la prueba gratuita. Las TPUs (aceleradores propios de Google) se tratan en el módulo de IA, junto con AI Hypercomputer.

Managed Instance Groups (MIG)

Un Managed Instance Group (MIG, grupo de instancias gestionado) es un conjunto de VMs idénticas creadas a partir de un instance template, que Google gestiona como una unidad. Es la pieza básica para servir aplicaciones escalables y resistentes con VMs.

Frente a él está el unmanaged instance group, un grupo de VMs heterogéneas que gestionas tú; solo sirve para agrupar VMs existentes detrás de un balanceador y no tiene autoescalado, autocuración, actualizaciones progresivas ni multizona.

flowchart TB
  T["Instance template v1"] --> M["MIG regional europe-southwest1"]
  M --> V1["VM zona a"]
  M --> V2["VM zona b"]
  M --> V3["VM zona c"]
  AS["Autoscaler: CPU, carga del balanceador, métricas, horarios"] --> M
  HC["Health check de autocuración"] --> M
  LB["Balanceador de carga"] --> V1
  LB --> V2
  LB --> V3

Capacidades

• Autocuración (autohealing): si una VM se para, se cae, es reclamada (Spot) o no supera el health check de la aplicación, el MIG la recrea. Configura un retardo inicial (initial delay) suficiente para que la aplicación arranque; si no, el MIG recreará VMs que aún están arrancando.
• Autoescalado (autoscaling): ajusta el número de VMs según señales:
  • Uso medio de CPU.
  • Capacidad de servicio del balanceador HTTP(S).
  • Métricas de Cloud Monitoring (por ejemplo, mensajes pendientes en una suscripción de Pub/Sub).
  • Horarios (schedules) para picos conocidos.
  • Con varias señales, el autoescalador calcula el tamaño para cada una y se queda con el mayor.
  • Periodo de inicialización (antes cool down period; 60 s por defecto): tiempo que ignora las métricas de VMs recién creadas.
  • Periodo de estabilización de 10 minutos antes de reducir, y scale-in controls para limitar lo rápido que encoge.
  • Autoescalado predictivo: prevé la carga con el histórico y escala por adelantado; útil si las VMs tardan en arrancar y la carga tiene patrón diario o semanal.
  • Modos: activado, desactivado o solo escalar hacia arriba.
  • Con CPU, balanceador o métricas por instancia no puede bajar a cero VMs.
• Actualizaciones progresivas (rolling updates): cambias el template y el MIG sustituye las VMs de forma controlada.
  • Tipo proactive (automático) u opportunistic (solo al recrear VMs).
  • maxSurge: VMs extra permitidas durante la actualización. maxUnavailable: VMs que pueden estar fuera de servicio. Con maxUnavailable=0 y maxSurge positivo consigues actualizaciones sin pérdida de capacidad.
  • Minimal action: refresh, restart o replace.
  • Canary: dos versiones de template a la vez, por ejemplo un 10 % con la nueva.
  • Si algo va mal, vuelves al template anterior con otra actualización (rollback).
• Stateful MIGs: conservan discos, IPs o metadatos por instancia al recrearla. Para aplicaciones con estado que no se pueden rediseñar.

gcloud compute instance-groups managed rolling-action start-update web-mig \
  --region=europe-southwest1 \
  --version=template=projects/PROYECTO/regions/europe-southwest1/instanceTemplates/web-v2 \
  --max-surge=3 --max-unavailable=0

Zonal frente a regional

Consejo de capacidad: en un MIG regional de tres zonas, si una zona cae, las otras dos deben aguantar toda la carga. Sobredimensiona un poco (o deja que el autoescalador lo haga) para ese escenario.

Google Kubernetes Engine (GKE)

GKE es el servicio gestionado de Kubernetes, el orquestador de contenedores de código abierto que nació en Google. Encaja cuando tienes muchos microservicios en contenedores, necesitas portabilidad (Kubernetes funciona igual en otras nubes y en local) o requisitos que Cloud Run no cubre (cargas con estado complejas, protocolos no HTTP, control fino de red y planificación, operadores de Kubernetes, GPUs y TPUs a escala).

Conceptos de Kubernetes que necesitas

Standard frente a Autopilot

GKE tiene dos modos de operación:

Hoy la frontera se difumina: con ComputeClasses puedes ejecutar cargas en modo Autopilot dentro de clusters Standard. El examen, sin embargo, sigue planteándolo como «¿quién gestiona los nodos?».

Precio (consulta la página oficial): una tarifa de gestión de 0,10 USD por cluster y hora en todos los modos, y un crédito mensual de 74,40 USD por cuenta de facturación que cubre la tarifa de un cluster Autopilot o Standard zonal. A eso se suman los recursos de cómputo.

Clusters zonales y regionales

• Zonal: un único plano de control en una zona. Si la zona cae, no puedes gestionar el cluster (las cargas en otras zonas pueden seguir funcionando si el cluster es multizonal).
• Regional: réplicas del plano de control en varias zonas y nodos repartidos. Mayor disponibilidad, también durante las actualizaciones. Recomendado para producción y obligatorio en Autopilot.
• La ubicación no se puede cambiar después: un cluster zonal no se convierte en regional. Tampoco se cambia la VPC ni la subred.

Escalado en GKE

Hay escalado a dos niveles, y el examen los mezcla a propósito:

• Pods: Horizontal Pod Autoscaler (HPA) añade réplicas según CPU, memoria o métricas personalizadas; Vertical Pod Autoscaler (VPA) ajusta las peticiones de CPU y memoria de cada pod.
• Nodos (Standard): cluster autoscaler añade o quita nodos de un node pool cuando hay pods pendientes o nodos infrautilizados; node auto-provisioning crea node pools nuevos del tamaño adecuado. En Autopilot todo esto lo hace Google.

Las versiones se gestionan con canales de lanzamiento (release channels), que controlan cómo de pronto recibes versiones nuevas de Kubernetes y actualizaciones automáticas, y con ventanas y exclusiones de mantenimiento.

Redes de contenedores básicas

• Los clusters nuevos son VPC-native: los pods reciben IPs de un rango secundario de la subred (alias IP) y son direccionables dentro de la VPC sin NAT. Los Services usan otro rango secundario. Planifica bien estos rangos: quedarse sin IPs de pods limita el tamaño del cluster.
• Tipos de Service:
  • ClusterIP (por defecto): IP interna estable, solo dentro del cluster.
  • NodePort: expone un puerto en cada nodo.
  • LoadBalancer: en GKE crea un balanceador de carga de red de paso a través (passthrough Network Load Balancer) regional. Con una anotación puede ser interno.
  • ExternalName: alias DNS a un nombre externo.
  • Headless: sin IP de cluster; el DNS devuelve directamente las IPs de los pods.
• Ingress y Gateway API crean un Application Load Balancer (capa 7, basado en proxy), necesario para HTTPS con certificados, enrutado por ruta o host, Cloud Armor o CDN. Gateway API es la evolución recomendada de Ingress.
• Workload Identity Federation for GKE: permite que un pod actúe con una identidad de IAM sin claves. Es la forma correcta de dar a un pod acceso a Cloud Storage o BigQuery.

Cloud Run

Cloud Run es la plataforma serverless de contenedores: le das una imagen de contenedor (o el código fuente y la construye con buildpacks y Cloud Build) y Google se ocupa de todo lo demás: infraestructura, escalado, TLS, balanceo. Es regional.

Tipos de recurso

• Services (servicios): responden a peticiones HTTP (también gRPC, WebSockets y streaming). Cada despliegue crea una revisión inmutable, y puedes repartir tráfico entre revisiones (canary, azul/verde) y hacer rollback al instante. Reciben una URL https://...run.app.
• Jobs (trabajos): ejecutan tareas hasta completarse, sin escuchar peticiones. Un job puede tener hasta 10.000 tareas en paralelo; cada tarea dura como máximo 10 minutos por defecto y hasta 168 horas (7 días) configurándolo; 3 reintentos por defecto. Se lanzan a mano, con Cloud Scheduler o desde un flujo de trabajo. Ideales para lotes, migraciones de datos o informes nocturnos.
• Worker pools: cargas continuas en segundo plano que extraen trabajo (por ejemplo, de Pub/Sub o Kafka) sin punto de entrada HTTP.

Escalado, concurrencia y facturación

• Escalado a cero: sin tráfico, no hay instancias y no pagas cómputo (en la facturación por peticiones). La primera petición tras un periodo inactivo sufre un arranque en frío (cold start). Para evitarlo, configura instancias mínimas (--min-instances), que sí se pagan.
• Instancias máximas (--max-instances): protegen a sistemas de detrás (por ejemplo, una base de datos con conexiones limitadas) y el coste.
• Concurrencia: cada instancia atiende varias peticiones a la vez. Desde gcloud o Terraform el máximo por defecto es 80 veces el número de vCPU (desde la consola, 80), con un tope de 1.000. Con concurrencia 1 cada petición tiene su instancia, lo que multiplica instancias y arranques en frío: solo tiene sentido si el código no admite concurrencia o cada petición usa toda la CPU.
• Tiempo máximo de petición: 5 minutos por defecto, hasta 60 minutos.
• Facturación: por peticiones (request-based), pagas CPU y memoria solo mientras se procesan peticiones; o por instancias (instance-based), pagas las instancias mientras existen, adecuado para trabajo en segundo plano o tráfico constante. Consulta los precios en cloud.google.com/run/pricing.
• Admite GPUs para inferencia de IA.

Seguridad y red

• Identidad: cada servicio se ejecuta con una cuenta de servicio; crea una específica con los roles mínimos.
• Autenticación de entrada: por defecto requiere IAM (roles/run.invoker). Para una web pública, --allow-unauthenticated.
• Ingress (entrada): all, internal o internal-and-cloud-load-balancing (solo tráfico interno o a través de un balanceador de Google Cloud, por ejemplo para poner delante Cloud Armor).
• Salida hacia la VPC (egress): para llegar a recursos con IP privada (Cloud SQL por IP privada, Memorystore, VMs):
  • Direct VPC egress (opción moderna): el servicio obtiene IPs directamente de una subred (/26 o mayor). Sin conector que pagar; el coste de red escala a cero con el servicio.
  • Serverless VPC Access connector (opción anterior): un conector con instancias propias que se pagan aunque no haya tráfico.
  • Con --vpc-egress=private-ranges-only solo va por la VPC el tráfico a IPs privadas; con all-traffic va todo, lo que permite, por ejemplo, salir a internet con una IP fija mediante Cloud NAT.

gcloud run deploy api --image=europe-southwest1-docker.pkg.dev/PROYECTO/apps/api:1.2 \
  --region=europe-southwest1 --service-account=api-sa@PROYECTO.iam.gserviceaccount.com \
  --network=default --subnet=default --vpc-egress=private-ranges-only \
  --concurrency=80 --min-instances=0 --max-instances=20 --no-allow-unauthenticated

Cloud Run functions

Cloud Run functions es la oferta de funciones como servicio (FaaS): escribes solo una función en Node.js, Python, Go, Java, .NET, Ruby o PHP, y se ejecuta ante una petición HTTP o un evento. Contexto de nombres: antes se llamaba Cloud Functions; la versión actual («2nd gen» en su día) se despliega como un servicio de Cloud Run, y la original pasa a llamarse Cloud Run functions (1st gen).

• Eventos mediante Eventarc: un objeto nuevo en Cloud Storage, un mensaje en Pub/Sub, eventos de Firestore y cualquier evento de más de 90 fuentes a través de Cloud Audit Logs.
• Hereda las capacidades de Cloud Run: concurrencia, instancias mínimas, Direct VPC egress, hasta 16 GiB de memoria y 4 vCPU.
• Despliegue recomendado:

gcloud run deploy procesar-imagen --source=. --function=procesar \
  --base-image=python312 --region=europe-southwest1

(gcloud functions deploy sigue existiendo por compatibilidad.)

Cuándo: código pegamento que reacciona a eventos (redimensionar imágenes al subirlas, procesar un mensaje, un webhook), sin tener que pensar en contenedores. Si la lógica crece o necesitas controlar el contenedor, pasa a un servicio de Cloud Run.

App Engine (heredado)

App Engine fue la plataforma PaaS original de Google Cloud. Sigue existiendo y aparece en preguntas antiguas y en empresas que lo usan, pero la documentación oficial dice que para usuarios nuevos se recomienda Cloud Run como alternativa preferida.

• Standard environment: entornos de ejecución concretos, arranque en segundos, escala a cero.
• Flexible environment: contenedores sobre VMs, arranque en minutos, mínimo una instancia, permite SSH y dependencias nativas.
• Solo hay una aplicación de App Engine por proyecto, y su región no se puede cambiar una vez creada.
• Ofrece reparto de tráfico entre versiones, igual que las revisiones de Cloud Run.

Si una pregunta habla de «aplicación existente en App Engine», respeta ese contexto; si pide diseñar algo nuevo y serverless, la respuesta será casi siempre Cloud Run.

Google Cloud VMware Engine

Google Cloud VMware Engine es un servicio totalmente gestionado para ejecutar la plataforma VMware (vSphere, vCenter, vSAN, NSX, HCX) sobre servidores bare metal dedicados en Google Cloud, en nubes privadas para tu organización. Google gestiona la infraestructura, las actualizaciones de la plataforma y el hardware; tú, tus VMs y su configuración.

Encaja cuando:

• Quieres salir del centro de datos rápido («cierre del CPD en seis meses») con cientos de VMs VMware sin reescribir ni reconvertir nada, y con las mismas herramientas y conocimientos del equipo.
• Necesitas recuperación ante desastres para un entorno VMware local.
• Hay licencias o certificaciones de fabricantes ligadas a VMware.

Después, las VMs pueden modernizarse poco a poco hacia servicios nativos. No está disponible en la prueba gratuita, así que no tiene lab. Su conectividad (redes de VMware Engine, peering con tu VPC) la verás en redes.

Qué plataforma de cómputo elijo

Tabla de decisión

Árbol de decisión

flowchart TD
  A["¿Es un entorno VMware que hay que mover sin cambios?"] -->|Sí| VME["Google Cloud VMware Engine"]
  A -->|No| B["¿Necesitas control del SO, kernel, licencias por hardware o software no contenerizable?"]
  B -->|Sí| C["¿Licencia por núcleo físico o aislamiento de hardware?"]
  C -->|Sí| ST["Compute Engine en sole-tenant nodes"]
  C -->|No| D["¿Varias VMs idénticas que deben escalar o sobrevivir a una zona?"]
  D -->|Sí| MIG["MIG regional con autoescalado"]
  D -->|No| VM["VM de Compute Engine"]
  B -->|No| E["¿Es solo una función que reacciona a un evento o webhook?"]
  E -->|Sí| FN["Cloud Run functions"]
  E -->|No| F["¿Ya usáis Kubernetes o necesitáis su ecosistema, portabilidad o cargas con estado complejas?"]
  F -->|Sí| G["¿Necesitáis controlar los nodos?"]
  G -->|Sí| GS["GKE Standard"]
  G -->|No| GA["GKE Autopilot"]
  F -->|No| H["¿Es una tarea que se ejecuta hasta terminar?"]
  H -->|Sí| JOB["Cloud Run jobs"]
  H -->|No| RUN["Cloud Run services"]

Dos modificadores que se aplican a casi cualquier rama:

• ¿Tolera interrupciones y quieres minimizar coste? Spot VMs (en VMs, MIGs o node pools de GKE).
• ¿Carga estable y conocida durante años? CUDs para abaratar la capacidad base.

Trampas típicas del examen

• Local SSD para datos que deben sobrevivir: incorrecto; se pierden si la VM se detiene.
• Spot para cargas críticas o con estado sin réplica: incorrecto; no tienen SLA ni live migration.
• VMs preemptible: el término actual es Spot VMs; las preemptible tenían un máximo de 24 horas.
• Unmanaged instance group para autoescalar: no autoescala ni se autocura. Necesitas un MIG.
• MIG zonal para alta disponibilidad frente a caída de zona: insuficiente; usa MIG regional.
• Modificar un instance template: no se puede; crea uno nuevo y lanza una rolling update.
• Health check de autocuración sin retardo inicial suficiente: bucle de recreación de VMs.
• Autoescalado a cero con CPU: un MIG no baja a cero con esas señales; si necesitas escalar a cero, piensa en Cloud Run.
• Custom machine types en cualquier serie: solo en las series N y E de uso general, y cuestan un 5 % más.
• GPUs en la prueba gratuita o live migration con GPU: ninguna de las dos cosas.
• Cluster GKE zonal «convertible» a regional: no; se crea de nuevo.
• Service de tipo LoadBalancer para HTTPS con reglas por ruta: no; eso es Ingress o Gateway (Application Load Balancer).
• Claves JSON en un pod: incorrecto; Workload Identity Federation for GKE.
• Cloud Run «siempre caliente» sin coste: las instancias mínimas se pagan.
• Concurrencia 1 en Cloud Run sin motivo: multiplica instancias y arranques en frío.
• Serverless VPC Access connector como primera opción: hoy se prefiere Direct VPC egress.
• App Engine para una aplicación nueva: Google recomienda Cloud Run.
• «Migrar VMware rápido sin cambios»: VMware Engine, no reescribir en GKE.

Resumen

• Compute Engine: VMs zonales con control total; familias (uso general, cómputo, memoria, almacenamiento, aceleradores, red); E2 barata; custom machine types en series N y E (+5 %).
• Hyperdisk es el disco recomendado (IOPS y rendimiento independientes), Persistent Disk el heredado, Local SSD es temporal.
• Spot VMs: hasta -91 %, reclamables en cualquier momento, sin SLA ni duración máxima; para cargas tolerantes a fallos.
• Imágenes (globales, familias), snapshots incrementales, machine images e instance templates inmutables (obligatorios para MIGs).
• Sole-tenant para licencias por hardware y aislamiento; GPUs en series A y G o en N1, sin live migration.
• MIG regional = alta disponibilidad con VMs: autocuración, autoescalado (CPU, balanceador, métricas, horarios, predictivo) y rolling updates (maxSurge, maxUnavailable, canary).
• GKE: Autopilot por defecto (Google gestiona nodos, pago por pod, regional); Standard si necesitas controlar nodos; clusters regionales en producción; HPA/VPA y cluster autoscaler; VPC-native; Ingress o Gateway para HTTP(S).
• Cloud Run: contenedores serverless con escala a cero, concurrencia, revisiones con reparto de tráfico, jobs para lotes y Direct VPC egress.
• Cloud Run functions para eventos; App Engine es heredado; VMware Engine para mover VMware sin cambios.
• Elige siempre la plataforma más gestionada que cumpla los requisitos.

Practica lo aprendido

Documentación oficial para ampliar

• Machine families resource and comparison guide
• Choose a disk type
• Spot VMs
• Instance groups
• Autoscaling groups of instances
• Automatically apply VM configuration updates in a MIG
• Sole-tenant nodes
• Autopilot overview
• GKE cluster types
• What is Cloud Run
• Direct VPC egress with Cloud Run
• Cloud Run functions comparison
• Google Cloud VMware Engine overview
• GKE pricing