Google ACE: Contenedores, alojamiento de aplicaciones y plataformas serverless — Guía de estudio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Forma parte de la Google Associate Cloud Engineer — 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 una gama de plataformas para ejecutar contenedores y aplicaciones, desde plataformas serverless totalmente gestionadas hasta clústeres de Kubernetes configurables. Seleccionar y operar la plataforma correcta requiere comprender los planos de control, los modelos de escalado, los mecanismos de lanzamiento, las redes y la seguridad. Esta sección consolida la guía operativa para Google Kubernetes Engine (GKE), Artifact Registry, Cloud Run, App Engine y Cloud Functions, junto con patrones para secretos, despliegues seguros y diagnósticos.

Kubernetes Engine: Clústeres, Cargas de Trabajo y Redes

Los clústeres de GKE proporcionan un plano de control de Kubernetes gestionado con grupos de nodos que tú dimensionas y proteges. Elige Autopilot para una mínima sobrecarga operativa y valores predeterminados recomendados, o Standard para un control granular de los nodos, las redes y los complementos. Utiliza canales de lanzamiento y la actualización automática de nodos para actualizaciones predecibles y seguras; habilita la reparación automática de nodos. Prefiere Container-Optimized OS para nodos con seguridad reforzada, a menos que paquetes específicos requieran Ubuntu.

• Grupos de nodos y programación (scheduling)

  • Separa los grupos de nodos por clase de carga de trabajo (p. ej., general, GPU, spot) y usa taints/tolerations para dirigir los Pods.
  • Habilita el autoescalador de clúster y configura un mín/máx por grupo. Ten en cuenta que los PodDisruptionBudgets y las solicitudes de recursos pueden bloquear el escalado hacia dentro (scale-in) o dejar Pods en estado pendiente si las solicitudes exceden las formas de nodo disponibles.
  • Los nodos Spot/preemptible reducen el coste pero introducen riesgo de expulsión (eviction); combínalos con presupuestos de sobrecarga (surge) del Deployment y restricciones de topología de Pods para mayor resiliencia.

• Namespaces y multi-tenancy

  • Usa namespaces para dividir cuotas, políticas y RBAC. Aplica NetworkPolicies para restringir el tráfico este-oeste. Impón los estándares de Pod Security a nivel de namespace para evitar cargas de trabajo con privilegios.

• Cargas de trabajo

  • Los Deployments gestionan Pods sin estado (stateless) con actualizaciones continuas, presupuestos de sobrecarga/no disponibles (surge/unavailable) y reversiones rápidas. Usa sondas de preparación (readiness) para controlar el paso del tráfico y sondas de actividad/arranque (liveness/startup) para la autorreparación. Las sondas de preparación mal configuradas pueden causar un agujero negro de tráfico; pruébalas antes de pasar a producción.
  • Los StatefulSets proporcionan identidades estables y escalado ordenado para bases de datos y sistemas basados en quórum. Usa un Service sin cabecera (headless) y una StorageClass que soporte aprovisionamiento dinámico; planifica la localidad zonal de los PV.
  • Los DaemonSets programan un Pod por nodo (p. ej., agentes de logging/monitorización). Respetan el autoescalado y los eventos de drenaje (drain) y son ideales para la telemetría a nivel de nodo.

• Services e Ingress

  • ClusterIP expone un DNS y un balanceo de carga dentro del clúster. NodePort se usa principalmente para la resolución de problemas. LoadBalancer aprovisiona un balanceador de carga TCP/UDP externo o interno de Google Cloud; usa el interno para servicios privados.
  • GKE Ingress configura el balanceo de carga HTTP(S) global con certificados gestionados, mapas de URL y Cloud Armor. Para una gestión de tráfico moderna, prefiere el balanceo de carga nativo de contenedores (NEG) para comprobaciones de estado por Pod y una convergencia más rápida. Asegúrate de que los endpoints de preparación (readiness) reflejen el estado real de la aplicación; de lo contrario, el backend se volverá no saludable, causando errores 502.

• Autoescalado

  • Horizontal Pod Autoscaler escala las réplicas según métricas como la CPU o métricas personalizadas a través de Cloud Monitoring; asegúrate de que el Metrics Server esté saludable. Vertical Pod Autoscaler puede dimensionar correctamente las solicitudes; evita conflictos con HPA usando VPA en modo de “recomendación” para cargas de trabajo gestionadas por HPA o usa el modo compatible HPA+VPA con cuidado.
  • El autoescalador de clúster añade/elimina nodos para alojar los Pods. Si los Pods solicitan más recursos de los que ofrece cualquier forma de nodo, nunca se programarán; alinea las solicitudes/límites con las formas de los grupos de nodos.

Ejemplos cortos:

• Revertir una versión con fallos:

undefined

• Inspeccionar otro contexto rápidamente:

undefined

Gestión de Artefactos, Seguridad de la Cadena de Suministro y Lanzamientos Seguros

Artifact Registry aloja imágenes de contenedor por región con soporte para VPC Service Controls. Adopta repositorios (o prefijos) separados para los entornos y exige etiquetas inmutables; despliega por ‘digest’ para eliminar la ambigüedad. Integra Cloud Build o tu CI para compilar y enviar con metadatos de procedencia.

