Capítulo 9 - Infraestructura Cloud y Orquestación con Kubernetes

El sistema se desplegará en Kubernetes con 3 ambientes separados para garantizar aislamiento y permitir testing exhaustivo antes de llegar a producción.

Ambiente	Nodos	Pods por Servicio	CPU/RAM por Pod	Propósito
Producción	2 nodos	3 réplicas	2 CPU / 4GB RAM	Usuarios finales, 99.9% uptime
Pre-Producción	2 nodos	2 réplicas	1 CPU / 2GB RAM	Testing final, staging, validación
Desarrollo	1 nodo	2 pods (Dev + QA)	0.5 CPU / 1GB RAM	Desarrollo activo, testing de features

Justificación de la Estrategia

Producción (2 nodos): Alta disponibilidad con anti-affinity rules. Si un nodo cae, el otro maneja el tráfico.
Pre-Producción (2 nodos): Replica producción para testing realista de performance y escalado.
Desarrollo (1 nodo fraccionado): Ahorro de costos dividiendo recursos entre Dev y QA en el mismo nodo.

Arquitectura Completa de Kubernetes

graph TB
    Cloud["CLOUD PROVIDER
(AWS EKS / Azure AKS / GCP GKE)"]
    
    subgraph NodeProd1["NODO PROD 1
(Zona AZ-A)"]
        MSH1["MS-Histórico
(Replica 1)"]
        MSP1["MS-Pagos
(Replica 1)"]
        MSA1["MS-Auth
(Replica 1)"]
        HPA1["HPA: Enabled
Anti-affinity"]
    end
    
    subgraph NodeProd2["NODO PROD 2
(Zona AZ-B)"]
        MSH2["MS-Histórico
(Replica 2)"]
        MSP2["MS-Pagos
(Replica 2)"]
        MSA2["MS-Auth
(Replica 2)"]
        HPA2["HPA: Enabled
Anti-affinity"]
    end
    
    subgraph NodePreProd["NODO PRE-PROD 1
(Zona AZ-A)"]
        MSHPP["MS-Histórico
(Replica 1)"]
        MSPPP["MS-Pagos
(Replica 1)"]
        MSAPP["MS-Auth
(Replica 1)"]
        HPAPP["HPA: Enabled"]
    end
    
    LB["LOAD BALANCER
(Ingress Controller)
- NGINX / Traefik
- SSL Termination
- Rate Limiting"]
    
    Internet["INTERNET
(Usuarios)"]
    
    Cloud --> NodeProd1
    Cloud --> NodeProd2
    Cloud --> NodePreProd
    
    NodeProd1 --> LB
    NodeProd2 --> LB
    NodePreProd --> LB
    
    LB --> Internet
    
    style Cloud fill:#E3F2FD,stroke:#2196F3,stroke-width:3px,rx:15,ry:15
    style NodeProd1 fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    style NodeProd2 fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    style NodePreProd fill:#FFF9C4,stroke:#FBC02D,stroke-width:3px,rx:15,ry:15
    style LB fill:#FFE5E5,stroke:#E74C3C,stroke-width:3px,rx:15,ry:15
    style Internet fill:#F3E5F5,stroke:#9C27B0,stroke-width:3px,rx:15,ry:15

9.3.1 Horizontal Pod Autoscaler (HPA)

Kubernetes escala pods automáticamente basado en métricas de uso:

Métrica	Umbral Scale-Up	Umbral Scale-Down	Acción
CPU > 70%	5 min consecutivos	CPU < 30% por 10 min	Crear nuevo pod
Memoria > 80%	3 min consecutivos	Memoria < 40% por 10 min	Crear nuevo pod
Request Rate	> 1000 req/s por pod	< 200 req/s por pod	Ajustar réplicas

Límites de Escalado

flowchart TB
    Config["Configuración por Servicio"]
    
    subgraph Limits["Límites de Escalado"]
        MinRep["Min Replicas: 2
(alta disponibilidad)"]
        MaxRep["Max Replicas: 10
(control de costos)"]
        Cooldown["Cool-down: 5 minutos
(evitar flapping)"]
        ScaleUp["Scale-up velocity:
2 pods cada 30 segundos"]
        ScaleDown["Scale-down velocity:
1 pod cada 5 minutos"]
    end
    
    subgraph Examples["Ejemplos de Escalado"]
        Normal["Carga Normal (100 req/s)
[Pod1] [Pod2]"]
        High["Carga Alta (500 req/s)
[Pod1] [Pod2] [Pod3]"]
        Peak["Pico (1500 req/s)
[Pod1] [Pod2] [Pod3]
[Pod4] [Pod5]"]
        Return["De vuelta a normal
[Pod1] [Pod2]
(scale-down gradual)"]
    end
    
    Config --> Limits
    Limits --> Examples
    
    Normal --> High
    High --> Peak
    Peak --> Return
    
    style Config fill:#E3F2FD,stroke:#2196F3,stroke-width:3px,rx:15,ry:15
    style Limits fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    style Examples fill:#FFF9C4,stroke:#FBC02D,stroke-width:3px,rx:15,ry:15
    style Normal fill:#F3E5F5,stroke:#9C27B0,stroke-width:2px,rx:10,ry:10
    style High fill:#FFE5E5,stroke:#E74C3C,stroke-width:2px,rx:10,ry:10
    style Peak fill:#FFEBEE,stroke:#C62828,stroke-width:2px,rx:10,ry:10
    style Return fill:#E8F5E9,stroke:#4CAF50,stroke-width:2px,rx:10,ry:10

9.3.2 Vertical Pod Autoscaler (VPA)

Ajusta automáticamente los recursos (CPU/RAM) asignados a cada pod según uso histórico:

Aspecto	Comportamiento
Análisis	Últimos 7 días de consumo de recursos
Recomendaciones	Ajusta requests y limits automáticamente
Aplicación	En ventanas de mantenimiento (bajo tráfico)
Modo	Recommendation (sugiere) o Auto (aplica automáticamente)

Beneficios del Autoescalado

Reducción de Costos: Solo se pagan recursos cuando se necesitan (40-60% ahorro vs aprovisionamiento estático)
Alta Disponibilidad: Escala automáticamente ante picos de tráfico (fin de mes, promociones)
Eficiencia Operativa: Sin intervención manual
Resiliencia: Maneja picos inesperados sin degradación

9.4.1 Algoritmo Recomendado: Least Connections

¿Por qué Least Connections?

Las transacciones bancarias tienen duración variable:

Consultas simples: 50-100ms
Transferencias: 500-2000ms
Reportes: 2000-5000ms

Least Connections distribuye mejor la carga real versus Round Robin, previniendo sobrecarga de pods individuales.

Algoritmo	Caso de Uso	Pros	Cons
Least Connections	Default para todos los servicios	Balanceo óptimo con requests de duración variable	Overhead mínimo para tracking
IP Hash	Sesiones pegajosas (si necesario)	Mantiene usuario en mismo pod	Puede causar desbalanceo
Weighted Round Robin	Canary deployments	Control fino para introducir nuevas versiones	Requiere configuración manual

9.5.1 Health Checks en Kubernetes

Tipo de Probe	Pregunta	Configuración	Acción al Fallar
Liveness Probe	¿El contenedor está vivo?	HTTP GET /health cada 10s Timeout: 3s Failure threshold: 3	Reiniciar pod
Readiness Probe	¿El contenedor está listo para tráfico?	HTTP GET /ready cada 5s Timeout: 2s Success threshold: 1	Remover del balanceador
Startup Probe	¿La aplicación terminó de iniciar?	HTTP GET /startup cada 5s Failure threshold: 30 (2.5 min)	Reiniciar pod si falla

9.5.2 Implementación con ELK Stack

Pipeline de Logs y Monitoreo

flowchart TD
    subgraph K8sCluster["KUBERNETES CLUSTER"]
        Pod1["Pod
Filebeat"]
        Pod2["Pod
Filebeat"]
        Pod3["Pod
Filebeat"]
    end
    
    Logstash["LOGSTASH
(Log Processing)

• Parse
• Filter
• Enrich"]
    
    Elasticsearch["ELASTICSEARCH
(Log Storage)

• Índices por fecha
• Retención config"]
    
    Kibana["KIBANA
(Visualization)

• Dashboards
• Alertas"]
    
    Pod1 --> Logstash
    Pod2 --> Logstash
    Pod3 --> Logstash
    
    Logstash --> Elasticsearch
    Elasticsearch --> Kibana
    
    style K8sCluster fill:#E3F2FD,stroke:#2196F3,stroke-width:3px,rx:15,ry:15
    style Logstash fill:#FFF9C4,stroke:#FBC02D,stroke-width:3px,rx:15,ry:15
    style Elasticsearch fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    style Kibana fill:#FFE5E5,stroke:#E74C3C,stroke-width:3px,rx:15,ry:15

9.5.3 Métricas con Prometheus + Grafana

Stack de Métricas

flowchart TD
    subgraph Prometheus["PROMETHEUS
(Metrics Collection)"]
        direction TB
        Scrape["Scrape targets cada 15s:
• /metrics endpoint
• Node exporter
• kube-state-metrics"]
        Retention["Retención: 30 días"]
    end
    
    Grafana["GRAFANA
(Visualización)

• Dashboards
• Alertas
• Query PromQL"]
    
    Prometheus --> Grafana
    
    style Prometheus fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    style Grafana fill:#E3F2FD,stroke:#2196F3,stroke-width:3px,rx:15,ry:15

Para desarrollo local y testing, se configuran múltiples archivos docker-compose agrupados por funcionalidad:

9.6.1 Estructura de Archivos

Organización de Docker Compose

graph TB
    Root[docker/]
    
    Core[docker-compose.core.yml
Servicios core]
    DB[docker-compose.databases.yml
PostgreSQL, MongoDB, Redis]
    Msg[docker-compose.messaging.yml
Kafka, ZooKeeper]
    Obs[docker-compose.observability.yml
ELK, Prometheus, Grafana]
    Dev[docker-compose.dev.yml
Override para desarrollo]
    Test[docker-compose.test.yml
Override para testing]
    
    Command["Comando de inicio completo:

docker-compose \
-f docker-compose.core.yml \
-f docker-compose.databases.yml \
-f docker-compose.messaging.yml \
-f docker-compose.observability.yml \
-f docker-compose.dev.yml \
up -d"]
    
    Root --> Core
    Root --> DB
    Root --> Msg
    Root --> Obs
    Root --> Dev
    Root --> Test
    
    Core --> Command
    DB --> Command
    Msg --> Command
    Obs --> Command
    Dev --> Command
    
    style Root fill:#E3F2FD,stroke:#2196F3,stroke-width:3px,rx:15,ry:15
    style Core fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    style DB fill:#FFF9C4,stroke:#FBC02D,stroke-width:3px,rx:15,ry:15
    style Msg fill:#FFE5E5,stroke:#E74C3C,stroke-width:3px,rx:15,ry:15
    style Obs fill:#F3E5F5,stroke:#9C27B0,stroke-width:3px,rx:15,ry:15
    style Dev fill:#E0F2F1,stroke:#00897B,stroke-width:3px,rx:15,ry:15
    style Test fill:#FFF3E0,stroke:#F57C00,stroke-width:3px,rx:15,ry:15
    style Command fill:#FCE4EC,stroke:#C2185B,stroke-width:3px,rx:15,ry:15

9.6.2 Beneficios de la Modularización

Flexibilidad: Levantar solo servicios necesarios para testing específico
Mantenibilidad: Archivos pequeños y enfocados
Reutilización: Mismos archivos para dev, test y CI
Isolation: Servicios agrupados lógicamente

9.7.1 Configuración de Cluster

Componente	Configuración	Justificación
Kafka Brokers	3 nodos	Alta disponibilidad y particionamiento
ZooKeeper Nodes	3 nodos (impar para quorum)	Coordinación y failover automático
Replication Factor	3 para cada topic	Tolerancia a fallo de 2 brokers
Min In-Sync Replicas	2	Garantiza durabilidad sin sacrificar performance

9.7.2 Topics Principales

Topic	Particiones	Retención	Uso
transactions.created	10	30 días	Nuevas transacciones bancarias
audit.events	5	7 años	Eventos de auditoría (compliance)
notifications.queue	5	7 días	Notificaciones pendientes de envío
data.sync	3	1 día	Sincronización CQRS entre bases de datos
saga.orchestration	5	3 días	Coordinación de transacciones distribuidas

Justificación de Kafka

Throughput: 1M+ mensajes/segundo por nodo
Durabilidad: Réplicas + persistencia en disco
Escalabilidad: Particionamiento horizontal
Orden garantizado: Por partition key
Replay capability: Re-procesar eventos históricos

La arquitectura es agnóstica al proveedor cloud. Puede implementarse en cualquiera de las siguientes opciones:

Proveedor	Servicio K8s	Pros	Cons	Costo Estimado
AWS	EKS (Elastic Kubernetes Service)	Más maduro y estable Amplia documentación Integración con servicios AWS	Curva de aprendizaje Costos pueden escalar	~$2,700/mes
Azure	AKS (Azure Kubernetes Service)	Control plane gratis Integración con Azure AD Buen soporte	Menos maduro que EKS Documentación menor	~$2,400/mes
GCP	GKE (Google Kubernetes Engine)	Autopilot mode (managed) Integración nativa con Kubernetes Networking avanzado	Menor adopción en LATAM Soporte limitado local	~$2,500/mes
OpenShift	OpenShift (Red Hat)	Kubernetes enterprise Seguridad robusta Soporte Red Hat	Más costoso Más complejo	~$3,500/mes

Recomendación: AWS EKS por madurez, ecosistema y disponibilidad en LATAM. Alternativa viable: Azure AKS por costo/beneficio.

9.9.1 Organización por Namespaces

Estructura de Namespaces

             flowchart TD
    classDef cluster fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,stroke-dasharray:5 5,rx:10,ry:10
    classDef namespace fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,rx:8,ry:8
    classDef production fill:#e8f5e8,stroke:#2e7d32,stroke-width:1.5px,rx:6,ry:6
    classDef preprod fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px,rx:6,ry:6
    classDef dev fill:#fce4ec,stroke:#c2185b,stroke-width:1.5px,rx:6,ry:6
    classDef qa fill:#fff8e1,stroke:#ff8f00,stroke-width:1.5px,rx:6,ry:6
    classDef monitoring fill:#e8eaf6,stroke:#283593,stroke-width:1.5px,rx:6,ry:6
    classDef system fill:#f5f5f5,stroke:#424242,stroke-width:1.5px,rx:6,ry:6

    KUBERNETES_CLUSTER[KUBERNETES CLUSTER]:::cluster

    subgraph KUBERNETES_CLUSTER
        NS1[Namespace: production]:::namespace
        NS2[Namespace: pre-production]:::namespace
        NS3[Namespace: development]:::namespace
        NS4[Namespace: qa]:::namespace
        NS5[Namespace: monitoring]:::namespace
        NS6[Namespace: kube-system]:::namespace
    end

    %% Contenido de cada namespace apilado verticalmente
    NS1 --> MSH1[MS-Históricos
3 réplicas]:::production
    NS1 --> MSP1[MS-Pagos
3 réplicas]:::production
    NS1 --> MSA1[MS-Autenticación
3 réplicas]:::production
    NS1 --> MSAU1[MS-Auditoría
2 réplicas]:::production
    NS1 --> APIG1[API-Gateway
3 réplicas]:::production

    NS2 --> MSH2[MS-Históricos
2 réplicas]:::preprod
    NS2 --> MSP2[MS-Pagos
2 réplicas]:::preprod
    NS2 --> MSA2[MS-Autenticación
2 réplicas]:::preprod
    NS2 --> APIG2[API-Gateway
2 réplicas]:::preprod

    NS3 --> MSH3[MS-Históricos
1 réplica]:::dev
    NS3 --> MSP3[MS-Pagos
1 réplica]:::dev
    NS3 --> MSA3[MS-Autenticación
1 réplica]:::dev

    NS4 --> MSH4[MS-Históricos
1 réplica]:::qa
    NS4 --> MSP4[MS-Pagos
1 réplica]:::qa

    NS5 --> PROM[Prometheus]:::monitoring
    NS5 --> GRAF[Grafana]:::monitoring
    NS5 --> ES[Elasticsearch]:::monitoring
    NS5 --> KIB[Kibana]:::monitoring

    NS6 --> DNS[kube-dns]:::system
    NS6 --> METRICS[metrics-server]:::system
    NS6 --> INGRESS[ingress-nginx]:::system

    %% Conexiones entre namespaces
    NS1 --> NS2
    NS2 --> NS3
    NS3 --> NS4
    NS4 --> NS5
    NS5 --> NS6

9.9.2 Beneficios de Namespaces

Aislamiento: Recursos de un ambiente no afectan otros
RBAC Granular: Permisos específicos por namespace
Resource Quotas: Límites de CPU/RAM por namespace
Network Policies: Control de tráfico entre namespaces
Organización: Separación lógica clara de ambientes

9.10.1 Resource Requests y Limits por Microservicio

Microservicio	CPU Request	CPU Limit	Memory Request	Memory Limit
MS-Históricos	0.5 cores	2 cores	1 GB	4 GB
MS-Pagos	1 core	2 cores	2 GB	4 GB
MS-Autenticación	0.5 cores	1.5 cores	1 GB	3 GB
MS-Notificaciones	0.5 cores	2 cores	1 GB	3 GB
MS-Auditoría	0.5 cores	1.5 cores	1 GB	3 GB
API-Gateway	1 core	2 cores	2 GB	4 GB

Diferencia entre Request y Limit:

Request: Recursos garantizados que el pod siempre tendrá disponibles
Limit: Máximo de recursos que el pod puede usar (burst capacity)

9.10.2 Namespace Resource Quotas

Namespace	CPU Total	Memory Total	Pods Máximos
production	30 cores	60 GB	100
pre-production	15 cores	30 GB	50
development	8 cores	16 GB	30
qa	8 cores	16 GB	30

9.11.1 Segmentación de Red (Zero Trust)

Implementación de políticas de red para restringir comunicación entre pods:

Reglas de Network Policies

flowchart TB
    Default["Política por Defecto
DENY ALL
Solo comunicaciones explícitas"]
    
    subgraph Allowed["Reglas Permitidas ✓"]
        A1["Internet → API-Gateway
(puerto 443)"]
        A2["API-Gateway → Microservicios"]
        A3["Microservicios → PostgreSQL
(puerto 5432)"]
        A4["Microservicios → Redis
(puerto 6379)"]
        A5["Microservicios → Kafka
(puerto 9092)"]
        A6["Todos → Elasticsearch
(puerto 9200)"]
        A7["Monitoring namespace → Todos
(scraping)"]
    end
    
    subgraph Denied["Reglas Denegadas ✗"]
        D1["Microservicios NO pueden
llamarse directamente
(deben pasar por Gateway)"]
        D2["Internet NO puede acceder
directamente a microservicios
(solo vía Gateway)"]
        D3["Namespace development
NO puede acceder a
recursos de production"]
    end
    
    Default --> Allowed
    Default --> Denied
    
    style Default fill:#FFE5E5,stroke:#E74C3C,stroke-width:3px,rx:15,ry:15
    style Allowed fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:15,ry:15
    style Denied fill:#FFEBEE,stroke:#C62828,stroke-width:3px,rx:15,ry:15

9.11.2 Beneficios de Network Policies

Seguridad en profundidad: Limita blast radius de un compromiso
Compliance: Demuestra segmentación de red para auditorías
Zero Trust: Ninguna comunicación es confiable por defecto
Visibilidad: Políticas explícitas documentan arquitectura

9.12.1 NGINX Ingress Controller

¿Por qué NGINX Ingress?

Madurez: Estable y ampliamente adoptado
Performance: Maneja 50K+ requests/segundo
Features: SSL termination, rate limiting, redirects, rewrite rules
Integración: Cert-manager para SSL automático con Let's Encrypt

9.12.2 Configuración de SSL/TLS

Aspecto	Configuración
Protocolo	TLS 1.3 (fallback a TLS 1.2)
Certificados	Let's Encrypt (renovación automática cada 60 días)
Cipher Suites	Solo strong ciphers (AES-256-GCM, ChaCha20)
HSTS	Enabled (max-age=31536000)
Certificate Pinning	Configurado en apps móviles

9.12.3 Rate Limiting en Ingress

Endpoint	Rate Limit	Burst
/api/v1/login	5 req/min por IP	10
/api/v1/register	3 req/hora por IP	5
/graphql	100 req/min por usuario	150
Global	1000 req/min por IP	1500

9.13.1 Storage Classes

Storage Class	Tipo	Performance	Uso
ssd-fast	SSD (gp3 en AWS)	Alta (3000 IOPS)	Bases de datos transaccionales
ssd-standard	SSD (gp2 en AWS)	Media (baseline IOPS)	Redis, aplicaciones generales
hdd-bulk	HDD (st1 en AWS)	Baja (throughput optimized)	Logs, backups, archivos

9.13.2 Persistent Volume Claims

Componente	Storage Class	Tamaño	ReclaimPolicy
PostgreSQL Primary	ssd-fast	500 GB	Retain (manual deletion)
PostgreSQL Replicas	ssd-fast	500 GB	Retain
Redis	ssd-standard	100 GB	Delete
Kafka	ssd-standard	1 TB	Retain
Elasticsearch	ssd-standard	2 TB	Retain

9.14.1 HashiCorp Vault Integration

Kubernetes se integra con Vault para inyección de secretos:

Flujo de Secrets Injection

---
title: Flujo de Secretos con Vault en Kubernetes
---
flowchart TD
    classDef step fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,rx:8,ry:8
    classDef vault fill:#fff3e0,stroke:#f57c00,stroke-width:2px,rx:8,ry:8
    classDef success fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px,rx:8,ry:8
    classDef optional fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,rx:8,ry:8

    A[1. Pod inicia en Kubernetes]:::step
    B[2. Init Container ejecuta Vault Agent]:::vault
    C[3. Contenedor principal inicia]:::step
    D[4. Vault Agent Sidecar

        opcional]:::optional
    E[✅ Aplicación ejecutándose

        con secretos seguros]:::success

    C1[Autentica con Vault usando

        Service Account]:::vault
    C2[Obtiene secretos

        DB passwords, API keys]:::vault
    C3[Escribe secretos en

        volumen compartido]:::vault
    D1[Lee secretos desde

        volumen NO desde

        variables de entorno]:::success
    D2[Renueva secretos

        automáticamente]:::optional
    D3[Refresca cada 1 hora]:::optional

    A --> B
    B --> C1
    B --> C2
    B --> C3
    C1 & C2 & C3 --> C
    C --> D1
    D1 --> D
    D --> D2
    D2 --> D3
    D3 --> E

9.14.2 Tipos de Secretos Gestionados

Database Credentials: PostgreSQL, Redis passwords
API Keys: Firebase, servicios externos
JWT Signing Keys: Para autenticación OAuth
Encryption Keys: Para datos sensibles
SSL Certificates: Para comunicación interna

Nunca almacenar secretos en:

Variables de entorno en Kubernetes manifests
ConfigMaps (son plain text)
Git repositories
Docker images

9.15.1 Pipeline Automatizado

Flujo CI/CD Completo

---
title: Kubernetes CI/CD Pipeline
config:
  theme: base
  themeVariables:
    primaryColor: "#e3f2fd"
    primaryBorderColor: "#1976d2"
    primaryTextColor: "#0d47a1"
    clusterBkg: "#f5f5f5"
    clusterBorder: "#bdbdbd"
---
flowchart TD
    %% === INICIO DEL PIPELINE ===
    Start([Inicio del Pipeline]) --> Push
    
    subgraph Source["🔀 Fuente"]
        Push[Developer Push → Git
GitHub/GitLab]
        MR[Merge Request Created]
        Push --> MR
    end
    
    Push --> CI
    MR --> CI
    
    CI[CI Pipeline Triggered] --> Tests
    
    %% === FASE DE TESTING ===
    subgraph Tests["🧪 Testing Phase"]
        direction TB
        Lint[Lint & Static Analysis] --> Unit
        Unit[Unit Tests] --> Integration
        Integration[Integration Tests] --> Security
        Security[Security Scan
Snyk · Trivy · Checkmarx]
    end
    
    Tests --> Build
    
    %% === FASE DE CONSTRUCCIÓN ===
    subgraph Build["🏗️ Build & Package"]
        direction TB
        DockerBuild[Multi-stage Docker Build] --> Tagging
        Tagging[Tag Image
git-sha · version · env] --> Scan
        Scan[Image Vulnerability Scan] --> PushRegistry
        PushRegistry[Push to Container Registry]
    end
    
    Build --> DeployDev
    
    %% === DESPLIEGUE EN DESARROLLO ===
    subgraph DeployDev["🟢 Development Environment"]
        direction TB
        ApplyDev[kubectl apply -f k8s/dev] --> WaitDev[Wait for Rollout]
        WaitDev --> SmokeTests[Smoke Tests]
        SmokeTests --> NotifyDev[Notify Team]
    end
    
    DeployDev --> Approval1{¿Tests pasan?}
    
    Approval1 -->|Sí| DeployStaging
    Approval1 -->|No| FailDev[❌ Fail Pipeline]
    
    %% === DESPLIEGUE EN STAGING ===
    subgraph DeployStaging["🟡 Pre-Production Environment"]
        direction TB
        ManualApproval1[Manual Approval Required] --> ApplyStaging
        ApplyStaging[kubectl apply -f k8s/staging] --> E2ETests
        E2ETests[End-to-End Tests] --> PerfTests[Performance Tests]
    end
    
    DeployStaging --> Approval2{¿QA Approved?}
    
    Approval2 -->|Sí| DeployProd
    Approval2 -->|No| FailStaging[❌ Rollback Staging]
    
    %% === DESPLIEGUE EN PRODUCCIÓN ===
    subgraph DeployProd["🔴 Production Deployment"]
        direction TB
        ManualApproval2[Change Advisory Board
Approval Required] --> BlueGreen
        
        subgraph BlueGreen["🔄 Blue-Green Strategy"]
            direction TB
            DeployNew[Deploy to 'green' env] --> HealthChecks
            HealthChecks[Health Checks & Readiness
5 min monitoring] --> TrafficSwitch
            TrafficSwitch[Switch Traffic
Load Balancer Update] --> MonitorProd
        end
        
        MonitorProd[Monitor Production
15 min observation window]
    end
    
    DeployProd --> HealthCheck{¿Error Rate > 1%?}
    
    HealthCheck -->|Sí| Rollback
    HealthCheck -->|No| Success
    
    %% === RESULTADOS FINALES ===
    subgraph Rollback["🔄 Rollback Automático"]
        direction TB
        TriggerRollback[Trigger Rollback] --> RevertTraffic
        RevertTraffic[Revert to 'blue' env] --> NotifyTeam
        NotifyTeam[Notify DevOps Team] --> Investigate[Investigate Issues]
    end
    
    subgraph Success["✅ Deployment Successful"]
        direction TB
        Cleanup[Cleanup Old Resources] --> NotifySuccess
        NotifySuccess[Notify Stakeholders] --> Metrics[Update Deployment Metrics]
    end
    
    %% === ESTILOS Y CLASES ===
    classDef source fill:#E3F2FD,stroke:#2196F3,stroke-width:3px,rx:10,ry:10
    classDef testing fill:#FFF9C4,stroke:#FBC02D,stroke-width:3px,rx:10,ry:10
    classDef build fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:10,ry:10
    classDef dev fill:#E0F2F1,stroke:#00897B,stroke-width:3px,rx:10,ry:10
    classDef staging fill:#F3E5F5,stroke:#9C27B0,stroke-width:3px,rx:10,ry:10
    classDef prod fill:#FFE5E5,stroke:#E74C3C,stroke-width:3px,rx:10,ry:10
    classDef deployment fill:#E1F5FE,stroke:#0277BD,stroke-width:3px,rx:10,ry:10
    classDef rollback fill:#FFEBEE,stroke:#C62828,stroke-width:3px,rx:10,ry:10
    classDef success fill:#E8F5E9,stroke:#4CAF50,stroke-width:3px,rx:10,ry:10
    classDef decision fill:#FFFFFF,stroke:#666666,stroke-width:2px,rx:10,ry:10
    
    %% APLICAR ESTILOS ===
    class Source,Start,Push,MR source
    class Tests,Lint,Unit,Integration,Security testing
    class Build,DockerBuild,Tagging,Scan,PushRegistry build
    class DeployDev,ApplyDev,WaitDev,SmokeTests,NotifyDev dev
    class DeployStaging,ManualApproval1,ApplyStaging,E2ETests,PerfTests staging
    class DeployProd,ManualApproval2 prod
    class BlueGreen,DeployNew,HealthChecks,TrafficSwitch,MonitorProd deployment
    class Rollback,TriggerRollback,RevertTraffic,NotifyTeam,Investigate rollback
    class Success,Cleanup,NotifySuccess,Metrics success
    class Approval1,Approval2,HealthCheck decision

9.15.2 Deployment Strategies

Estrategia	Uso	Pros	Cons
Rolling Update	Updates normales	Zero downtime, gradual	Dos versiones coexistiendo temporalmente
Blue-Green	Releases mayores	Rollback instantáneo, testing completo	Requiere 2x recursos temporalmente
Canary	Features de alto riesgo	Exposición gradual (5% → 100%)	Requiere feature flags

9.16.1 Backup de Configuraciones

Componente	Método de Backup	Frecuencia
Kubernetes Manifests	Git repository (GitOps)	Cada commit (versionado)
etcd (K8s state)	Velero snapshots	Cada 6 horas
Persistent Volumes	Volume snapshots (cloud provider)	Diario
Secrets (Vault)	Vault snapshots	Diario

9.16.2 Plan de Disaster Recovery

Escenario	RTO	RPO	Procedimiento
Pod crash	< 30 segundos	0	K8s reinicia automáticamente
Node failure	< 5 minutos	0	K8s reschedula pods en otros nodos
Zona AZ completa	< 5 minutos	0	Réplicas en otras AZ asumen carga
Cluster completo	< 2 horas	< 6 horas	Restaurar desde Velero backup + DB restore
Región completa	< 6 horas	< 1 día	Failover a región secundaria (geo-replication)

9.17.1 Costos Mensuales Estimados (AWS EKS)

Componente	Especificación	Costo Mensual (USD)
EKS Control Plane	1 cluster	$73
Nodos EC2 Producción	2x t3.xlarge (4vCPU, 16GB)	$300
Nodos EC2 Pre-Prod	2x t3.large (2vCPU, 8GB)	$150
Nodos EC2 Dev	1x t3.medium (2vCPU, 4GB)	$40
Load Balancer	Application LB	$25
EBS Volumes	5 TB SSD (gp3)	$400
NAT Gateway	2 AZ	$90
Data Transfer	1 TB egress	$90
Backup Storage	1 TB S3 Glacier	$15
CloudWatch Logs	50 GB/mes	$30
Route 53	Hosted zone + queries	$10

Total Estimado (solo K8s infra): ~$1,223/mes
Total con bases de datos y servicios adicionales: ~$2,700/mes

9.17.2 Optimizaciones de Costo

Reserved Instances: 40-60% descuento comprando 1-3 años → Ahorro $400/mes
Spot Instances para Dev/QA: 70-90% descuento → Ahorro $80/mes
S3 Lifecycle policies: Mover logs antiguos a Glacier → Ahorro $50/mes
Right-sizing: Análisis mensual de uso → Ahorro 15-25%

Costo Optimizado: ~$2,000/mes (~$24,000/año)