Kubernetes y DevOps: Infraestructura de Grado Producción
Desde contenedores Docker hasta clusters Kubernetes en GKE y EKS. Charts de Helm, service mesh Istio, pipelines CI/CD, prácticas SRE y optimización de costos — todo probado en batalla con plataformas de 26 microservicios.
Por Jose Nobile | Actualizado 2026-07-26 | 13 min de lectura
Docker: Fundamentos de Contenedores
La contenedorización es la base de la infraestructura moderna. Docker empaqueta tu aplicación, sus dependencias y ambiente de ejecución en una unidad portable y reproducible. Hacer bien los contenedores a nivel fundacional previene problemas en cascada en Kubernetes, CI/CD y producción.
Prácticas clave para imágenes Docker de producción:
- Builds multi-stage — Separa etapas de build y runtime. Build con SDK completo, ejecución con runtime mínimo. Reduce el tamaño de imagen 60-80%.
- Usuarios no-root — Nunca ejecutes contenedores como root. Crea un usuario dedicado en el Dockerfile para compliance de seguridad.
- Cache de capas — Ordena las instrucciones del Dockerfile de menos a más frecuentemente cambiadas. Copia package.json antes del código fuente para cachear la instalación de dependencias.
- Health checks — Define instrucciones HEALTHCHECK para orquestación apropiada de contenedores e integración con load balancer.
- Escaneo de imágenes — Integra Trivy o Snyk en tu pipeline CI para detectar vulnerabilidades antes del despliegue.
Kubernetes en GKE y EKS
Los servicios gestionados de Kubernetes (GKE en Google Cloud, EKS en AWS) eliminan la complejidad de gestión de clusters mientras proveen confiabilidad empresarial. La elección entre GKE y EKS depende de tu inversión cloud existente y requisitos específicos.
Google Kubernetes Engine
Aprovisionamiento de cluster más rápido, modo Autopilot para gestión hands-off, GKE Ingress integrado con Google Cloud Load Balancer, integración estrecha con Cloud Build y Artifact Registry. Mejor relación costo-rendimiento.
Amazon Elastic Kubernetes
Integración profunda con AWS (roles IAM para service accounts, storage EBS/EFS, ALB Ingress), Fargate para pods serverless, marketplace extenso de add-ons. Preferido cuando tus datos y servicios ya están en AWS.
Diseño de Cluster
Namespaces separados por ambiente (dev, staging, prod). Usa node pools para aislamiento de workloads (CPU-intensivo vs. memoria-intensivo). Habilita cluster autoscaler con límites min/max apropiados.
Gestión de Charts Helm
Helm empaqueta manifiestos de Kubernetes en charts reutilizables y versionados. Para plataformas con 26 microservicios, Helm es esencial — estandariza configuraciones de despliegue, habilita overrides por ambiente vía values files, y provee capacidades de rollback atómico.
Una estrategia de Helm chart bien estructurada para plataformas de microservicios:
- Chart base — Un chart genérico que maneja el 90% de tus servicios (deployment, service, ingress, HPA, PDB). Los servicios usan overrides de values.yaml para personalización.
- Values por ambiente — Archivos de values separados por ambiente:
values-dev.yaml,values-staging.yaml,values-prod.yaml. Mantén los secretos en un store encriptado separado. - Versionado de charts — Versionado semántico para charts. Cambios breaking incrementan la versión mayor. CI valida templates de charts antes del merge.
- Helmfile — Gestiona declarativamente múltiples releases entre ambientes. Un comando para sincronizar todos los servicios en un ambiente.
Service Mesh Istio
Istio agrega una capa de infraestructura transparente que maneja comunicación servicio-a-servicio, seguridad y observabilidad sin modificar código de aplicación. Para plataformas de microservicios, Istio provee capacidades que de otra forma requerirían implementación custom en cada servicio.
Gestión de Tráfico
Despliegues canary con división de tráfico por porcentaje, A/B testing vía ruteo por headers, circuit breaking para servicios fallando, reintentos automáticos con backoff configurable, y timeouts de requests.
Mutual TLS
mTLS automático entre todos los servicios sin cambios de código. Cada llamada servicio-a-servicio está encriptada y autenticada. La rotación de certificados ocurre de forma transparente.
Observabilidad
Tracing distribuido (Jaeger/Zipkin), métricas a nivel de servicio (latencia, tasas de error, throughput), visualización de dependencias (Kiali) y logging de acceso para cada request.
Pipelines CI/CD
Los pipelines de Integración Continua y Despliegue Continuo automatizan el camino desde el commit de código hasta el despliegue en producción. Un pipeline bien diseñado asegura que cada cambio sea testeado, validado y desplegado consistentemente — eliminando error humano del proceso de release.
GitOps e Ingeniería de Plataformas (2026): La adopción de GitOps cruzó un umbral crítico, con más del 64% de las empresas reportándolo como su mecanismo de entrega principal. Argo CD 3.4 es la línea estable actual (3.4.5 publicado el 9 de julio de 2026), que agrega notificaciones de Microsoft Teams Workflows -- el reemplazo de los Office 365 Connectors que Microsoft retiró el 31 de marzo de 2026 --, filtrado de la lista de Applications por anotaciones y un nuevo filtro de Operation Status; 3.5 está en pruebas de release candidate. Flux continúa diferenciándose con su GitOps Toolkit componible que monitorea registries de imágenes y actualiza manifiestos automáticamente. La tendencia más amplia es la estandarización de ingeniería de plataformas -- las plataformas internas de desarrollo (IDPs) ahora integran Argo CD o Flux como herramientas de día uno, proveyendo caminos dorados que aplican consistencia y trazabilidad mientras abstraen la complejidad de Kubernetes de los desarrolladores de aplicaciones.
Kubernetes 1.36 "Haru" (lanzado 22 de abril de 2026) incluye 70 mejoras rastreadas, incluyendo DRA alcanzando GA para scheduling de GPU, HPAScaleToZero habilitado por defecto, User Namespaces GA para contenedores rootless, OCI VolumeSource GA y MutatingAdmissionPolicy graduando a stable. El Ingress NGINX Controller fue oficialmente retirado el 24 de marzo de 2026 -- todos los equipos deben migrar a Gateway API. En el lado de herramientas, Helm 4 entrega Server-Side Apply por defecto y chequeos de readiness basados en kstatus, haciendo helm install --wait confiable en pipelines CI/CD por primera vez. Helm 4.2.3 (9 de julio de 2026) es el release estable actual. Helm 3 ya tiene fin de vida publicado: 3.22.0 el 9 de septiembre de 2026 es el último release de features (solo actualizaciones del cliente de Kubernetes) y los parches de seguridad terminan el 10 de febrero de 2027 -- así que los equipos que siguen en v3 deben planear su migración ahora.
GitLab CI/CD
La plataforma CI/CD principal de Jose. Integrada con repositorios GitLab, Docker registry y clusters Kubernetes. Features: pipelines multi-proyecto, pipelines padre-hijo, ambientes dinámicos y auto DevOps.
GitHub Actions
Usado para proyectos open-source y más pequeños. Builds matrix para testing cross-platform, workflows reutilizables para lógica CI compartida, GitHub Container Registry para imágenes, y OIDC para deploys cloud seguros.
Arquitectura del Pipeline
Etapas estándar: lint, test, build, scan, deploy-staging, integration-test, deploy-prod. Ejecución paralela donde sea posible. Cada etapa tiene criterios claros de éxito/falla y triggers de rollback.
El pipeline CI/CD maneja 26 microservicios y 41 variantes de apps Android de marca. Un solo push a la rama main dispara builds paralelos en todos los servicios, ejecuta tests de integración y despliega a staging. El deploy a producción es una promoción de un clic después de aprobación QA.
Prácticas SRE
Site Reliability Engineering conecta desarrollo y operaciones, usando prácticas de ingeniería de software para resolver problemas de infraestructura. Los principios centrales que marcan la diferencia en producción:
SLOs y Error Budgets
Define Service Level Objectives para latencia (p99 < 200ms), disponibilidad (99.9%) y tasa de error (< 0.1%). Los error budgets determinan cuándo congelar features y enfocarse en confiabilidad.
Respuesta a Incidentes
Runbooks documentados para fallas comunes, rotación on-call con paths de escalación, revisiones post-incidente (sin culpa) y remediación automatizada para patrones de falla conocidos.
Planificación de Capacidad
Load testing antes de releases importantes, políticas de autoscaling basadas en patrones de tráfico reales, cuotas de recursos por namespace y revisiones periódicas de right-sizing.
Gestión de Cambios
Rollouts progresivos (canary y luego completo), feature flags para desacoplar deploy de release, rollback automático ante aumento de tasa de error, y ventanas de deployment para cambios de alto riesgo.
Stack de Observabilidad
Observabilidad significa entender qué está pasando dentro de tu sistema examinando sus outputs. Los tres pilares — métricas, logs y trazas — trabajan juntos para proveer visibilidad completa del comportamiento del sistema.
- Métricas — Prometheus para colección, Grafana para visualización. Métricas clave: tasa de requests, tasa de error, latencia (método RED) y utilización de recursos.
- Logs — Logging JSON estructurado, centralizado con stack ELK o Loki. IDs de correlación entre servicios para tracing de requests.
- Trazas — Tracing distribuido con Jaeger o Tempo. Visualiza el flujo de requests entre microservicios, identifica cuellos de botella.
- Alertas — Alerta por violaciones de SLO, no por umbrales de métricas individuales. Integración PagerDuty u Opsgenie para notificaciones on-call.
Optimización de Costos
Right-Sizing
Analiza uso real de recursos vs. límites solicitados. La mayoría de los servicios sobre-provisionan 40-60%. Usa recomendaciones VPA para ajustar requests y limits.
Nodos Spot / Preemptible
Corre workloads stateless en instancias spot (60-90% de ahorro). Configura pod disruption budgets y pod anti-affinity para manejar evictions de nodos elegantemente.
Cluster Autoscaler
Escala nodos automáticamente según necesidades de scheduling de pods. Configura delays de scale-down para evitar thrashing. Usa prioridades de node pool para preferir tipos de instancia más baratos.
Cuotas de Recursos
Establece cuotas a nivel de namespace para prevenir consumo descontrolado de recursos. Implementa LimitRanges para límites por defecto de contenedores. Revisa y ajusta cuotas mensualmente.
Ejemplo Real: Infraestructura en Producción
La plataforma corre 26 microservicios en Google Kubernetes Engine, sirviendo múltiples países con facturación localizada (Stripe + MercadoPago). La infraestructura soporta 41 variantes de apps Android de marca construidas y desplegadas a través de un pipeline CI/CD unificado.
20+ Microservicios en GKE
Servicios Node.js/TypeScript corriendo en GKE con deployments gestionados por Helm. Autoscaling basado en CPU y métricas custom. Istio para service mesh, Prometheus + Grafana para observabilidad.
CI/CD de 41 Apps Android
Un solo pipeline GitLab CI construye 41 variantes de marca de la app Android. Cada variante tiene sus propios assets de branding, endpoints de API y listing de Play Store. Un solo push despliega todas las variantes, ahorrando ~2 semanas por ciclo de release.
Despliegue Multi-País
Configuraciones específicas por región para cálculos de impuestos, proveedores de pago y requisitos de compliance. Infraestructura como código asegura ambientes consistentes entre regiones con mínimo config drift.