En casi todos los clusters que he auditado, el mayor desperdicio no está en un nodo carísimo: está en decenas de decisiones pequeñas. Requests inflados «por si acaso», réplicas que nadie revisa, entornos de desarrollo encendidos 24/7 y volúmenes huérfanos.
FinOps no es un proyecto de finanzas. Es una práctica de ingeniería.
Visibilidad: sin etiquetas no hay conversación
No puedes asignar costos si no sabes a quién pertenecen. El mínimo viable:
metadata:
labels:
app.kubernetes.io/name: pagos
app.kubernetes.io/part-of: checkout
owner: equipo-pagos
environment: production
cost-center: "fintech-core"Con esas etiquetas puedes responder: ¿cuánto cuesta el equipo de pagos? ¿cuánto el entorno de staging? ¿qué servicio creció este mes?
Asignación: requests versus realidad
Kubernetes programa en función de los requests, no del consumo real. Si pides 2 CPU y usas 0.3, estás pagando capacidad que nadie aprovecha.
resources:
requests:
cpu: 300m
memory: 512Mi
limits:
memory: 768MiRecomendaciones:
- Usa datos históricos de consumo (VPA en modo recomendación, métricas de Prometheus).
- Separa requests de limits; no pongas el mismo valor por reflejo.
- Revisa memory limits con cuidado: OOMKilled es peor que un poco de sobreasignación.
- Mide el impacto de cada cambio en latencia y errores.
Optimización con impacto
| Palanca | Impacto típico | Riesgo |
|---|---|---|
| Rightsizing de requests | Alto | Bajo si se mide |
| Autoscaling horizontal | Medio-alto | Configuración de métricas |
| Nodos spot para workloads tolerantes | Alto | Interrupciones |
| Apagar entornos no productivos | Medio | Fricción para equipos |
| Reservas / savings plans | Alto | Compromiso de largo plazo |
| Limpieza de volúmenes e IPs | Bajo-medio | Requiere inventario |
No todas las palancas aplican al mismo tiempo. Prioriza las que no sacrifican experiencia de desarrollo ni confiabilidad.
Cultura: guardrails, no sermones
Un dashboard que nadie mira no cambia comportamientos. Lo que sí funciona:
- Presupuestos por equipo con alertas tempranas.
- Revisión mensual de costo por servicio en la ceremonia del equipo.
- Etiquetas obligatorias en el pipeline, no como recomendación.
- Un owner claro para cada workload.
- Un proceso para apagar lo que no tiene dueño.
La conversación cambia cuando el costo se trata como una métrica de ingeniería, igual que la latencia o la tasa de errores.
Un plan de 30 días
- Semana 1: etiquetas, inventario y mapa de owners.
- Semana 2: costo por namespace y por servicio.
- Semana 3: rightsizing de los 10 workloads más caros.
- Semana 4: guardrails, presupuestos y revisión con equipos.
La meta no es gastar menos por gastar menos. Es gastar mejor: capacidad alineada con valor, decisiones visibles y equipos que entienden el costo de lo que operan.