Llegué a un proyecto donde el discurso oficial era claro: "con Kubernetes vamos a resolver todos nuestros problemas de despliegue". Seis meses después seguían con los mismos problemas, más un clúster carísimo que nadie entendía del todo. La herramienta era excelente. El equipo, no estaba listo, y eso no es un defecto técnico.
Con el tiempo entendí algo que ahora repito mucho: Kubernetes no arregla equipos rotos, los expone bajo una luz muy fuerte.
Si dos equipos no se hablaban antes, ahora se pelean por los límites de recursos del mismo namespace. Si nadie definía qué significaba "la aplicación está sana", ahora tienen sondas de vida que reinician contenedores en bucle sin que nadie sepa por qué. Si las responsabilidades eran difusas, ahora hay un YAML gigante que es de todos y por tanto de nadie.
Lo que funcionó no fue una charla técnica más. Fue sentarnos a acordar un contrato entre las personas antes de tocar el clúster. ¿Qué equipo es dueño de cada servicio? ¿Qué significa que un servicio esté listo para recibir tráfico, en términos concretos, no filosóficos? ¿Quién responde a las tres de la mañana cuando un pod entra en pánico?
Solo después de responder eso, los manifiestos empezaron a tener sentido. Las sondas de disponibilidad dejaron de ser copiar y pegar y pasaron a reflejar de verdad cuándo un servicio podía trabajar. Los límites de recursos dejaron de ser adivinanzas y pasaron a ser negociaciones honestas entre equipos que ahora sí se hablaban.
Kubernetes nos obligó a ser explícitos sobre cosas que antes vivían en la ambigüedad cómoda. Y esa incomodidad, aunque dolió, fue lo mejor que nos pasó. Nos forzó a acordar como personas lo que la plataforma iba a ejecutar como máquina.
Si están pensando en dar el salto, mi pregunta no sería "¿saben de contenedores?". Sería "¿saben quién es dueño de qué, y están dispuestos a escribirlo?". El clúster amplifica lo que ya son. Que amplifique acuerdos, no silencios.
– Sergey Shinder
Top comments (0)