Google Cloud Platform: GKE y Más

Arquitectura del Cluster

GKE es el servicio de Kubernetes gestionado de Google. Maneja la gestión del plano de control, upgrades automáticos y auto-reparación de nodos. Dos modos: Standard (gestionas node pools) y Autopilot (Google gestiona todo).

• Plano de control: Gestionado por Google. Plano de control regional para HA (3 masters en zonas). Sin cargo por el plano de control en modo Standard
• Node pools: Grupos de VMs con configuración idéntica. Mezcla tipos de máquina (e2, n2, c2) para balance costo/rendimiento
• Modo Autopilot: Google gestiona nodos, escala por pod. Solo defines resource requests de pods. Ideal para equipos que quieren cero gestión de nodos
• Release channels: Rapid, Regular, Stable. Controla qué tan rápido GKE actualiza tu cluster. Stable es recomendado para producción
• Clusters privados: Los nodos no tienen IPs públicas. Plano de control accesible solo vía endpoint privado o redes autorizadas
• Clusters VPC-native: Usan rangos de IP alias. Requerido para Network Policies, reglas de firewall a nivel pod e IP masquerading

# Create a production-ready GKE cluster
gcloud container clusters create myapp-prod \
  --region us-central1 \
  --release-channel stable \
  --enable-private-nodes \
  --master-ipv4-cidr 172.16.0.0/28 \
  --enable-master-authorized-networks \
  --master-authorized-networks 10.0.0.0/8 \
  --enable-ip-alias \
  --network app-vpc \
  --subnetwork app-subnet \
  --cluster-secondary-range-name pods \
  --services-secondary-range-name services \
  --enable-network-policy \
  --workload-pool=myapp-prod.svc.id.goog \
  --num-nodes 3 \
  --machine-type e2-standard-4 \
  --disk-size 100 \
  --enable-autoscaling \
  --min-nodes 2 \
  --max-nodes 10 \
  --enable-autorepair \
  --enable-autoupgrade

Configuración de Workloads

Los workloads de Kubernetes en GKE requieren planificación cuidadosa de recursos. Pods sub-aprovisionados reciben OOMKilled; pods sobre-aprovisionados desperdician dinero.

• Requests vs limits: Requests garantizan recursos mínimos. Limits limitan uso máximo. Configura requests basados en uso P95, limits en 2x requests
• Horizontal Pod Autoscaler (HPA): Escala pods basado en CPU, memoria o métricas custom. Usa el campo behavior para controlar velocidad de escalado
• Vertical Pod Autoscaler (VPA): Ajusta automáticamente resource requests basado en uso histórico. Ejecuta en modo "Off" primero para obtener recomendaciones
• Pod Disruption Budgets (PDB): Asegura disponibilidad mínima durante disrupciones voluntarias (upgrades, escalado). Configura minAvailable o maxUnavailable
• Topology spread constraints: Distribuye pods entre nodos y zonas para alta disponibilidad
• VMs Preemptible/Spot: 60-91% más baratas que VMs regulares. Usa para cargas stateless con PDB y pod anti-affinity apropiados

# Kubernetes deployment with production-grade configuration
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
  namespace: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: api-service
  template:
    metadata:
      labels:
        app: api-service
    spec:
      serviceAccountName: api-service-sa
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api-service
      containers:
        - name: api
          image: us-central1-docker.pkg.dev/myapp-prod/services/api:v2.1.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
            limits:
              cpu: 500m
              memory: 1Gi
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 20
          env:
            - name: DB_HOST
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: host

Networking e Ingress

• GKE Ingress controller: Aprovisiona Google Cloud Load Balancers automáticamente. Soporta HTTP(S), certificados SSL vía certs gestionados por Google
• Istio / Anthos Service Mesh: mTLS entre servicios, gestión de tráfico (canary, blue-green), circuit breaking, observabilidad
• Network Policies: Firewall nativo de Kubernetes. Restringe comunicación pod-a-pod. Default deny + allow explícito es el enfoque más seguro
• Balanceo de carga interno: Expón servicios internamente vía anotación cloud.google.com/load-balancer-type: Internal
• Cloud NAT: Provee acceso a internet saliente para nodos privados sin asignar IPs públicas

