Migración a Kubernetes | Guía de producción

Una migración a Kubernetes no consiste en mover contenedores a otro clúster y declarar la operación resuelta. El riesgo aparece en las dependencias que no se documentaron, los límites de recursos que nunca se midieron, las identidades que se copiaron sin revisar y el tráfico que no tiene una vuelta atrás clara. Cuando la migración se hace con prisa, la plataforma nueva hereda la fragilidad de la anterior y añade una capa de complejidad que después cuesta gobernar.

El objetivo de una migración a Kubernetes debería ser operativo, no solo tecnológico: mejorar la repetibilidad del delivery, hacer visibles los límites de capacidad, reducir cambios manuales y conservar un rollback verificable. Antes de mover tráfico, hay que conocer qué depende de qué, qué señales indican que el servicio está sano y qué condición obliga a volver al sistema anterior.

Esta guía cubre ese camino completo: preparación de la migración, seguridad por defecto, escalado basado en datos, observabilidad accionable, networking pragmático y un modelo de entrega que no dependa de memoria tribal. La meta no es adoptar Kubernetes por inercia. Es decidir si el cambio reduce riesgo y coste operativo en tu contexto.

Qué debe resolver una migración a Kubernetes

Los artículos siguientes cubren áreas específicas con profundidad técnica. Esta guía actúa como mapa de entrada y complemento transversal.

Migrar Ingress NGINX tras su retiro: guía y alternativas: opciones reales para equipos en transición que necesitan decidir sin que la urgencia dicte la arquitectura
EKS Auto Mode vs Karpenter: cuál es mejor para tu cluster: escalado inteligente en AWS, cuándo cada opción compensa y qué tradeoffs concretos implica cada una
Tendencias DevOps 2026: platform engineering, IA y FinOps: contexto del ecosistema para entender qué está cambiando y qué tiene tracción real más allá del ciclo de hype
Beneficios de GitOps con ArgoCD | Helm: delivery declarativo y reversible con reconciliación continua, y por qué ese modelo importa más que el repositorio de YAML
Migración cloud sin tiempo de inactividad: cómo hacerlo bien: patrón de migración por fases que preserva disponibilidad y permite volver atrás si algo no sale como se esperaba

Migración a Kubernetes: una secuencia con rollback antes del cambio de tráfico

Una migración controlada separa el trabajo de conocer el sistema del trabajo de moverlo. La secuencia siguiente reduce el blast radius y deja una condición concreta para avanzar:

Construye el baseline. Mide tráfico, latencia, errores, consumo, dependencias externas y comportamiento de jobs durante una ventana representativa. Sin baseline, no puedes distinguir una regresión de una variación normal.
Clasifica los workloads. Separa servicios stateless, datos stateful, jobs, integraciones y componentes de entrada. Cada grupo necesita una estrategia distinta de persistencia, escalado, exposición y rollback.
Define el contrato de ejecución. Declara requests, limits, probes, políticas de red, identidad, secretos, almacenamiento y requisitos de disponibilidad. Lo que no está explícito acaba siendo una excepción manual.
Prueba en paralelo. Despliega una primera carga representativa sin retirar el sistema de origen. Valida funcionalidad, observabilidad, rendimiento, seguridad y comportamiento ante dependencias lentas o caídas.
Desvía tráfico gradualmente. Usa canary, blue-green o una estrategia equivalente. Compara las señales con el baseline y fija un umbral de rollback antes de que empiece la ventana de cambio.
Retira el origen solo después de validar. Conserva durante el tiempo acordado la capacidad de volver atrás, los datos necesarios y el procedimiento de reversión. El rollback no es una frase en el runbook si nunca se ha probado.

Gate antes del siguiente paso	Debe estar demostrado	No avanzar si...
Dependencias	Las llamadas, colas, DNS, almacenamiento y credenciales están inventariados	Hay dependencias críticas conocidas solo por una persona
Salud	Las métricas y logs del destino se comparan con el baseline	Solo se comprueba que los pods están `Running`
Capacidad	Requests, limits y escalado responden a carga medida	El sizing se basa en valores copiados del sistema anterior
Cambio	Existe una ventana, un owner y un umbral de rollback	El retorno depende de cambios manuales no documentados

Esta secuencia también ayuda a decidir si Kubernetes es realmente el destino correcto. Si el equipo no puede describir el estado actual, medir la salud del servicio o volver atrás, todavía no está preparado para acelerar la migración.

Seguridad y gobernanza en Kubernetes

La seguridad en Kubernetes falla sistemáticamente por dos razones que rara vez se discuten juntas. La primera es que los permisos excesivos se acumulan en silencio. La segunda es que ese silencio termina cuando hay un incidente.

