Kubecost vs OpenCost: cuando monitorear costes duele más que la factura

La historia suele empezar igual. Un equipo despliega un clúster de Kubernetes que el primer día parece limpio, moderno y escalable. Hay cierta satisfacción: los contenedores funcionan a buen ritmo, el autoescalado está bien ajustado y los paneles brillan con un verde impecable. Tres meses después llega la factura de la tarjeta. De pronto alguien de finanzas hace preguntas incómodas, alguien de ingeniería finge que no ha visto el correo y alguien de dirección se pregunta en privado quién autorizó «eso que cuesta más que el data warehouse».

Ahí empieza la búsqueda de una herramienta que tome el caos difuso de los costes de Kubernetes y lo convierta en algo comprensible para personas normales.

Casi todo el mundo empieza por los dos mismos nombres: Kubecost y OpenCost. Sobre el papel parece sencillo: uno es de código abierto y gratuito; el otro es comercial y más pulido. Ambos prometen el mismo sueño. Por fin sabrás qué cargas de trabajo, namespaces, equipos o despliegues están devorando el presupuesto, podrás justificar la infraestructura ante quienes firman los cheques y dejarás de hacer suposiciones.

Cuando los equipos empiezan a trabajar con estas herramientas, ese sueño se complica bastante. La visibilidad de costes en Kubernetes resulta ser un problema difícil, y las aplicaciones creadas para resolverlo a menudo generan sus propios dolores de cabeza. Durante los últimos meses, ingenieros de distintas empresas han estado contrastando impresiones y el panorama es muy uniforme: rastrear los costes de K8s es más confuso, inestable, inconsistente y frágil de lo que nadie quiere admitir. En muchos casos, monitorear los costes de Kubernetes acaba siendo más doloroso que la propia factura.

Cuando el código abierto parece una fuente abierta de problemas

OpenCost tiene un enfoque que encaja bien con los equipos de ingeniería: despliegue simple, ADN de código abierto y la promesa de que nadie te va a mandar una factura sorpresa. Los equipos se adentran en él esperando algo ágil y flexible.

El entusiasmo inicial es real. Un ingeniero comentaba que todo parecía excelente el primer día. Aparecían todos los datos, los gráficos se rellenaban y sentían que por fin tenían el control del gasto. La emoción duró poco. Tras funcionar durante una semana, la interfaz dejó de cargar datos históricos por completo y cargar los números de siete días provocaba timeouts. Alguien de la comunidad les sugirió compilar la herramienta en local y ajustar una directiva de NGINX para que la UI no se atragantara con sus propias consultas. Cuando un panel de costes necesita intervalos de espera personalizados para evitar caídas por timeout, la confianza se evapora rápido.

Otro equipo vivió algo similar. OpenCost funcionaba, pero solo durante los primeros cinco o seis días. A partir de ahí, los paneles se quedaban en blanco porque el sistema no aguantaba el volumen de datos que generaba su clúster. Terminaron enviando todo a Prometheus y Grafana solo para entender las cifras, porque la propia interfaz estorbaba.

Tampoco fue un caso aislado. Más de un ingeniero afirmó que OpenCost simplemente no escala en clústeres grandes. Gestiona bien entornos pequeños, pero en cuanto la carga de trabajo crece, con más pods, más métricas y más rotación, la herramienta empieza a tener dificultades.

El patrón se repite constantemente. OpenCost resulta atractivo por ser abierto y simple, pero en clústeres medianos y grandes esa simplicidad se convierte en una limitación, y en entornos con miles de pods varios ingenieros comentaron que pasó de ser «imperfecto» a «prácticamente inutilizable».

Hay algo que sí se valora: cuando OpenCost funciona, ofrece una capa básica de visibilidad y, como es de código abierto, los equipos pueden añadir encima paneles personalizados, exportadores y consultas propias. Para algunas empresas eso es suficiente, sobre todo si tienen experiencia sólida con Prometheus y Terraform. Para otras, los parches temporales se acumulan hasta que alguien dice: «No tenemos tiempo para esto», y propone probar la alternativa comercial.

Kubecost encaja bien hasta que alcanzas sus límites

Kubecost tiene otra historia. La gente lo instala y, a menudo, funciona a la primera. Un equipo señalaba que les sorprendió lo rápido que ofreció números precisos, prácticamente desde el instante de su despliegue. La interfaz estaba más cuidada, los gráficos tenían sentido, los responsables entendían lo que veían y la versión gratuita resultaba «suficiente» para clústeres pequeños.

Luego empezaron a acumularse las pegas. La versión gratuita solo conserva 15 días de datos, lo que no basta para informes mensuales, previsiones ni revisiones financieras. Si tu clúster supera los 50 nodos, alcanzas el tope de la capa gratuita enseguida. Y como no hay federación en el plan gratuito, quien gestiona varios clústeres de pronto tiene que tratar cada uno como una isla aislada.

Los costes de red son otro tema. Un ingeniero quería asignar costes de red entre zonas, pero Kubecost no podía distinguir el tráfico entre rangos de IP específicos, lo que impedía elaborar informes precisos en clústeres multi-AZ. En sus palabras, terminaba mostrando números «obvios», datos que no ayudaban a tomar mejores decisiones, y en ese punto pagar la versión enterprise no parecía justificado.

Otro equipo comentó que muchas de las métricas de Kubecost quedan bonitas pero aportan poca información útil. Parece una vista completa de los costes de tu clúster, pero algunos de los detalles más importantes, los necesarios para la atribución multinquilino, siguen exigiendo trabajo a medida.