Cloud Run ejecuta contenedores stateless sin gestionar infraestructura. Escala de cero a miles de instancias automáticamente. Solo pagas por tiempo de procesamiento real (facturado por 100ms).

• Contrato del contenedor: Escucha en la variable PORT (default 8080), responde a requests HTTP, stateless (sin persistencia en disco local entre requests)
• Concurrencia: Cada instancia maneja múltiples requests concurrentes (default 80, máx 1000). Ajusta según el perfil de memoria/CPU de tu app
• Cold starts: El primer request a una nueva instancia tiene latencia de arranque. Minimiza manteniendo imágenes pequeñas y usando min-instances > 0
• Asignación de CPU: "CPU siempre asignada" para procesamiento en background, o "CPU solo durante requests" para cargas request-response puras (más barato)
• VPC connector: Accede a recursos privados (Cloud SQL, Memorystore, servicios internos GKE) desde Cloud Run vía Serverless VPC Access
• División de tráfico: Rutea porcentaje de tráfico a nuevas revisiones para deploys canary. Rollback instantáneo redirigiendo 100% de vuelta

# Deploy a Cloud Run service
gcloud run deploy api-service \
  --image us-central1-docker.pkg.dev/myapp-prod/services/api:v2.1.0 \
  --region us-central1 \
  --platform managed \
  --port 3000 \
  --memory 1Gi \
  --cpu 1 \
  --concurrency 80 \
  --min-instances 1 \
  --max-instances 100 \
  --timeout 60 \
  --service-account [email protected] \
  --vpc-connector app-vpc-connector \
  --set-env-vars "NODE_ENV=production" \
  --set-secrets "DB_PASSWORD=db-password:latest"

Ejemplo de Pipeline Cloud Build

# cloudbuild.yaml - Build, test, push, deploy
steps:
  # Run tests
  - name: 'node:20-alpine'
    entrypoint: 'sh'
    args: ['-c', 'npm ci && npm test']

  # Build Docker image with kaniko (layer caching)
  - name: 'gcr.io/kaniko-project/executor:latest'
    args:
      - '--destination=us-central1-docker.pkg.dev/$PROJECT_ID/services/api:$SHORT_SHA'
      - '--cache=true'
      - '--cache-ttl=72h'

  # Deploy to GKE
  - name: 'gcr.io/cloud-builders/gke-deploy'
    args:
      - 'run'
      - '--filename=k8s/'
      - '--image=us-central1-docker.pkg.dev/$PROJECT_ID/services/api:$SHORT_SHA'
      - '--cluster=myapp-prod'
      - '--location=us-central1'

options:
  logging: CLOUD_LOGGING_ONLY
  machineType: 'E2_HIGHCPU_8'

timeout: '900s'

Modelo IAM de GCP

IAM de GCP usa una jerarquía de recursos: Organización > Carpetas > Proyectos > Recursos. Los permisos se heredan hacia abajo. Políticas en niveles superiores aplican a todos los recursos debajo.

• Principales: Cuentas Google, cuentas de servicio, grupos, dominios. Siempre usa grupos para acceso humano
• Roles: Predefinidos (ej: roles/container.developer) o custom. Evita roles primitivos (Owner, Editor, Viewer) -- son demasiado amplios
• Cuentas de servicio: Identidades de máquina. Crea SAs por servicio con permisos mínimos. Nunca uses la SA de compute por defecto
• Condiciones IAM: Otorga permisos solo cuando se cumplen condiciones (basadas en tiempo, atributos de recurso, IP)
• Logs de auditoría: Admin Activity (siempre activo), Data Access (configurar por servicio), System Event. Envía a Cloud Logging

Workload Identity

Workload Identity es la forma recomendada para que los workloads de GKE accedan a APIs de GCP. Vincula cuentas de servicio de Kubernetes con cuentas de servicio de GCP, eliminando la necesidad de claves exportadas.