El modelo de identidad de Kubernetes se construye sobre RBAC, pero RBAC sin disciplina se degrada rápido. Lo que empieza como un ClusterRole con permisos amplios "para que el equipo pueda iterar rápido" se queda ahí durante meses, y con él se queda una superficie de ataque que nadie revisa. En la práctica, el principio de mínimo privilegio no consiste en reducir permisos hasta que el sistema falle, sino en ser deliberado sobre qué puede hacer cada service account y revisar esa decisión con cadencia.

Las Network Policies merecen una mención especial porque su ausencia no genera errores visibles, solo riesgo latente. Sin políticas de red, el comportamiento por defecto es que cualquier pod puede alcanzar a cualquier otro. Eso significa que un compromiso local puede convertirse en movimiento lateral con poco esfuerzo. Y significa también que un servicio mal configurado, con un loop de reintentos o una pérdida de control sobre sus conexiones salientes, puede degradar al resto del clúster de formas difíciles de atribuir. Introducir NetworkPolicies tiene un coste inicial real: obliga a mapear flujos de comunicación que suelen estar implícitos. Ese coste compra contención.

Pod Security es el tercer pilar. El retiro de PodSecurityPolicy y la llegada de Pod Security Admission, junto con proyectos como Kyverno, cambiaron el modelo operativo pero no cambiaron el problema de fondo: los pods con capacidades excesivas, montando hostPath o corriendo como root son vectores de escalada de privilegios. Aplicar perfiles restricted o baseline por defecto y requerir excepciones explícitas con revisión no es burocracia. Es ingeniería defensiva.

La cadena de suministro cierra el triángulo. Escanear imágenes en CI con Trivy o Grype y bloquear despliegues con CVEs críticos sin parche conocido reduce la superficie de forma efectiva. El problema que vemos con frecuencia es que los escaneos existen pero las políticas de bloqueo no. Detectar una vulnerabilidad y desplegarla de todos modos no aporta valor. La detección útil es la que interrumpe el flujo cuando el riesgo supera un umbral acordado.

La gobernanza completa el modelo. Admission webhooks, OPA Gatekeeper o Kyverno como políticas declarativas permiten codificar las decisiones de seguridad como política versionada. Eso tiene una consecuencia práctica importante: las excepciones se vuelven visibles, auditables y reversibles. En lugar de tener un pod privilegiado que "nadie sabe por qué está así", tienes una excepción documentada en Git con una justificación y un owner.

Escalado y recursos

El escalado en Kubernetes se discute habitualmente como una decisión de herramienta: HPA o VPA, Cluster Autoscaler o Karpenter, escalado por CPU o por métricas personalizadas. Esas elecciones importan, pero la pregunta anterior es más importante: ¿tus workloads tienen requests y limits declarados con precisión suficiente para que el scheduler tome decisiones correctas?

Sin requests realistas, el scheduler asigna pods a nodos basándose en información incorrecta. El resultado son nodos sobrecomprometidos que bajo presión generan throttling de CPU o OOMKills de memoria. Ambos síntomas se parecen a inestabilidad de la aplicación. Los OOMKills especialmente, porque implican pérdida de caché, reconexiones y warm-up que, en servicios críticos, se traducen en latencia adicional que alguien atribuye a "la aplicación" y no a la configuración de recursos.

El HPA es útil cuando la señal está bien elegida. Escalar solo por CPU es un atajo que falla sistemáticamente en cargas I/O bound, servicios que esperan respuestas de dependencias lentas o sistemas que acumulan presión en colas antes de que el consumo de CPU lo refleje. En esos casos, KEDA o métricas personalizadas basadas en profundidad de cola, lag de consumidores o conexiones activas permiten escalar por demanda real en lugar de por un proxy imperfecto.

En AWS, la elección entre EKS Auto Mode y Karpenter define el modelo operativo del escalado de nodos. Auto Mode reduce la carga operativa cediendo control al servicio gestionado. Karpenter da control granular sobre tipos de instancia, zonas, consolidación agresiva y políticas de interrupción de Spot. La elección correcta depende de cuánto quieres operar, no de cuál tiene mejor marketing. EKS Auto Mode vs Karpenter cubre esa decisión con detalle.

VPA complementa HPA para workloads donde el escalado horizontal no es la respuesta: jobs batch, servicios con memoria que crece según datos cargados al inicio, o aplicaciones que el equipo no puede o no quiere replicar. VPA en modo Off con recomendaciones visibles es un punto de partida sensato antes de activar ajuste automático, que requiere aceptar reinicios planificados.

Observabilidad en producción

