Infraestructura

Lo que aprendí migrando 40 servicios a Kubernetes

Seis meses, dos incidentes serios y una conclusión incómoda: el clúster fue lo fácil. Lo difícil fue todo lo demás.

Ada RíosIngeniera de plataformas18 sep 20261 min de lectura
  • Infraestructura
  • Producción
Lo que aprendí migrando 40 servicios a Kubernetes

Cuando empezamos, el plan cabía en una diapositiva: contenedores, un clúster gestionado y a correr. Seis meses después tengo claro que el clúster fue la parte fácil.

El inventario que no teníamos#

Antes de mover nada hicimos lo que deberíamos haber hecho años antes: un inventario honesto de cada servicio. Quién lo mantiene, de qué depende, qué pasa si se cae.

TipoServiciosMigrados sin cambios
APIs sin estado2421
Trabajos en cola94
Con estado propio70

Los siete con estado propio se quedaron fuera de la primera fase. Fue la mejor decisión del proyecto.

Límites de recursos: la trampa de los valores por defecto#

Desde entonces ningún despliegue pasa la revisión sin esto:

deployment.yaml
resources:  requests: { cpu: 250m, memory: 256Mi }  limits:   { memory: 512Mi }

Sin límite de CPU, a propósito: el throttling nos dio más latencia que ruido.

Lo que haría distinto#

  1. Empezar por la observabilidad, no por el clúster.
  2. Migrar primero los servicios aburridos: ganan confianza y no hacen ruido.
  3. Poner presupuestos de error antes de la primera migración, no después del primer incidente.

La migración terminó en febrero. El equipo, que al principio la veía como un castigo, hoy despliega cuatro veces más que antes.

¿Te ha servido?

Cada dos semanas, un artículo como este en tu correo. Sin spam.