• Cómo funciona: KSA (Kubernetes Service Account) se anota con una GSA (Google Service Account). Cuando un pod usa la KSA, el servidor de metadatos de GKE provee credenciales de la GSA
• Sin archivos de clave: Elimina el riesgo de filtración de archivos JSON de clave. Las credenciales son de corta duración y se rotan automáticamente
• Identidad por pod: Diferentes pods pueden tener diferentes permisos GCP usando diferentes KSAs
• Acceso cross-project: Una GSA en proyecto A puede vincularse a una KSA en el cluster GKE del proyecto B

# Setup Workload Identity for a service
# 1. Create GCP service account
gcloud iam service-accounts create api-service \
  --display-name="API Service" \
  --project=myapp-prod

# 2. Grant necessary permissions
gcloud projects add-iam-policy-binding myapp-prod \
  --member="serviceAccount:[email protected]" \
  --role="roles/cloudsql.client"

# 3. Bind KSA to GSA
gcloud iam service-accounts add-iam-policy-binding \
  [email protected] \
  --role="roles/iam.workloadIdentityUser" \
  --member="serviceAccount:myapp-prod.svc.id.goog[your-org/api-service-sa]"

# 4. Annotate the Kubernetes service account
kubectl annotate serviceaccount api-service-sa \
  --namespace myapp \
  iam.gke.io/gcp-service-account=api-service@myapp-prod.iam.gserviceaccount.com

Workload Identity Federation

Workload Identity Federation extiende el concepto sin claves más allá de GKE. Cargas externas (GitHub Actions, GitLab CI, AWS, Azure, on-prem) pueden autenticarse en GCP sin claves de cuentas de servicio intercambiando sus tokens de identidad nativos.

• Identity pools: Crea un pool por límite de confianza (ej: uno para GitHub, otro para GitLab). Cada pool contiene proveedores que mapean identidades externas
• Mapeo de atributos: Mapea claims de tokens externos (ej: assertion.repository) a atributos de Google. Usa condiciones de atributos para restringir qué identidades externas pueden autenticarse
• GitHub Actions: Configura proveedor OIDC con token.actions.githubusercontent.com. Restringe a repos y ramas específicas vía condiciones de atributos
• Sin claves de larga duración: Los tokens de federación son de corta duración (1 hora por defecto). Elimina la carga de rotación de claves y el riesgo de filtración por completo
• Impersonación de cuenta de servicio: La identidad externa se autentica vía el pool, luego impersona una cuenta de servicio GCP para acceder recursos. La SA sigue gobernando permisos vía IAM

# Setup Workload Identity Federation for GitHub Actions
# 1. Create the identity pool
gcloud iam workload-identity-pools create github-pool \
  --location="global" \
  --display-name="GitHub Actions Pool"

# 2. Add GitHub as an OIDC provider
gcloud iam workload-identity-pools providers create-oidc github-provider \
  --location="global" \
  --workload-identity-pool=github-pool \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --attribute-condition="assertion.repository=='your-org/api-service'"

# 3. Allow the provider to impersonate the deploy SA
gcloud iam service-accounts add-iam-policy-binding \
  [email protected] \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/123456/locations/global/workloadIdentityPools/github-pool/attribute.repository/your-org/api-service"

Cloud Logging

• Logging estructurado: Escribe JSON a stdout/stderr desde contenedores. GKE envía automáticamente a Cloud Logging. Campos como severity, httpRequest y trace se parsean automáticamente
• Métricas basadas en logs: Crea métricas custom desde patrones de log. Usa para alertas de tasas de error, mensajes específicos o eventos de negocio
• Log sinks: Rutea logs a BigQuery (analytics), Cloud Storage (archivo a largo plazo) o Pub/Sub (procesamiento en tiempo real)
• Filtros de exclusión: Reduce costos de logging excluyendo logs de alto volumen y bajo valor (health checks, logs nivel debug)
• Retención de logs: 30 días por defecto para la mayoría. Usa log buckets para períodos de retención custom (hasta 10 años)

// Structured logging in Node.js for Cloud Logging
const log = (severity, message, extra = {}) => {
  const entry = {
    severity,  // DEBUG, INFO, WARNING, ERROR, CRITICAL
    message,
    timestamp: new Date().toISOString(),
    'logging.googleapis.com/trace': getTraceId(),
    'logging.googleapis.com/spanId': getSpanId(),
    serviceContext: { service: 'api-service', version: '2.1.0' },
    ...extra
  };
  console.log(JSON.stringify(entry));
};