La observabilidad que importa no es la que registra todo, sino la que permite tomar decisiones bajo presión. En on-call, la diferencia entre una observabilidad bien diseñada y una mal diseñada no es cuántos dashboards hay, sino cuánto tiempo tardas en pasar de "hay un problema" a "sé qué está fallando y por qué".

OpenTelemetry es el estándar de facto para instrumentación porque desacopla la colección de la señal del backend donde la analizas. Instrumentas una vez y puedes cambiar de Jaeger a Tempo, de Prometheus a Mimir, sin reescribir código de aplicación. En organizaciones que crecen o que evalúan cambiar de proveedor de observabilidad, ese desacoplamiento tiene valor económico real.

La pila más común que equilibra capacidad y coste operativo en clusters propios es Prometheus para métricas, Loki para logs y Tempo o Jaeger para trazas, todo expuesto a través de Grafana. En entornos gestionados, servicios como Amazon Managed Prometheus o Google Cloud Managed Service for Prometheus eliminan la carga operativa del almacenamiento y retención a cambio de coste directo.

El salto de madurez que más reduce MTTR es pasar de alertas por umbral a alertas por consumo de error budget. Las alertas por umbral generan ruido porque no distinguen entre "algo cambió" y "algo importa". Una alerta de burn rate del SLO vincula la señal con impacto en experiencia de usuario, no con valores absolutos que envejecen mal. Ese cambio no es cosmético: reduce la fatiga de on-call y convierte las alertas en accionables de nuevo.

Los logs estructurados en JSON, correlacionados por trace ID o request ID, son el complemento que hace trazable la investigación. Cuando un problema requiere saltar de métrica a traza a log, la correlación por identificador común es lo que permite seguir el hilo en segundos en lugar de minutos.

Networking e Ingress

El controlador de ingress es el primer punto de contacto del tráfico externo y, por tanto, uno de los puntos de mayor impacto en disponibilidad y seguridad. En 2026, la transición ya tiene una fecha pasada: Ingress NGINX se retiró tras marzo de 2026 y dejó de recibir nuevas versiones, parches y correcciones de seguridad. Si un clúster todavía depende de él, la migración es una decisión de riesgo operativo, no una mejora opcional que pueda posponerse sin criterio.

Las alternativas principales son Gateway API como sucesor formal con más expresividad y mejor separación de responsabilidades, y controladores mantenidos como AWS Load Balancer Controller, NGINX Gateway Fabric o Traefik. Para equipos que todavía dependen de Ingress NGINX, la guía de migración tras su retiro cubre la transición con criterios concretos para decidir sin que la urgencia dicte la arquitectura.

Gateway API merece atención especial porque resuelve problemas que Ingress nunca pudo modelar bien: routing por cabecera, rutas compartidas entre equipos con ownership separado, políticas de retry y timeout expresadas como recursos propios, e integración limpia con service mesh. El salto de Ingress a Gateway API no es trivial, pero en organizaciones con múltiples equipos que comparten el mismo punto de entrada, el modelo de roles de Gateway API simplifica la gobernanza de forma significativa.

El service mesh es la extensión natural del networking interno cuando las necesidades de seguridad, observabilidad o control de tráfico superan lo que se puede manejar con NetworkPolicies y configuración a nivel de ingress. Istio y Linkerd son las opciones más maduras. La decisión de adoptar un service mesh debería ser impulsada por necesidades concretas verificadas, no por la aspiración de tener mTLS "porque es bueno". La complejidad operativa que añade un mesh mal gobernado suele costar más que el riesgo que mitiga.

Migración a Kubernetes y GitOps

Migrar a Kubernetes sin un modelo de delivery claro es trasladar el problema, no resolverlo. En muchos proyectos de migración, el primer resultado es una plataforma técnicamente más sofisticada con los mismos procesos manuales de antes, solo que ahora expresados en YAML en lugar de en scripts de bash. La deuda cambia de forma pero no desaparece.

GitOps resuelve el problema de raíz porque convierte el estado deseado del clúster en código versionado, revisado y reconciliado de forma continua. Con ArgoCD como control loop, el clúster converge automáticamente al estado que Git dice que debería tener. Si alguien hace un cambio manual, el drift es visible. Si un despliegue falla, el rollback es un git revert. Si necesitas auditar qué cambió y cuándo, el historial de Git es la fuente de verdad.

La guía de beneficios de GitOps con ArgoCD cubre la implementación con Helm, separación de valores por entorno y el modelo de ApplicationSets para gestionar múltiples clústeres o entornos sin duplicar configuración.

La migración en sí, especialmente cuando hay sistemas que no pueden permitirse tiempo de inactividad, requiere un patrón de transición por fases: replicar, verificar, redirigir tráfico de forma gradual y solo entonces retirar el sistema origen. Migración cloud sin tiempo de inactividad cubre ese patrón con criterios de go/no-go para cada fase.

