Visibilidad de costos de Kubernetes con Kubecost y VPA
No se puede optimizar lo que no se puede ver. Así fue como construí visibilidad de costos en Kubernetes con Kubecost, hice rightsizing de los workloads con el Vertical Pod Autoscaler y consolidé los node pools para reducir la cantidad de nodes en cerca del 20%.
La asignación de costos orienta los resource requests y la consolidación; los ahorros necesitan un baseline de facturación.
Contribución de un vistazo
- Mi responsabilidad
- Despliegue de Kubecost, integración de facturación y visibilidad de la asignación por workload.
- Alcance
- Infraestructura de asignación de costos en sandbox y producción.
- Colaboración y límites
- Hice visible el costo y el uso de recursos para respaldar las decisiones sobre los workloads; la visibilidad es distinta de la adopción o los ahorros verificados.
- Resultado
- Información de asignación por namespace/módulo y de rightsizing; los ahorros resultantes requieren su propio baseline de facturación.
El costo de Kubernetes es célebremente opaco. La factura de la nube llega como un único número, pero se reparte entre namespaces, equipos y workloads que comparten los mismos nodes, y nadie puede decir cuánto cuesta realmente cada cosa. FinOps empieza por corregir eso: hacer visible el costo por workload y luego actuar sobre lo que se ve.
Paso 1: visibilidad de costos con Kubecost
Desplegué Kubecost en los clusters de sandbox y producción, conectado a la exportación de facturación de la nube (vía BigQuery) para que sus números se concilien con la factura real en lugar de estimarla. Algunas decisiones que lo hicieron perdurar:
- Prometheus independiente. Dejé que Kubecost ejecutara su propia pila de métricas en lugar de acoplarse al Prometheus existente. Más rápido de desplegar y con recolección de métricas garantizada, sin conexiones frágiles entre servicios.
- Ingress interno con TLS. Accesible para el equipo, no desde internet.
- Asignación por módulo. Configuré etiquetas de asignación de costos para que la factura se desglose por módulo y equipo, no solo por namespace.
El beneficio es inmediato: costo en tiempo real por namespace y deployment, utilización frente a asignación, recomendaciones de rightsizing y conciliación de facturación contra la factura real de la nube.
Paso 2: rightsizing con el Vertical Pod Autoscaler
La visibilidad mostró la historia de siempre: workloads que solicitan mucha más CPU y memoria de la que llegan a usar. Implementé el Vertical Pod Autoscaler (VPA) en los entornos de no producción para que los requests sigan el uso real en lugar de la conjetura cautelosa que alguien hizo hace un año. Una advertencia que vale la pena compartir: VPA no está libre de casos límite. En un servicio ávido de memoria interactuó mal con el comportamiento de OOM, así que retiré VPA de ese workload específico en lugar de dejar que peleara con el pod. El rightsizing es un valor por defecto, no una religión.
Paso 3: consolidación
Con datos reales de utilización, resultó que muchos nodes cargaban pods casi inactivos. Consolidé los workloads en node pools compartidos para que el scheduler pudiera hacer bin-pack correctamente, lo que redujo la cantidad de nodes en cerca del 20% en todos los entornos sin impacto en los workloads.
Paso 4: conviértelo en un hábito, no en un proyecto
Los ahorros puntuales se erosionan. La práctica es lo que mantiene la factura baja:
- Vigilancia diaria del costo. El hábito permanente de revisar los reportes de costos e investigar cualquier pico el mismo día, mientras la causa todavía está fresca.
- Revisión de uso comprometido. Analicé la flota de cómputo en estado estable para la cobertura de descuentos por uso comprometido, de modo que el baseline que siempre está en ejecución sea también el baseline por el que menos pagas.
- El análisis de costos guía las decisiones. Establecí el baseline del costo de workloads específicos para que dar de baja uno viniera con un ahorro medido y validado, no con una conjetura optimista.
FinOps es un ciclo, no una limpieza
Ve el costo por workload, haz rightsizing según el uso real, consolida lo que está inactivo y luego vigila la deriva y repite. Las herramientas (Kubecost, VPA, exportación de facturación) existen para que ese ciclo sea barato de ejecutar, de modo que los ahorros se acumulen en lugar de erosionarse.
Lo que le diría a alguien que empieza con esto
- Compra visibilidad primero. La asignación de costos por namespace, conciliada con la factura real, es la base sobre la que se apoya todo lo demás.
- Haz rightsizing con VPA, pero mantenlo vigilado. Es el valor por defecto correcto; no es el adecuado para todos los workloads (especialmente los servicios sensibles a la memoria).
- Consolida con evidencia. Los datos reales de utilización convierten un «quizás estamos sobreaprovisionados» en un recorte de la cantidad de nodes concreto y seguro.
- Convierte el costo en un vistazo diario, no en un simulacro de incendio trimestral. Los picos son más baratos de corregir el día en que ocurren.
Decisiones y próximos pasos
Una mirada retrospectiva al enfoque y sus límites. La próxima mejora es una propuesta, no un resultado entregado.
Alternativa y justificación
Una pila de métricas dedicada simplifica la recolección inicial; reutilizar una pila compartida puede reducir la duplicación pero introduce acoplamiento.
Contrapartida
La asignación es un modelo de atribución. Los recursos compartidos y las etiquetas afectan cómo se asignan los costos a los equipos.
Lo que mejoraría a continuación
Próxima mejora: conciliar la cobertura de asignación y medir qué recomendaciones adoptan los equipos antes de afirmar un impacto de optimización.