• Gestión de vulnerabilidades

  • Habilita Artifact Analysis para escanear imágenes en busca de CVEs del sistema operativo y del lenguaje. Interrumpe las compilaciones o bloquea la promoción si se encuentran hallazgos de alta gravedad. Combínalo con Binary Authorization para requerir firmas/atestaciones (p. ej., aprobación de la política de vulnerabilidades, procedencia SLSA) antes de la admisión en GKE.

• Promoción de imágenes

  • Promociona copiando el ‘digest’ de una imagen de los repositorios de desarrollo a los de staging/producción o reetiquetando en un repositorio de promoción; evita la etiqueta mutable “latest”. Automatiza con activadores de Cloud Build condicionados a los resultados de las pruebas y los escaneos.

• Secretos y configuración

  • Prefiere Secret Manager con acceso de privilegios mínimos. En GKE, usa el controlador CSI de Secret Manager con Workload Identity para que los nodos nunca vean secretos de larga duración. Para configuraciones KRM, separa ConfigMap (no secreto) de Secret (sensible) y móntalos como solo lectura.
  • Para serverless, monta los secretos mediante vinculaciones directas de Secret Manager; evita incrustar secretos en variables de entorno a menos que sea estrictamente necesario.

• Patrones de reversión y lanzamiento

  • Kubernetes: usa actualizaciones continuas (rolling updates) con maxUnavailable=0 para no tener tiempo de inactividad y maxSurge ajustado a la capacidad; haz un canary con dos Deployments detrás de un único Service o usa una malla de servicios (Service mesh) para porcentajes graduales. Protege las cargas de trabajo críticas con PodDisruptionBudgets y minReadySeconds.
  • Cloud Run y App Engine: usa revisiones/versiones y división de tráfico para despliegues canary y azul/verde (blue/green). Mantén las revisiones anteriores “calientes” (warm) para reducir la latencia de la reversión.
  • Modos de fallo: la desviación por etiquetas mutables, las brechas en el tiempo de escaneo y las sondas de preparación (readiness) mal especificadas son causas comunes de interrupciones del servicio. Usa ‘digests’ de imagen, comprobaciones previas al despliegue y sondas de estado sintéticas.

Plataformas de aplicaciones sin servidor

Cloud Run proporciona computación nativa de contenedores, impulsada por solicitudes, con escalado automático a cero y aplicación de identidad por solicitud.

• Servicios y trabajos de Cloud Run

  • Los servicios manejan HTTP; la concurrencia controla el número de solicitudes simultáneas por instancia (ajústala para equilibrar latencia vs. eficiencia). Los trabajos manejan tareas por lotes/cron no HTTP y pueden ser paralelizados.
  • Las revisiones son instantáneas inmutables. La división del tráfico permite implementaciones canary por porcentaje. Establece un mínimo de instancias para reducir los arranques en frío; usa la asignación de CPU durante el tiempo de inactividad si se requiere trabajo en segundo plano.
  • Identidad: asigna una cuenta de servicio dedicada por servicio/revisión con el mínimo privilegio. Restringe la invocación a través de IAM (rol Invocador de Cloud Run) o hazlo público si es necesario. Para la autenticación de usuarios finales, usa tokens firmados de IAP o la autenticación integrada de Cloud Run con Identity Platform.

• Redes

  • Usa conectores de VPC sin servidor para acceder a recursos privados de la VPC. Elige el egreso: todo el tráfico a través del conector, o solo los rangos privados de RFC1918. Ten en cuenta las cuotas de rendimiento del conector; escala el tamaño del conector y alínealo regionalmente con el servicio. Para el tráfico saliente a Internet con recursos que solo tienen IP privada, combínalo con Cloud NAT.
  • Private Service Connect puede consumir servicios de productor de forma privada o exponer puntos de conexión internos. Para la ingesta a través de HTTP(S) externo, usa Cloud Load Balancing con NEGs sin servidor.

App Engine ofrece dos entornos:

• Estándar
  • Aislado (sandboxed), escala rápidamente y admite escalado automático, básico o manual. El escalado automático con min_idle_instances proporciona capacidad precalentada. Arranque en frío rápido y modelo de despliegue simple; personalizaciones limitadas a nivel de SO y un conjunto fijo de entornos de ejecución.
• Flexible
  • Ejecuta Docker en VMs de Compute Engine con más control sobre las bibliotecas del sistema y las redes. Ciclo de vida de la instancia más lento y costo base más alto; adecuado cuando se necesitan entornos de ejecución personalizados o bibliotecas nativas.
• Servicios y versiones
  • Divide el tráfico por versión (aleatorio, por cookie o por IP). Cada servicio puede escalar de forma independiente. Usa despliegues graduales y mantén una versión anterior para una reversión instantánea.

Cloud Functions proporciona funciones de un solo propósito impulsadas por eventos.

• Activadores: Pub/Sub, Cloud Storage, HTTP, Eventarc para muchas fuentes. Haz que los manejadores (handlers) sean idempotentes; algunos activadores reintentan en caso de fallo, lo que lleva a un procesamiento duplicado.
• Configuración del entorno de ejecución: variables de entorno, vinculaciones de Secret Manager, máximo de instancias, memoria/CPU. Controla la concurrencia para las funciones HTTP para equilibrar la latencia y el costo.
• Errores comunes: la concurrencia ilimitada o los efectos secundarios no idempotentes causan duplicación de datos; asegúrate de tener DLQs para Pub/Sub; establece tiempos de espera adecuados.

← Compute Engine y operaciones de máquinas virtuales · Todos los dominios · Redes de VPC →

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

Explorar Google →