Checklist de auditoría Kubernetes

Una revisión periódica del clúster no necesita ser un proceso pesado, pero sí necesita cubrir las áreas donde el drift silencioso acumula riesgo. La siguiente tabla actúa como guía mínima para equipos que quieren mantener el clúster en un estado gobernable sin convertir la auditoría en un proyecto.

Área	Pregunta de auditoría	Señal de riesgo
RBAC y permisos	¿Todos los service accounts tienen el mínimo privilegio necesario y documentado?	ClusterRoles con `*` en verbos o recursos sin justificación
Network Policies	¿Existe una política por defecto que deniegue tráfico no explícito?	Namespaces sin ninguna NetworkPolicy aplicada
Pod Security	¿Todos los workloads aplican un perfil de seguridad y las excepciones están justificadas?	Pods corriendo como root sin necesidad documentada
Recursos declarados	¿Todos los pods tienen `requests` y `limits` basados en consumo real medido?	Pods sin `requests` o con `limits` de CPU muy bajos que provocan throttling
Secretos y credenciales	¿Se usan mecanismos de identidad dinámica y no credenciales estáticas en variables de entorno?	Secretos de larga vida hardcodeados en manifiestos o configmaps
Imágenes y cadena de suministro	¿El CI bloquea despliegues con CVEs críticos sin parche conocido?	Escaneos que detectan pero no bloquean
Ingress y exposición	¿El controlador de ingress tiene rate limiting y los endpoints públicos están cubiertos?	Endpoints públicos sin ningún límite de tasa
Versión de Kubernetes	¿La versión del clúster está dentro del soporte oficial y el próximo upgrade está planificado?	Versión a menos de 60 días del fin de soporte
Add-ons y operadores	¿Todos los componentes adicionales están en versiones compatibles con la versión del clúster?	Add-ons a versiones que no figuran como compatibles
Observabilidad	¿Existen SLOs definidos con alertas de burn rate y runbooks asociados?	Alertas solo por umbral sin runbook o sin owner
Backups y recuperación	¿Los backups de estado crítico se prueban con restauración completa y RTO medido?	Backups configurados pero sin restauración verificada en los últimos 90 días
Escalado	¿El autoscaler está configurado con señales que representen presión real del sistema?	HPA por CPU en servicios I/O bound sin métricas de cola o latencia

Esta tabla no es exhaustiva, pero cubre los puntos donde consistentemente encontramos deuda acumulada en clústeres que "funcionan bien" hasta que no lo hacen.

Cuándo actuar

Si al leer esta guía reconoces más de tres puntos del checklist como áreas donde tu clúster tiene deuda sin plan de resolución, el momento de actuar es antes de que un incidente obligue a hacerlo. La diferencia entre revisar con tiempo y revisar bajo presión no es solo estrés operativo: es la diferencia entre elegir la solución correcta y elegir la solución rápida, que frecuentemente son distintas.

Un equipo externo con experiencia en operación de Kubernetes en producción puede hacer en días lo que internamente tomaría semanas: mapear el estado real del clúster, priorizar la deuda por impacto y riesgo, y definir un plan de acción que el equipo pueda ejecutar sin detener el trabajo de producto.

Si este es tu caso, la página de consultoría cloud y DevOps describe cómo trabajamos y qué tipo de situaciones atendemos.

Preguntas frecuentes sobre migración a Kubernetes

¿Cuándo merece la pena migrar a Kubernetes?

Cuando necesitas una plataforma repetible para varios servicios, equipos o entornos y el modelo actual ya genera trabajo manual, problemas de capacidad o cambios difíciles de auditar. Si solo existe un servicio sencillo y la operación es estable, la migración puede añadir más complejidad que valor.

¿Cómo se migra a Kubernetes sin tiempo de inactividad?

Mantén el sistema de origen operativo mientras validas el destino. Replica datos cuando sea necesario, prueba el workload con tráfico controlado, desvía gradualmente mediante canary o blue-green y define de antemano las señales que activan el rollback. Sin una ruta de retorno probada, no existe una migración sin downtime fiable.

¿Hay que migrar todos los servicios a la vez?

No. Empieza por un servicio de riesgo medio, con dependencias conocidas y suficiente tráfico para producir aprendizaje. Usa esa primera migración para fijar estándares de observabilidad, seguridad, despliegue y rollback antes de ampliar el alcance.

¿Qué debe estar listo antes de mover producción?

El baseline de salud, las dependencias, los límites de recursos, la identidad, los secretos, el almacenamiento, la observabilidad, el owner del cambio y el procedimiento de reversión. Si alguno de esos puntos depende de conocimiento tribal, la migración todavía no está lista.