// Usage
log('INFO', 'Booking created', {
  userId: '12345',
  bookingId: 'bk_789',
  httpRequest: { requestMethod: 'POST', requestUrl: '/api/bookings', status: 201 }
});

Cloud Monitoring

• Métricas GKE: Utilización CPU/memoria, reinicios de pods, salud de nodos, errores de contenedor -- todo recolectado automáticamente
• Métricas custom: Envía métricas específicas de la app vía OpenTelemetry o la API de Monitoring. Usa para KPIs de negocio (reservas/minuto, tasa de éxito de pagos)
• Políticas de alerta: Alertas multi-condición con canales de notificación (email, Slack, PagerDuty, webhooks). Usa condiciones de ausencia de métrica para detectar fallos silenciosos
• Uptime checks: Sondas HTTP(S) desde múltiples ubicaciones globales. Alerta ante caídas en 1 minuto
• Dashboards: Dashboards custom con MQL (Monitoring Query Language). Incrusta gráficos de Cloud Logging y Cloud Trace
• SLOs (Service Level Objectives): Define objetivos de disponibilidad y latencia. Alertas de burn rate notifican antes de que se viole el SLO

Cloud Trace

• Tracing distribuido: Rastrea requests a través de microservicios. Ve exactamente dónde ocurre la latencia en una cadena de llamadas multi-servicio
• Instrumentación automática: GKE y Cloud Run generan spans de trace automáticamente para requests entrantes. Agrega OpenTelemetry para spans custom
• Correlación trace-log: Incluye logging.googleapis.com/trace en logs estructurados. Cloud Logging vincula logs a su trace automáticamente
• Análisis de latencia: Cloud Trace genera distribuciones de latencia e identifica regresiones. Configura alertas cuando la latencia P99 supere umbrales
• Sampling: Configura la tasa de muestreo para controlar costos. 1% de muestreo es suficiente para análisis de latencia en producción en servicios de alto tráfico

// OpenTelemetry tracing setup for Node.js on GKE
const { NodeTracerProvider } = require('@opentelemetry/sdk-trace-node');
const { BatchSpanProcessor } = require('@opentelemetry/sdk-trace-base');
const { TraceExporter } = require('@google-cloud/opentelemetry-cloud-trace-exporter');
const { registerInstrumentations } = require('@opentelemetry/instrumentation');
const { HttpInstrumentation } = require('@opentelemetry/instrumentation-http');
const { ExpressInstrumentation } = require('@opentelemetry/instrumentation-express');

const provider = new NodeTracerProvider();
provider.addSpanProcessor(
  new BatchSpanProcessor(new TraceExporter({ projectId: 'myapp-prod' }))
);
provider.register();

registerInstrumentations({
  instrumentations: [new HttpInstrumentation(), new ExpressInstrumentation()]
});

La facturación de GCP es por proyecto. Sin gestión activa, los clusters GKE y discos persistentes son los principales generadores de costo.

• Committed Use Discounts (CUDs): Compromisos de 1 o 3 años para 20-57% de ahorro en compute. CUDs flexibles aplican a través de familias de máquinas
• Spot VMs en node pools: Crea un node pool separado con Spot VMs para cargas no críticas. Usa taints y tolerations para controlar scheduling
• Right-size con VPA: Ejecuta VPA en modo recomendación. Revisa y aplica sugerencias. La mayoría de equipos sobre-aprovisionan en 50%+ en el deploy inicial
• Cluster autoscaler: Escala node pools a cero cuando no se necesitan. Usa ajuste de scale-down-unneeded-time y scale-down-utilization-threshold
• Regional vs zonal: Clusters regionales cuestan 3x en nodos (uno por zona). Usa regional para HA en producción, zonal para dev/staging
• Costos de discos persistentes: Elimina PVCs sin usar. Usa pd-standard para cargas no sensibles a IOPS (pd-ssd cuesta 6x más)
• Costos de logging: Cloud Logging cobra por GB ingerido. Excluye logs verbosos, reduce nivel de log en producción y configura retención apropiada
• Alertas de presupuesto: Configura presupuestos por proyecto con alertas al 50%, 80%, 100%, 150%. Usa notificaciones programáticas para auto-escalar o notificar al equipo