Otra persona explicó que las actualizaciones eran un incordio cuando no se utilizaba Helm, sobre todo si habían sustituido el almacenamiento de métricas predeterminado de Kubecost. La herramienta les gustaba, pero mantenerla resultaba tedioso.

Y luego está el asunto evidente: Kubecost ahora pertenece a IBM. Varias empresas simplemente no pueden comprar productos de IBM por restricciones de proveedores. Otras comentaban que la presencia de IBM les genera cautela respecto al bloqueo de proveedor o la evolución de los precios a largo plazo.

Aun así, la idea que la gente repetía es que Kubecost está pulido y resulta práctico. La versión gratuita sirve para clústeres pequeños y la edición enterprise se encarece con rapidez, pero resuelve los problemas de escalado. A pesar de sus carencias, muchos equipos consideran que compensa antes que pelearse con OpenCost.

Cuando ambas opciones decepcionan, los equipos crean la suya

Resulta revelador que tantos ingenieros acaben levantando las manos y diciendo: «Simplemente creamos herramientas internas».

Algunos canalizan todo hacia Prometheus y montan paneles de Grafana con las métricas que de verdad les interesan. Otros recurren al autoescalado, al etiquetado a nivel de pod y a informes de uso cruzados con AWS o GCP.

Unos pocos equipos indicaron que los propios proveedores de nube empezaron a ofrecer mejores desgloses. Un ingeniero comentó que las herramientas nativas de GCP terminaron facilitando las vistas multinquilino que necesitaban sus usuarios, por lo que Kubecost pasó a ser innecesario.

Varios profesionales señalaron que combinan OpenCost con exportadores, paneles o automatización para aproximarse a números exactos. No es elegante, pero funciona. Si tienes un equipo de ingeniería de plataforma con disponibilidad, una solución propia te da justo lo que necesitas sin concesiones.

Si tu equipo es pequeño, tu clúster tiene mucha actividad o no tienes tiempo para reinventar la rueda, Kubecost suele terminar siendo la opción «menos frustrante», al menos hasta que llega la factura de la versión enterprise.

Kubernetes hace que todo sea difícil de medir

Es fácil culpar a las herramientas, pero parte de este desorden proviene del propio Kubernetes. Los clústeres aumentan y reducen su tamaño siguiendo patrones extraños. Los pods mueren y reaparecen sin cesar, y las cargas de trabajo saltan de un nodo a otro. Las instancias spot, la capacidad reservada, las clases de almacenamiento, los volúmenes efímeros y los nodos compartidos convierten la atribución de costes en un blanco móvil.

A todo eso se suman las redes multi-AZ, el tráfico local frente al tráfico entre zonas, distintos niveles de almacenamiento, modelos variables de créditos de CPU y llamadas internas entre servicios que los propios proveedores de nube apenas logran rastrear. Kubecost y OpenCost intentan cuantificar algo que es caótico por naturaleza, y gran parte de lo que se les critica procede precisamente de ahí.

La mayoría de los equipos no busca una precisión milimétrica. Solo quieren responder a estas preguntas sin pasarse dos días exportando archivos CSV:

1. ¿Qué cargas de trabajo están provocando los mayores cambios en los costes?
2. ¿Qué equipos consumen más recursos?
3. ¿Por qué subió tanto la factura del mes pasado?
4. ¿Quién está utilizando almacenamiento caro?
5. ¿Este clúster tiene el tamaño adecuado o está sobredimensionado?

Que tantos equipos sigan sin obtener respuestas claras dice mucho sobre el estado general de las herramientas de costes para Kubernetes.

¿Cuál deberías elegir?

Basándonos en lo que han vivido los equipos, la elección se resume de forma directa así.

Si tu clúster es pequeño o mediano

Kubecost (gratuito) es la opción menos frustrante. Obtendrás gráficos claros, una atribución razonable y una interfaz que no se caerá al sexto día.

Si tu clúster es grande o crítico para el negocio

Kubecost Enterprise es la única versión que escala con regularidad, pero tiene un precio que toma por sorpresa a algunos equipos.

Si buscas código abierto y no te importa crear paneles propios

OpenCost + Prometheus + Grafana funciona, pero prepárate para vigilarlo de cerca.

Si detestas ambas opciones

No estás solo. Muchos equipos construyen herramientas internas, recurren a exploradores de costes nativos de la nube o combinan fuentes de datos.

Si la visibilidad de red es importante

Ninguna de las dos herramientas gestiona el rastreo de red multi-AZ como a la gente le gustaría.

Si tienes una lista negra estricta de proveedores

Kubecost queda descartado para las empresas que no pueden contratar con IBM.

Dónde terminan la mayoría de los equipos

Los equipos empiezan con estas herramientas esperando conseguir claridad de una vez. El proceso a menudo se convierte en una extraña carrera de relevos entre ilusión, frustración, soluciones temporales y, finalmente, resignación; la mayoría de las empresas prefiere algo que funcione con suficiente solvencia antes que una solución perfecta.

Kubecost es el que funciona casi sin fricciones la mayor parte del tiempo. OpenCost resulta más fácil de adoptar, pero también se queda corto antes. Y Kubernetes sigue siendo esa capa intermedia caótica que complica todo el asunto más de lo debido.

Controlar los costes de Kubernetes no debería parecer una prueba de resistencia, pero para muchos equipos todavía lo es. Hasta que las herramientas evolucionen o las plataformas sean menos caóticas, las facturas seguirán llegando, los paneles seguirán fallando y la búsqueda de la herramienta adecuada continuará dando vueltas en círculos, porque lo único más confuso que Kubernetes es el coste de Kubernetes.