Google PCD: Cómputo, contenedores y plataformas de ejecución Serverless — Guía de estudio

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Developer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Google Cloud ofrece múltiples plataformas de ejecución que abarcan máquinas virtuales, contenedores y serverless. La elección de la plataforma correcta depende de las características de la carga de trabajo, como los patrones de solicitud, la gestión del estado, la disciplina de compilación y lanzamiento, el modelo operativo y las restricciones de red. Esta sección cubre los principios de diseño, los modos de fallo y los compromisos para Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE) y Compute Engine, junto con los servicios de soporte para imágenes, identidad, redes, configuración y operaciones.

Entornos de ejecución sin servidor (Serverless): Cloud Run, App Engine, Cloud Functions

Cloud Run

• Modelo: Contenedores totalmente gestionados con manejo de solicitudes HTTP o Jobs en contenedores que se ejecutan hasta su finalización.
• Revisiones y tráfico: Cada despliegue crea una revisión inmutable. Dividir el tráfico por porcentaje entre las revisiones permite patrones canary y blue-green con reversión instantánea. Ejemplo:

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

• Concurrencia y escalado: La concurrencia predeterminada es de 80; establécela en 1 para código no seguro para hilos (non-thread-safe) o que consume mucha CPU (CPU-bound). Una mayor concurrencia reduce la amplificación del arranque en frío (cold-start) y el costo, but puede aumentar la latencia de cola si la CPU/memoria por solicitud es inadecuada. Cloud Run escala a cero y hacia arriba según la tasa de solicitudes entrantes; contrólalo con instancias mínimas/máximas para reducir los arranques en frío y limitar el costo.
• Asignación de CPU: Elige “CPU siempre asignada” para trabajos en segundo plano entre solicitudes a costa de una facturación adicional; de lo contrario, la CPU solo se asigna mientras se manejan las solicitudes.
• Jobs: Los Cloud Run Jobs ejecutan N tareas en paralelo hasta su finalización con reintentos máximos por tarea y tiempos de espera generales; adecuados para procesamiento ETL, por lotes (batch) y de distribución ramificada (fan-out). Los modos de fallo incluyen la creación de puntos calientes (hot-spotting) en los backends cuando muchas tareas apuntan a la misma dependencia; añade limitación de velocidad y reintentos con retirada exponencial (backoff).
• Redes: Público, autenticado a través de IAM, o privado detrás de una VPC a través de Serverless VPC Access y Private Service Connect.

App Engine

• Entornos:
  • Estándar: Entornos aislados (sandboxed), escalado rápido, tiempos de ejecución fijos por lenguaje; baja latencia de arranque en frío con escalado automático; sistema de archivos restringido, tiempos de espera de solicitud y límites de tamaño de solicitud de entrada. Usa URLs firmadas de Cloud Storage para subidas grandes.
  • Flexible: Basado en Docker, capacidades similares a las de una VM, tiempos de ejecución personalizados, escalado más lento que el Estándar, admite hilos en segundo plano y escritura en el disco local.
• Servicios y versiones: Un servicio (microservicio) puede alojar múltiples versiones; enruta el tráfico por porcentaje entre versiones de manera similar a Cloud Run. Usa dispatch.yaml para enrutar rutas o hosts específicos a servicios para un enrutamiento simple y centralizado sin un balanceador de carga externo.
• Escalado: Manual, básico o automático en el Estándar; escalado basado en el número de VMs en el Flexible. Compromiso: un autoescalado agresivo mejora la capacidad de respuesta pero puede aumentar el costo y la contención en el backend.
• Errores comunes: Un escalado de instancias sin límites ni cuotas puede sobrecargar los sistemas dependientes (downstream); aplica cuotas y disyuntores (circuit breakers).

Cloud Functions

• Manejadores orientados a eventos: Se activan por eventos de HTTP, Pub/Sub, Cloud Storage o Eventarc. Usa la 2ª generación para aprovechar el modelo de ejecución de Cloud Run, el control de salida de VPC y la concurrencia; la 1ª generación procesa una solicitud a la vez.
• Reintentos e idempotencia: Las funciones en segundo plano pueden reintentarse en caso de fallo; diseña manejadores idempotentes y usa claves de deduplicación para evitar el doble procesamiento. Los activadores HTTP no son reintentados por la plataforma; implementa reintentos del lado del cliente con retirada exponencial (exponential backoff).
• Configuración del entorno de ejecución: Variables de entorno, integración con Secret Manager y concurrencia/instancias-máximas por función. Establece tiempos de espera para contener costos descontrolados. Ten cuidado con los arranques en frío prolongados con dependencias grandes; mantén los paquetes ligeros.