En producción, diseñé y gestioné toda la infraestructura GCP ejecutando 26 microservicios en producción sobre GKE. Decisiones de arquitectura clave y resultados:

• Cluster GKE: Cluster regional en us-central1 con canal Stable. Tres node pools: default (e2-standard-4), high-memory (e2-highmem-4 para servicios data-intensive) y spot (e2-standard-2 para batch jobs). Cluster autoscaler de 2 a 10 nodos por pool
• Cloud Build: Pipeline CI/CD automatizado disparado al mergear a main en GitLab. Build, test, push a Artifact Registry, deploy a GKE con rolling updates. Tiempo promedio de build: 3 minutos con caché de layers kaniko
• Workload Identity: Cada microservicio tiene su propio binding KSA-GSA. El servicio API accede Cloud SQL, el de notificaciones accede Pub/Sub, el de exportación accede Cloud Storage -- todo sin archivos de clave
• Observabilidad: Logging JSON estructurado desde todos los servicios Node.js. Dashboards custom para tasas de reservas, éxito de pagos y latencia API P95. Integración PagerDuty para alertas críticas
• Optimización de costos: Spot VMs para namespace de desarrollo, CUDs para baseline de producción, recomendaciones VPA aplicadas trimestralmente. Reducción de costos de compute GKE en ~40% vs pricing on-demand inicial

Cloud SQL es un servicio de base de datos relacional completamente gestionado que soporta MySQL, PostgreSQL y SQL Server. Maneja replicación, backups, encriptación y parches.

• Tiers de instancia: Shared-core (db-f1-micro, db-g1-small) para dev, dedicados (db-custom-*) para producción. Siempre usa instancias dedicadas en producción para rendimiento consistente
• Alta disponibilidad: HA regional con failover automático. Primario y standby en diferentes zonas. El failover toma 30-120 segundos. Habilita para todas las bases de datos de producción
• Read replicas: Descarga tráfico de lectura a réplicas cross-zone o cross-region. Útil para queries de analítica que no deben impactar las escrituras de producción
• Cloud SQL Auth Proxy: Método de conexión seguro usando autenticación basada en IAM. Corre como sidecar en pods GKE. Elimina la necesidad de gestionar certificados SSL o allowlist de IPs
• Backups automatizados: Backups diarios con retención configurable (hasta 365 días). Recuperación point-in-time (PITR) usando write-ahead logs para cualquier momento dentro de la ventana de retención
• Límites de conexión: Cada instancia tiene un límite máximo de conexiones según el tier. Usa connection pooling (PgBouncer, ProxySQL) para evitar agotamiento bajo alta concurrencia
• IP privada: Despliega Cloud SQL solo con IP privada. Acceso desde GKE vía private services access. Sin endpoint público reduce la superficie de ataque

# Create a production Cloud SQL PostgreSQL instance
gcloud sql instances create app-db \
  --database-version=POSTGRES_15 \
  --tier=db-custom-4-16384 \
  --region=us-central1 \
  --availability-type=REGIONAL \
  --storage-type=SSD \
  --storage-size=100GB \
  --storage-auto-increase \
  --backup-start-time=03:00 \
  --enable-point-in-time-recovery \
  --retained-backups-count=30 \
  --network=projects/myapp-prod/global/networks/app-vpc \
  --no-assign-ip \
  --database-flags=log_min_duration_statement=1000,max_connections=200

# Deploy Cloud SQL Auth Proxy as a sidecar in GKE
# (add to pod spec alongside your app container)
# - name: cloud-sql-proxy
#   image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2
#   args: ["--structured-logs", "myapp-prod:us-central1:app-db"]
#   securityContext:
#     runAsNonRoot: true

Cloud Storage es el servicio de almacenamiento de objetos de GCP. Almacena cualquier cantidad de datos no estructurados con alta durabilidad (99.999999999% -- once nueves). Cuatro clases de almacenamiento balancean costo y patrones de acceso.

