Kubernetes

Kubernetes resuelve un conjunto concreto de problemas: publicar una versión nueva sin ventana de mantenimiento, mantener una flota de servicios sobre máquinas que van y vienen, y dar a cada entorno la misma forma. Cuando esos son los problemas, merece su coste operativo. Cuando no lo son, es un segundo sistema que mantener encima del que sirve a los usuarios.

La prueba honesta es lo que hace realmente la carga de trabajo. Un sitio de contenido con tráfico predecible funciona mejor en un servidor bien configurado, con certificados automatizados y copias probadas, que en un clúster que nadie del equipo puede depurar a las dos de la mañana. Una plataforma con varios servicios, ciclos de publicación independientes y necesidades reales de escalado es otro caso, y ahí la orquestación se paga sola.

Donde el clúster está justificado, la mayor parte del valor está en las partes aburridas: peticiones y límites de recursos que reflejan uso medido y no suposiciones, comprobaciones de salud que fallan por los motivos correctos, secretos que nunca llegan a una imagen, y manifiestos templatizados por entorno para que staging y producción se diferencien solo en los valores que deben diferenciarse.

La experiencia detrás de esto es operar plataformas de ese tamaño, incluidas cargas de Kubernetes gestionado en GCP con despliegues templatizados con Helm. La recomendación que sale de ahí es, muchas veces, usar menos infraestructura y no más.

La fiabilidad que experimenta un usuario se decide en la capa que nunca ve. Cómo se programan los contenedores, cómo pasa el tráfico por la pasarela y cómo se detiene una mala versión antes de que llegue a todo el mundo son lo que convierte el despliegue de un acontecimiento en una rutina. El objetivo no es la sofisticación por sí misma: es que un equipo de producto pueda publicar sin tener que hacerse antes experto en clústeres, y que quien está de guardia tenga una forma documentada de parar y revertir una versión, no una improvisada.