Contenedores en Google Kubernetes Engine

Cargas de trabajo

• Deployments: Pods sin estado con actualizaciones progresivas (rolling updates). Asegura despliegues seguros con límites de excedente/no disponible (surge/unavailable):

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

• StatefulSets: IDs de red estables y ordenados, y volúmenes persistentes para servicios con estado.
• DaemonSets, Jobs, CronJobs: Agentes a nivel de nodo y cargas de trabajo por lotes.

Services e Ingress

• Tipos de Service:
  • ClusterIP para uso solo interno.
  • NodePort para acceso externo simple (operacionalmente limitado).
  • LoadBalancer para balanceo de carga externo/interno regional.
• Ingress: Enrutamiento HTTP(S) y terminación TLS; prefiere la Gateway API o Ingress con controladores gestionados para políticas de L7. Modo de fallo: las comprobaciones de estado fallan debido al firewall; permite los rangos de IP del balanceador de carga hacia los nodos del backend.

Autoescalado y grupos de nodos (Node Pools)

• Horizontal Pod Autoscaler (HPA): Escala pods según CPU, memoria o métricas personalizadas; combínalo con Pod Disruption Budgets para proteger la disponibilidad.
• Vertical Pod Autoscaler (VPA): Ajusta el tamaño correcto de las solicitudes/límites de los pods; evita usar HPA+VPA simultáneamente en la misma dimensión para prevenir bucles de retroalimentación.
• Cluster Autoscaler: Añade/elimina nodos para satisfacer las solicitudes de recursos de pods pendientes.
• Grupos de nodos (Node pools): Separa los grupos por clase de carga de trabajo. Usa taints/tolerations y etiquetas para la programación (scheduling). Mezcla instancias spot/preemptible para cargas de trabajo sensibles al costo con tolerancia a interrupciones. Elige tipos de máquina con suficiente ancho de banda de memoria/CPU para los límites por pod para evitar la limitación (throttling).

Salud y despliegues (rollouts)

• Sondas de actividad (liveness), preparación (readiness) e inicio (startup) evitan que se envíe tráfico a pods no preparados y reinician contenedores bloqueados. Sondas de actividad muy estrictas pueden causar reinicios en cascada; ajusta los retrasos iniciales y los umbrales de fallo.
• Reversión con kubectl rollout undo. Para un despliegue canary, usa múltiples Deployments y división de tráfico a nivel de Service a través de Ingress/Gateway.

Compute Engine para cargas de trabajo de aplicaciones

Diseño de VM

• Las plantillas de instancia definen el tipo de máquina, la imagen, los discos, los alcances de la cuenta de servicio, los scripts de inicio y los metadatos. Mantén las imágenes al mínimo; utiliza scripts de inicio o imágenes creadas con Packer para un arranque determinista.
• Discos: Usa discos persistentes balanceados o SSD para aplicaciones sensibles a la latencia. Comparte grandes conjuntos de datos de solo lectura en un grupo de instancias administrado mediante un disco persistente de solo lectura adjunto a varias instancias para una baja latencia y un inicio rápido.
• Redes: Crea reglas de firewall para los verificadores de estado (health checkers) cuando uses balanceadores de carga. Ejemplo:

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

Grupos de instancias administrados (MIGs)

• Autoescalado por CPU, solicitudes por segundo del balanceador de carga, métricas personalizadas o programaciones. Establece períodos de enfriamiento (cool-downs) para evitar la oscilación excesiva (thrashing).
• Autorreparación con verificaciones de estado que reinicia las VM en mal estado; asegúrate de que la ruta de la verificación de estado pruebe que la aplicación está lista, no solo la accesibilidad del puerto, para evitar servir errores 500.
• Actualizaciones progresivas y azul-verde: Crea una nueva plantilla de instancia e inicia una actualización canary en un subconjunto de instancias. Si los errores aumentan, revierte a la plantilla anterior. Las verificaciones de tiempo de actividad (uptime checks) y las alertas basadas en SLO detectan degradaciones rápidamente.