• Clases de almacenamiento: Standard (acceso frecuente), Nearline (una vez/mes), Coldline (una vez/trimestre), Archive (una vez/año). Reglas de lifecycle auto-transicionan objetos entre clases
• Acceso uniforme a nivel bucket: Deshabilita ACLs por objeto y usa solo IAM para control de acceso. Más simple, auditable y recomendado para todos los buckets nuevos
• Signed URLs: Genera URLs con tiempo limitado que otorgan acceso temporal a objetos privados. Usa para descargas de archivos sin exponer permisos del bucket
• Versionado de objetos: Retén versiones anteriores de objetos sobrescritos o eliminados. Esencial para protección de datos. Combina con reglas de lifecycle para eliminar versiones viejas después de N días
• Notificaciones Pub/Sub: Dispara eventos al crear, eliminar o actualizar metadatos de objetos. Impulsa pipelines serverless (Cloud Functions, Cloud Run) desde eventos de storage
• Transfer Service: Migra datos desde AWS S3, Azure Blob, fuentes HTTP u on-prem a Cloud Storage. Programa transferencias recurrentes para sincronización de datos

# Create a Cloud Storage bucket with lifecycle rules
gcloud storage buckets create gs://myapp-prod-uploads \
  --location=us-central1 \
  --uniform-bucket-level-access \
  --public-access-prevention

