Tema 2 de 11
Compute Engine: crear y configurar instancias
Lanzar una VM parece trivial, pero el temario pide decisiones concretas: la política de disponibilidad, las claves SSH, OS Login, VM Manager, las Spot VMs y los tipos de máquina personalizados. Cada una cambia el coste, la seguridad o el comportamiento ante el mantenimiento de Google.
Contenido
Crear una instancia
La página Create an instance de la consola organiza las opciones en paneles: Machine configuration (nombre, zona, tipo de máquina), OS and storage (disco de arranque e imagen), Data protection, Networking, Observability (Ops Agent), Security y Advanced (metadatos, reservas, modelo de aprovisionamiento, nodos de un solo inquilino). El botón Equivalent code genera el comando gcloud, REST o Terraform equivalente.
gcloud compute instances create web-1 --zone=us-central1-a \ --machine-type=e2-medium --image-family=debian-13 --image-project=debian-cloud
--image-familyusa la imagen más reciente y no obsoleta de la familia;--imagefija una versión concreta.- Para crear muchas a la vez:
gcloud compute instances bulk create. Para ejecutar una imagen de contenedor:create-with-container. - La mayoría de las imágenes públicas no tienen coste extra, salvo las premium. Importar imágenes propias es gratis, pero se paga su almacenamiento.
- Quien se conecta a una VM puede usar todos los permisos IAM de la cuenta de servicio asociada a ella.
Familias y tipos de máquina
| Familia | Series | Para qué |
|---|---|---|
| Uso general | N4, N4A, N4D, N2, N2D, N1 · C4, C4A, C4D, C3, C3D · E2 · Tau T2D, T2A | N: equilibrio precio/rendimiento. C: alto rendimiento constante. E2: uso diario a menor coste. Tau: cargas scale-out |
| Optimizada para almacenamiento | Z3, Z4D, Z4M | Bases SQL/NoSQL, analítica, búsqueda |
| Optimizada para cómputo | H4D, H3, C2, C2D | HPC, simulación, cargas limitadas por CPU |
| Optimizada para red | C4N, M4N | Cargas intensivas en E/S y ancho de banda |
| Optimizada para memoria | X5, X4, M4, M3, M2, M1 | SAP HANA, bases en memoria |
| Optimizada para aceleradores | A4X Max, A4X, A4, A3, A2, G4, G2 | IA generativa, entrenamiento e inferencia, HPC, transcodificación |
Los tipos shared-core comparten un núcleo físico para apps pequeñas: e2-micro, e2-small y e2-medium (2 vCPU en ráfagas cortas) y f1-micro y g1-small en N1.
Tipos de máquina personalizados
Si ningún tipo predefinido encaja, puedes elegir el número de vCPU y la cantidad de memoria. Disponibles en las series N4, N4D, N4A, N2, N2D, E2 y N1, y en G2 entre las optimizadas para aceleradores.
Cuándo
Cargas que no encajan en los predefinidos, que necesitan algo más de CPU o memoria sin saltar al siguiente tamaño, o software licenciado por CPU.
Precio
Un 5 % más caro que el predefinido equivalente, tanto bajo demanda como con compromisos.
Memoria extendida
Más memoria por vCPU que el máximo por defecto, con sobrecoste. Disponible en N4, N4A, N4D, N2, N2D y N1.
gcloud compute instances create app-1 --zone=us-central1-a \ --custom-vm-type=n2 --custom-cpu=6 --custom-memory=40960
Cada serie tiene un mínimo y un máximo de memoria por vCPU; con --custom-extensions se pide memoria extendida.
Spot VMs
Capacidad sobrante de Compute Engine con descuentos de hasta el 91 % en muchos tipos de máquina, GPU, TPU y Local SSD. A cambio, Compute Engine puede interrumpirlas (preempt) en cualquier momento. Son la versión actual de las VM interrumpibles (preemptible).
- Sin duración mínima ni máxima, salvo que limites la ejecución.
- Al interrumpirlas se detienen (STOP, por defecto) o se borran (DELETE), según la acción de terminación.
- Aviso: Compute Engine marca
preempted=TRUEen los metadatos. El aviso previo puede ser de 0 s (por defecto) o de 120 s; después llega la señal de apagado y un periodo de apagado de hasta 30 segundos (best effort), en el que corre el shutdown script. - No pueden migrar en vivo ni reiniciarse automáticamente tras un evento del host, y no tienen SLA.
- Si se interrumpen en su primer minuto, no se cobran. Detenidas no cobran horas de VM, pero los discos persistentes sí.
- No admiten la serie A4X ni bare metal, y no aplican los créditos del nivel gratuito. Su precio puede cambiar hasta una vez al día.
gcloud compute instances create batch-1 --zone=us-central1-a \ --machine-type=n2-standard-8 --provisioning-model=SPOT \ --instance-termination-action=STOP --preemption-notice-duration=120s \ --metadata shutdown-script=SHUTDOWN_SCRIPT
Política de disponibilidad (host maintenance)
El host de una VM sufre eventos: mantenimiento programado, mantenimiento urgente (normalmente con 7 a 14 días de aviso) o errores de hardware. La política de mantenimiento del host decide qué hace la VM:
| Ajuste | Opciones |
|---|---|
| Comportamiento en mantenimiento | MIGRATE (por defecto en la mayoría): migración en vivo sin apagar, con una breve bajada de rendimiento. TERMINATE: apagado suave, 60 s de espera y estado TERMINATED |
| Reinicio automático | Por defecto activado: tras un error del host, la VM se reinicia normalmente en unos 3 minutos (hasta 5,5). No aplica si la apagas tú desde el SO |
| Tiempo de detección de error | Entre 90 y 330 segundos antes de reiniciar una VM que no responde |
| Recuperación de Local SSD | De 0 a 168 horas intentando recuperar los datos (por defecto, una hora) |
No admiten migración en vivo
Instancias con GPU o TPU, bare metal, H4D, X4 y X5, la mayoría de las Confidential VM y ciertas configuraciones Z3/Z4 con mucho Titanium SSD. Se detienen en los eventos del host.
gcloud compute instances set-scheduling web-1 --zone=us-central1-a \ --maintenance-policy=MIGRATE --restart-on-failure
Los eventos quedan en las operaciones de zona y en los registros de eventos del sistema: compute.instances.migrateOnHostMaintenance o terminateOnHostMaintenance.
Acceso SSH: claves en metadatos
Para gestionar el acceso de usuarios a VM Linux hay dos métodos: OS Login (recomendado en la mayoría de los casos) o claves SSH en los metadatos, para quien tiene su propio servicio de directorio o no puede usar OS Login. Si te conectas desde la consola o con gcloud compute ssh, Compute Engine crea las claves por ti.
Metadatos del proyecto
Clave ssh-keys válida para todas las VM del proyecto, salvo las que activen Block project-wide SSH keys.
Metadatos de la instancia
Claves válidas solo para esa VM. Se añaden al crearla o después, y pueden llevar fecha de caducidad.
Riesgos de gestionar claves a mano
- Todos los usuarios con claves en metadatos tienen sudo.
- Hay que borrar a mano las claves de quien se va del proyecto.
- Un comando mal escrito puede borrar todas las claves públicas del proyecto o de la VM.
- Quien puede modificar los metadatos del proyecto puede añadir claves para todas sus VM.
OS Login
Vincula la cuenta Linux a la identidad de Google y controla el SSH con IAM, sin crear ni gestionar claves individuales. Es la forma recomendada para muchos usuarios en varias VM o proyectos.
Ciclo de vida automático
La misma cuenta Linux en todas las VM del proyecto u organización.
Autorización con IAM
Puedes permitir el acceso sin sudo. Al retirar el rol se revoca el acceso; se comprueba en cada inicio de sesión.
2FA y certificados
Verificación en dos pasos opcional y autenticación con certificados SSH.
Auditoría
Registros de auditoría de las conexiones. Puede importar cuentas Linux de AD o LDAP.
| Rol | Acceso |
|---|---|
roles/compute.osLogin | Inicio de sesión sin sudo |
roles/compute.osAdminLogin | Inicio de sesión con sudo |
roles/iam.serviceAccountUser | Necesario además si la VM se ejecuta con una cuenta de servicio |
# Para todo el proyecto gcloud compute project-info add-metadata --metadata enable-oslogin=TRUE # Para una VM concreta gcloud compute instances create vm-1 --metadata enable-oslogin=TRUE ... # 2FA (requiere también enable-oslogin=TRUE) --metadata enable-oslogin-2fa=TRUE
- Con OS Login activado, la VM ignora las claves SSH de los metadatos.
enable-oslogin=FALSEen la instancia lo desactiva aunque el proyecto lo tenga en TRUE.- La política de organización
compute.requireOsLoginlo impone en toda la organización. - Los nombres de usuario siguen el formato
USUARIO_DOMINIO_SUFIJO; los usuarios de otra organización llevan el prefijoext_y las cuentas de serviciosa_.
VM Manager
Conjunto de herramientas para gestionar el sistema operativo de grandes flotas de VM Windows y Linux en Compute Engine:
Patch
Parches bajo demanda y programados, e informes de cumplimiento de parches.
OS inventory management
Recoge información del sistema operativo. Alimenta el tipo OS_INVENTORY de Cloud Asset Inventory.
OS policies
Instalar, quitar y actualizar automáticamente paquetes de software.
Habilitar la OS Config API. En el proyecto, o en todos los de una carpeta u organización.
Tener el agente de OS Config. Viene en muchas imágenes públicas; compruébalo en cada VM.
Activar los metadatos. enable-osconfig=TRUE en el proyecto o en cada VM. Una política de organización puede imponerlo.
Escenarios de examen
| Situación | Respuesta | Por qué |
|---|---|---|
| Un software se licencia por vCPU y necesita 6 vCPU y 40 GB de RAM | Tipo de máquina personalizado | Ajusta vCPU y memoria a la licencia. |
| Trabajo por lotes tolerante a fallos al menor coste | Spot VMs | Hasta un 91 % de descuento, pero pueden ser interrumpidas. |
| La VM debe seguir funcionando durante el mantenimiento de Google | Política de mantenimiento MIGRATE | Migración en vivo a otro host. |
| Una VM con GPU recibe un evento de mantenimiento | Se detiene (TERMINATE) | Las instancias con GPU no admiten migración en vivo. |
| Gestionar el SSH de 200 ingenieros con sus cuentas de Google | OS Login con roles IAM | Sin gestionar claves a mano; se revoca al quitar el rol. |
| Dar acceso SSH sin sudo | roles/compute.osLogin | osAdminLogin da sudo. |
| Parchear de forma programada 500 VM Linux y Windows | VM Manager (Patch) | Parches bajo demanda y programados. |
| Servidor web pequeño de poco tráfico al menor coste | E2 (incluidos los shared-core) | Uso diario a menor coste. |
Trampas frecuentes del examen
❓ ¿Una Spot VM tiene SLA?
No. Está excluida del SLA de Compute Engine porque puede ser interrumpida en cualquier momento.
❓ ¿Qué pasa por defecto cuando se interrumpe una Spot VM?
Se detiene (STOP) y queda en TERMINATED. Solo se borra si la acción de terminación es DELETE.
❓ ¿Se puede usar OS Login y claves SSH en metadatos a la vez en una VM?
No. Con OS Login activado, la VM ignora las claves de los metadatos.
❓ ¿Una VM con GPU puede migrar en vivo?
No. Las instancias con GPU o TPU se detienen durante los eventos del host.
❓ ¿Los tipos de máquina personalizados cuestan lo mismo que los predefinidos?
No. Tienen un recargo del 5 %, y la memoria extendida cuesta aparte.
❓ ¿Qué rol de OS Login da sudo?
roles/compute.osAdminLogin. roles/compute.osLogin da acceso sin sudo.
❓ ¿Cuánto dura como máximo el apagado de una Spot VM interrumpida?
Hasta 30 segundos, best effort, tras el aviso previo opcional de 120 segundos.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un equipo de 150 desarrolladores necesita SSH a las VM Linux de varios proyectos. Cuando alguien deja la empresa, su acceso debe desaparecer al instante sin tocar las VM, y solo los administradores deben tener sudo. ¿Qué configura?
¿Listo para poner a prueba "Compute Engine: crear y configurar instancias"?
Preguntas originales, cada una con su explicación.
Empezar un simulacro