Registro y monitoreo

• Instala agentes para recopilar registros de la aplicación sin cambios en el código; envíalos a Cloud Logging y alerta a través de Cloud Monitoring. Usa Debug Logpoints para diagnósticos en vivo con una interrupción mínima.

Compilación, Identidad, Redes, Secretos y Operaciones

Artifact Registry e imágenes

• Usa Artifact Registry para imágenes de contenedor y artefactos de lenguaje. Habilita el escaneo de vulnerabilidades y la generación de procedencia. Mantén las imágenes pequeñas:
  • Compilaciones multifase para separar la compilación y el tiempo de ejecución.
  • Evita herramientas de desarrollo en la imagen final; fija las versiones del SO y de los paquetes. Ejemplo:

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

• Promoción: Etiqueta las imágenes de forma inmutable (p. ej., app:1.3.7, app:prod-20240901) y promuévelas reetiquetando en Artifact Registry; evita la etiqueta mutable latest en producción. Controla las promociones con los resultados de las pruebas de integración y canarias.

Identidad en tiempo de ejecución y privilegio mínimo

• Asigna una cuenta de servicio dedicada por carga de trabajo con los roles de IAM mínimos requeridos. Evita roles amplios como Editor. En GKE, mapea los ServiceAccounts de Kubernetes a cuentas de servicio de Google a través de Workload Identity. Para serverless, establece explícitamente la cuenta de servicio de tiempo de ejecución y elimina los alcances (scopes) del token predeterminado.

Conectores de VPC y redes de servicios

• Los conectores de Serverless VPC Access enrutan el egreso desde Cloud Run, Cloud Functions y App Engine hacia una VPC. Elige el modo de egreso:
  • Solo rangos privados para alcanzar servicios RFC1918 y conectados a la VPC, mientras que el egreso público va directo.
  • Todo el tráfico a través del conector más Cloud NAT para IPs de egreso deterministas y políticas de salida restringidas.
• Dependencias privadas: Prefiere IP privada para Cloud SQL y Private Service Connect para las APIs de Google o servicios de socios. Asegúrate de que los conectores coincidan en región y estén dimensionados para el rendimiento (throughput); monitorea la CPU del conector para evitar la limitación (throttling).

Configuración, secretos y verificaciones de estado

• Usa variables de entorno para la configuración no secreta. Almacena los secretos en Secret Manager y móntalos o inyéctalos en tiempo de ejecución; rota las claves regularmente. En GKE, usa Secrets y el driver CSI para Secret Manager. En App Engine y Cloud Run, otorga a la cuenta de servicio acceso a secretos específicos.
• Verificaciones de estado (Health checks):
  • Cloud Run: la instancia se reinicia en caso de fallo; usa verificaciones a nivel de solicitud y SLIs de latencia.
  • App Engine: verificaciones de estado integradas; personaliza liveness/readiness para el entorno Flexible.
  • GKE: configura sondas de liveness/readiness/startup.
  • Compute Engine detrás de balanceadores de carga (LBs): usa verificaciones de estado HTTP(S) con endpoints específicos de la aplicación.

Resolución de problemas, reversión y patrones de lanzamiento

• Azul-verde y canario con división de tráfico en Cloud Run y App Engine; en GKE, usa Deployments paralelos o controladores de entrega progresiva; en los MIGs, usa subconjuntos canarios de instancias. Define siempre criterios de cancelación basados en el presupuesto de errores del SLO y la latencia.
• Modos de fallo comunes:
  • Estampidas (thundering herds) después de escalar a cero o en despliegues grandes; mitígalo con instancias mínimas, calentamientos (warmups) y limitación de velocidad (rate limiting).
  • Cuotas del backend o límites de conexión excedidos; aplica retroceso exponencial (exponential backoff) y disyuntores (circuit breakers).
  • Arranques en frío (cold starts) debido a imágenes o dependencias grandes; reduce el tamaño de las imágenes y preinicializa los clientes.

Escenario de Problema Práctico