# Set lifecycle rule: transition to Nearline after 30 days, delete after 365
cat <<'EOF' > lifecycle.json
{
  "rule": [
    {"action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
     "condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}},
    {"action": {"type": "Delete"},
     "condition": {"age": 365}}
  ]
}
EOF
gcloud storage buckets update gs://myapp-prod-uploads \
  --lifecycle-file=lifecycle.json

Cloud Pub/Sub es un servicio de mensajería en tiempo real completamente gestionado para arquitecturas event-driven. Desacopla productores de consumidores y garantiza entrega at-least-once a cualquier escala.

• Topics y subscriptions: Los publishers envían mensajes a topics. Los subscribers consumen vía pull (basado en polling) o push (endpoint HTTP). Un topic puede tener muchas subscriptions
• Orden de mensajes: Habilita ordering keys para garantizar entrega en orden para mensajes con la misma clave. Requerido para event sourcing y procesamiento stateful
• Dead letter topics: Rutea automáticamente mensajes que fallan procesamiento después de N intentos a un dead letter topic para investigación. Previene que mensajes envenenados bloqueen la cola
• Entrega exactly-once: Disponible con pull subscriptions usando IDs de acknowledgment. Los subscribers deben manejar deduplicación para push subscriptions
• Retención de mensajes: Retén mensajes acknowledged hasta 31 días. Reproduce mensajes viejos buscando por timestamp -- útil para reprocesar después de deployar un fix
• Validación de schema: Aplica schemas Avro, Protocol Buffer o JSON en mensajes. Rechaza mensajes inválidos al publicar para prevenir fallas downstream

# Create a Pub/Sub topic and subscription with dead lettering
gcloud pubsub topics create booking-events

gcloud pubsub topics create booking-events-dlq

gcloud pubsub subscriptions create booking-processor \
  --topic=booking-events \
  --ack-deadline=60 \
  --message-retention-duration=7d \
  --dead-letter-topic=booking-events-dlq \
  --max-delivery-attempts=5 \
  --enable-exactly-once-delivery

# Push subscription to Cloud Run
gcloud pubsub subscriptions create booking-push \
  --topic=booking-events \
  --push-endpoint=https://booking-worker-xxxxx.run.app/pubsub \
  --push-auth-service-account=pubsub-invoker@myapp-prod.iam.gserviceaccount.com

VPC (Virtual Private Cloud) es la base de networking en GCP. Cada cluster GKE, instancia Cloud SQL y caché Memorystore corre dentro de una VPC. El diseño apropiado de red es crítico para seguridad y rendimiento.

• Subnets: Recursos regionales. Planifica rangos CIDR cuidadosamente -- GKE necesita rangos secundarios para pods y services. Un /20 para pods y /24 para services soporta la mayoría de clusters
• Reglas de firewall: Stateful, ordenadas por prioridad. Default deny ingress, allow egress. Usa tags o cuentas de servicio como targets para reglas granulares
• Shared VPC: El proyecto host es dueño de la red, proyectos de servicio despliegan recursos en ella. Centraliza gestión de red para organizaciones multi-equipo
• VPC peering: Conecta VPCs entre proyectos u organizaciones. No transitivo (A peered a B, B peered a C, A no puede alcanzar C). Usa para acceso cross-project a bases de datos
• Private Google Access: Permite que VMs sin IPs externas alcancen APIs de Google (Cloud Storage, BigQuery, Artifact Registry). Debe habilitarse por subnet
• VPC Flow Logs: Captura datos de flujo de red para análisis de seguridad y troubleshooting. Habilita a nivel de subnet con tasa de muestreo configurable
• Cloud Armor: Firewall de aplicación web y protección DDoS. Adjunta políticas de seguridad a load balancers HTTP(S). Bloquea por IP, geografía o reglas WAF custom (OWASP Top 10)

# Create a VPC with custom subnets for GKE
gcloud compute networks create app-vpc --subnet-mode=custom

gcloud compute networks subnets create app-subnet \
  --network=app-vpc \
  --region=us-central1 \
  --range=10.0.0.0/24 \
  --secondary-range pods=10.4.0.0/14,services=10.8.0.0/20 \
  --enable-private-ip-google-access \
  --enable-flow-logs

# Firewall: allow internal communication, deny all external
gcloud compute firewall-rules create allow-internal \
  --network=app-vpc \
  --allow=tcp,udp,icmp \
  --source-ranges=10.0.0.0/8 \
  --priority=1000

gcloud compute firewall-rules create allow-health-checks \
  --network=app-vpc \
  --allow=tcp:80,tcp:443,tcp:3000 \
  --source-ranges=130.211.0.0/22,35.191.0.0/16 \
  --target-tags=gke-node \
  --priority=1000

gcloud compute firewall-rules create deny-all-ingress \
  --network=app-vpc \
  --action=DENY \
  --rules=all \
  --source-ranges=0.0.0.0/0 \
  --priority=65534

Cloud CDN cachea contenido HTTP(S) en las ubicaciones edge globales de Google (más de 150 puntos de presencia). Se integra con HTTP(S) Load Balancing y soporta GKE, Cloud Run, Cloud Storage y backends externos.

• Modos de caché: USE_ORIGIN_HEADERS (respetar Cache-Control), CACHE_ALL_STATIC (cachear tipos estáticos comunes automáticamente) o FORCE_CACHE_ALL (cachear todo). Usa USE_ORIGIN_HEADERS para respuestas API, CACHE_ALL_STATIC para assets
• Cache keys: Por defecto incluye la URI completa. Personaliza para incluir/excluir parámetros de query, headers o cookies. Mejora tasas de hit para APIs con parámetros no significativos
• Signed URLs y cookies: Restringir acceso CDN a usuarios autorizados. Tokens con tiempo limitado para entrega de contenido premium o distribución de assets privados
• Invalidación de caché: Purga contenido cacheado por ruta URL o tag. Toma efecto globalmente en segundos. Usa con moderación -- diseña cache keys y TTLs para evitar invalidación frecuente
• Compresión: Sirve automáticamente respuestas comprimidas Brotli o gzip cuando el cliente lo soporta. Reduce costos de ancho de banda y mejora tiempos de carga

# Enable Cloud CDN on an existing backend service
gcloud compute backend-services update app-api-backend \
  --enable-cdn \
  --cache-mode=USE_ORIGIN_HEADERS \
  --default-ttl=3600 \
  --max-ttl=86400 \
  --global

# For static assets bucket backend
gcloud compute backend-buckets update app-static-backend \
  --enable-cdn \
  --cache-mode=CACHE_ALL_STATIC \
  --default-ttl=86400

# Invalidate cache
gcloud compute url-maps invalidate-cdn-cache app-lb \
  --path="/api/v2/config/*" --global

Secret Manager almacena claves API, contraseñas, certificados y otros datos sensibles. Provee versionado, rotación automática, control de acceso basado en IAM y logging de auditoría para cada acceso a secretos.

• Versiones de secretos: Cada secreto tiene versiones numeradas. Accede a la última o a una versión específica. Versiones viejas pueden deshabilitarse o destruirse (irreversible)
• Control de acceso IAM: Otorga roles/secretmanager.secretAccessor a cuentas de servicio específicas. Audita cada acceso vía Cloud Audit Logs
• Rotación automática: Configura schedules de rotación con notificaciones Pub/Sub. Dispara una Cloud Function para generar y almacenar nuevas credenciales
• Integración GKE: Monta secretos como volúmenes o variables de entorno usando el add-on de Secret Manager de GKE (SecretProviderClass). Evita sincronizar a Kubernetes Secrets
• Integración Cloud Run: Referencia secretos directamente vía el flag --set-secrets. Cloud Run los inyecta como variables de entorno al iniciar
• Replicación: Automática (Google gestiona) o gestionada por usuario (especificar regiones). Gestionada por usuario para requisitos de compliance que restringen datos a ciertas regiones

# Create and manage secrets
gcloud secrets create db-password \
  --replication-policy="user-managed" \
  --locations="us-central1,us-east1"

# Add a secret version
echo -n "s3cur3P@ssw0rd" | gcloud secrets versions add db-password --data-file=-

# Grant access to a GKE workload's service account
gcloud secrets add-iam-policy-binding db-password \
  --member="serviceAccount:[email protected]" \
  --role="roles/secretmanager.secretAccessor"

# Access from GKE using SecretProviderClass (CSI driver)
# apiVersion: secrets-store.csi.x-k8s.io/v1
# kind: SecretProviderClass
# metadata:
#   name: app-secrets
# spec:
#   provider: gcp
#   parameters:
#     secrets: |
#       - resourceName: "projects/myapp-prod/secrets/db-password/versions/latest"
#         path: "db-password"

Vertex AI es la plataforma unificada de Google Cloud para construir, desplegar y escalar modelos de machine learning y aplicaciones de AI generativa. Combina Model Garden (200+ modelos incluyendo Gemini de Google, modelos partners como Claude de Anthropic y modelos abiertos), herramientas MLOps y controles enterprise en un solo servicio gestionado.

• Modelos Claude en Vertex AI: Model Garden ofrece la línea de Anthropic -- Claude Fable 5 (el modelo más capaz de Anthropic, para el razonamiento más difícil y el trabajo agéntico de largo horizonte), Claude Opus 5 (el buque insignia del día a día), Claude Sonnet 5 (el mejor balance de velocidad e inteligencia), más generaciones anteriores como Opus 4.7, Opus 4.6, Sonnet 4.6 y Haiku 4.5. Consulta Model Garden para la disponibilidad actual por región. Dos tipos de endpoints: Global (ruteo dinámico para latencia óptima) y Regional (ruteo de datos garantizado a través de regiones geográficas específicas)
• Model Garden: Catálogo curado de 200+ modelos -- first-party de Google (Gemini, Imagen, Chirp, Veo), third-party (Claude, Llama) y modelos abiertos (Gemma, Mistral). Integrado con infraestructura de tuning, evaluación y serving de modelos
• Vertex AI Agents: Construye agentes AI con uso de herramientas integrado, grounding y capacidades RAG. Los agentes se conectan a Google Search, fuentes de datos enterprise y APIs custom. La orquestación la maneja la plataforma
• Pipeline MLOps: Vertex AI Pipelines para orquestar workflows ML, Feature Store para servir features ML reutilizables, Model Registry para versionado y Model Monitoring para detectar training-serving skew y drift de inferencia en producción
• Seguridad y compliance: Control de acceso basado en IAM, VPC Service Controls para enforcement de perímetro de datos, Customer-Managed Encryption Keys (CMEK) y Cloud Audit Logs para cada llamada API. Los datos quedan dentro de tu proyecto GCP
• Integración con Claude Code: Configura Claude Code para usar Vertex AI como proveedor con claude config set provider vertex. El tráfico se rutea a través de tu proyecto GCP con integración completa en seguridad, monitoreo y facturación de GCP