Kubecost y OpenCost: FinOps nativo en Kubernetes

Actualizado: 2026-05-03

OpenCost^[1] (sandbox de CNCF) y Kubecost^[2] (su versión comercial) resuelven el problema básico de Kubernetes: “¿cuánto cuesta exactamente cada namespace?”. Las facturas de AWS, GCP o Azure agrupan por recurso y tag de nube, no por workload K8s. Kubecost mapea el billing de cualquier cloud a los constructos nativos de Kubernetes — pods, deployments, namespaces, labels — dando por fin visibilidad de coste real al nivel donde los equipos toman decisiones.

Puntos clave

• La precisión típica de asignación de costes es del 85-95 % frente a la factura real — suficiente para la mayoría de decisiones de optimización.
• El ROI es claro para clústeres con gasto superior a 5.000 USD/mes: los ahorros identificados suelen superar el coste del software en el primer mes.
• OpenCost (Apache 2.0) cubre los esenciales de forma gratuita; Kubecost Business+ añade multi-clúster y billing avanzado.
• La transparencia de costes por equipo (showback) cambia el comportamiento de ingeniería más rápido que cualquier política de recursos.
• La precisión tiene límites: red, servicios compartidos como Redis y nodos spot/reservados siguen siendo áreas de fricción.

Qué ofrecen

• Asignación de costes: por pod, namespace, label, deployment.
• Recomendaciones de optimización: rightsizing, spot, workloads abandonados.
• Integración de billing cloud: AWS CUR, GCP Billing Export, Azure Cost Management.
• Showback/Chargeback: reportes internos de coste por equipo.
• Forecasting: predicciones de gasto.
• Alerting: notificaciones de presupuesto superado.

OpenCost vs Kubecost

OpenCost cubre los esenciales de forma gratuita. Kubecost añade las features enterprise.

Instalación con Helm

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm install opencost opencost/opencost

# O Kubecost
helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm install kubecost kubecost/cost-analyzer 
  --set kubecostToken="your-token"

El despliegue requiere:

• Prometheus scraping activo.
• Permisos IAM en cloud para las APIs de billing.

Precisión de la asignación de costes

La precisión depende de varios factores:

• Resolución de datos Prometheus: intervalos de 5 minutos son suficientes.
• Integración CSV/billing: más preciso que solo métricas.
• Datos históricos: normalmente 15-30 días.
• Distribución de coste idle: cómo se reparte el coste de nodos subutilizados.

Precisión típica: 85-95 % frente a la factura real. Suficiente para la mayoría de decisiones de optimización.

Recomendaciones de optimización

Kubecost sugiere acciones concretas:

• Rightsizing: reducir requests de pods sobreaprovisionados.
• Spot instances: cargas tolerantes a interrupciones.
• Reserved instances: cargas estables de larga duración.
• Workloads abandonados: deployments sin tráfico.
• Pods con problemas: consumiendo recursos sin aportar valor.

Ahorros típicos identificados en el primer mes: 20-40 % del gasto K8s. El mismo análisis FinOps descrito en FinOps: control de coste en la nube aplica específicamente a K8s con estas herramientas.

Showback interno: el cambio cultural

El showback — mostrar a cada equipo cuánto cuesta su namespace — es la feature con mayor impacto cultural:

Equipo Frontend
  - namespace: frontend-prod: 1.230 USD/mes
  - namespace: frontend-staging: 180 USD/mes
  - total: 1.410 USD

Equipo Backend
  - namespace: api-prod: 3.450 USD/mes
  - namespace: workers: 890 USD/mes
  - total: 4.340 USD

La transparencia de costes incentiva la eficiencia de forma orgánica. Cuando un equipo ve que su namespace de staging consume 180 USD al mes porque nadie lo apaga los fines de semana, lo arregla. Sin visibilidad, esa conversación nunca ocurre.

Integración con cloud billing

AWS

• Cost and Usage Report (CUR) en S3.
• IAM role con ce:GetCostAndUsage.
• Pricing de RDS, EKS, ELB incluido.

GCP

• Billing Export a BigQuery.
• Service account con billing.viewer.

Azure

• Cost Management Export.
• Service principal con rol billing reader.

Setup típico de unas horas por cloud.

Workflow de optimización

1. Baseline: medir el coste actual mensual por namespace.
2. Identificar top spenders: Pareto — el 20 % de workloads suele representar el 80 % del coste.
3. Rightsizing: optimizar requests de CPU/memoria.
4. Políticas: aplicar LimitRange y ResourceQuota. Ver Kubernetes 1.31 para el impacto del scheduler en la utilización real.
5. Estrategia spot: mover workloads tolerantes a nodos spot.
6. Monitorizar ahorros: tendencia continua.

Proceso iterativo mensual-trimestral.

Alerting de presupuesto

alerts:
  - name: namespace-over-budget
    type: budget
    namespace: production
    threshold: 5000  # 5.000 USD/mes
    window: 30d
    recipients:
      - slack:devops
      - email:finance@company.com

Limitaciones honestas

• Coste de red: la atribución de ingress/egress es difícil.
• Servicios compartidos: ¿cómo asignar el coste de un Redis compartido entre tres equipos?
• Gaps de precisión con spot/reservaciones.
• Curva de aprendizaje de la UI: no es trivial para equipos sin experiencia FinOps.

Conclusión

Kubecost y OpenCost transforman el gasto en Kubernetes de una caja negra en un coste gestionado. Para clústeres con más de 5.000 USD/mes, el ROI es claro: los ahorros identificados suelen superar el coste del software. OpenCost cubre los esenciales de forma gratuita; Kubecost Business+ vale la pena para features multi-clúster y billing cloud avanzado. La implementación es un día de setup más semanas iterando sobre las recomendaciones. Para FinOps serio en K8s, estas herramientas son fundamentales.

1. OpenCost
2. Kubecost