Acme Retail planea migrar una API de redimensionamiento de imágenes desde VMs autogestionadas a una plataforma escalable y rentable con respuestas de baja latencia, acceso privado a un bucket regional de Cloud Storage y lanzamientos canarios seguros.

Enfoque

1. Empaqueta el servicio como una imagen de contenedor pequeña y publícala en Artifact Registry.

• Justificación: Una compilación Docker multifase y reducida minimiza los arranques en frío y la transferencia de red. Artifact Registry centraliza los escaneos y los flujos de trabajo de promoción.

2. Despliega la API en Cloud Run con un mínimo de 2 instancias, una concurrencia de 40 y la opción de CPU siempre asignada deshabilitada.

• Justificación: Cloud Run proporciona escalado horizontal instantáneo y HTTPS gestionado. Un pequeño grupo de instancias mínimas reduce la latencia de arranque en frío durante los picos diurnos. Una concurrencia de 40 equilibra el costo y la latencia de cola para las transformaciones de imágenes que dependen de E/S. Deshabilitar la CPU siempre activa evita pagar por cómputo inactivo entre solicitudes.

3. Crea un conector de Serverless VPC Access y establece el egreso solo para rangos privados; habilita el Acceso Privado a Google en la subred y configura un endpoint de VPC-SC o Private Service Connect para Cloud Storage si es necesario.

• Justificación: La API debe obtener y escribir imágenes de forma privada sin egreso público. El modo de rangos privados asegura que solo el tráfico de la VPC pase por el conector, manteniendo las llamadas públicas directas y eficientes. El Acceso Privado a Google o Private Service Connect proporciona acceso privado a las APIs de Google desde la VPC.

4. Otorga a una cuenta de servicio de tiempo de ejecución dedicada acceso de privilegio mínimo al bucket de Cloud Storage de destino y a los secretos requeridos.

• Justificación: El principio de privilegio mínimo limita el radio de impacto. La identidad de tiempo de ejecución recibe los roles storage.objectViewer y storage.objectAdmin en el bucket específico, y el rol de accesor en los secretos necesarios de Secret Manager.

5. Almacena las claves de API y la configuración por entorno en Secret Manager y en variables de entorno; inyecta los secretos en tiempo de ejecución.

• Justificación: Rotación centralizada de secretos y acceso auditable. La configuración no secreta a través de variables de entorno apoya las prácticas de 12 factores.

6. Implementa retroceso exponencial (exponential backoff) y escrituras idempotentes para manejar errores 429/5xx de Cloud Storage.

• Justificación: Durante ráfagas de tráfico o eventos regionales, pueden ocurrir errores transitorios. El retroceso con fluctuación (jitter) protege tanto a la API como a Cloud Storage de tormentas de reintentos.

7. Configura una revisión canaria y divídele el 10% del tráfico; monitorea la tasa de errores, la latencia P95 y la saturación.

• Justificación: La división de tráfico en Cloud Run permite un despliegue progresivo seguro. Los monitores basados en SLO proporcionan disparadores de reversión automática si los presupuestos de errores se consumen demasiado rápido.

8. Añade un endpoint de verificación de estado HTTP que ejercite las dependencias posteriores; establece alertas en las verificaciones de tiempo de actividad (uptime checks) de Cloud Monitoring y en métricas basadas en registros.

• Justificación: La verificación de estado de extremo a extremo detecta fallos en las dependencias de forma temprana. Las verificaciones de tiempo de actividad proporcionan una perspectiva externa; las métricas basadas en registros capturan patrones de fallo específicos de la aplicación.

9. Establece límites de autoescalado y presupuestos; fija un máximo de instancias para limitar el gasto y define el manejo de errores 429 por sobrecarga.

• Justificación: Limitar la escala previene costos descontrolados y el agotamiento del backend. Un comportamiento de sobrecarga controlado mantiene la estabilidad del servicio.

10. Documenta la reversión (rollback): desvía el 100% del tráfico de vuelta a la revisión anterior de Cloud Run con un solo comando.

• Justificación: Las revisiones inmutables hacen que la reversión sea segura y rápida, minimizando el tiempo medio de recuperación (MTTR).

← Arquitectura de aplicaciones nativas de la nube y selección de servicios · Todos los dominios · Diseño de API →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →