Repartir la factura de un clúster compartido para que los equipos se crean el número

La factura de la nube muestra una línea: un grupo de nodos. El clúster ejecuta catorce servicios de seis equipos. Finanzas pregunta qué equipo es responsable de la subida, y la respuesta honesta es que nadie lo sabe, así que el equipo de plataforma se queda con todo. Como el equipo de plataforma no puede cambiar ninguna de las cargas, el coste tiene un dueño que no puede actuar y unos actores que no tienen dueño.

Ese es el problema que resuelve la atribución de coste. Es menos un problema de herramienta que de modelo, porque la aritmética es fácil y la discusión sobre la aritmética no lo es.

Cómo llega el coste de un nodo a un pod

El mecanismo es el mismo en todas las herramientas. Coge el coste por hora del nodo según la tarifa del proveedor, incluido el descuento que aplique de verdad. Calcula la parte de CPU y memoria del nodo que corresponde a cada pod durante el tiempo que estuvo ahí. Multiplica.

Las herramientas se diferencian en acabado, no en principio. OpenCost es el proyecto de la fundación que implementa el modelo y exporta la atribución como métricas; es libre, es la implementación de referencia y basta para la mayoría de los equipos. Kubecost se construye sobre el mismo núcleo con un producto comercial alrededor, que añade retención, vistas multiclúster, recomendaciones y funciones de gobierno. Empieza con OpenCost y múdate si necesitas el producto de alrededor, no el número.

Los dos necesitan precios de nodo exactos para valer algo. Si tienes reservas, descuentos por uso comprometido o un plan de ahorro, el precio de catálogo exagera la factura de forma sustancial y todos los equipos van a descartar las cifras con razón. Mete las tarifas reales, o como mínimo una tarifa efectiva mezclada, antes de enseñarle a nadie el primer informe.

Peticiones o uso, y por qué la respuesta es peticiones

Esta es la decisión que da forma al comportamiento, y los equipos suelen equivocarse en el sentido.

Repartir por uso cobra a un equipo la CPU y la memoria que consumieron sus pods de verdad. Parece justo y es incorrecto, porque no refleja lo que el clúster tuvo que comprar. Un pod que pide cuatro núcleos y usa dos décimas obliga al planificador a reservar cuatro núcleos; el clúster los compró y alguien los pagó. Si repartes por uso, ese equipo paga dos décimas y todos los demás subvencionan la reserva.

Repartir por peticiones cobra por lo reservado, que es lo que de verdad determinó el número de nodos. Crea exactamente el incentivo correcto: un equipo baja su factura haciendo que sus peticiones se parezcan a la realidad, que es la misma acción que mejora la densidad del clúster.

El enfoque estándar es el máximo entre petición y uso, para que un equipo que pide de menos y luego dispara tampoco salga premiado. Informa de los dos números uno al lado del otro. La proporción entre ellos es la cifra más accionable que puedes entregarle a un equipo, y es el mismo número que está detrás de por qué un clúster de EKS cuesta el doble y de lo que cuesta AKS.

Los costes compartidos son donde ocurre la discusión

Entre la mitad y un tercio del coste de un clúster no es atribuible a los pods de ningún equipo, y cómo lo trates determina si la gente acepta el informe.

La bolsa compartida incluye la cuota del plano de control, el namespace de sistema, los DaemonSets de red y almacenamiento, los agentes de monitorización y de registro, el controlador de entrada y su balanceador, la malla de servicios si la tienes, el margen que reserva el autoescalador, y la diferencia entre lo que costaron los nodos y lo que pidieron los pods.

Cuatro formas de repartirlo, de menos a más discusión:

• Proporcional al coste directo de cada equipo. Simple, defendible, y lo que usamos por defecto.
• A partes iguales por equipo. Castiga a los equipos pequeños y empieza una pelea.
• Por número de pods o de namespaces. Premia meterlo todo en un solo despliegue.
• Sin atribuir, a cargo de la plataforma. Honesto, y significa que nadie tiene incentivo para reducirlo.

Elijas lo que elijas, muéstralo como una línea aparte en vez de mezclarlo en silencio. Un equipo que ve "tus cargas: 4.100, tu parte de plataforma: 900" acepta el segundo número. Un equipo que ve un solo número un 22 por ciento por encima de lo que esperaba discute el informe entero.

La capacidad ociosa merece también su propia línea. Si el clúster funciona al 45 por ciento de asignación, más de la mitad de la factura es margen, y eso es un hallazgo de plataforma, no de equipo.

Mostrar primero, y durante más tiempo del que crees

Mostrar significa que los equipos ven sus costes. Facturar internamente significa que el coste aterriza en su presupuesto. Ir directo a facturar es la forma más común de que esta iniciativa muera.

La razón es que los primeros meses de números están mal. Faltan etiquetas, los costes compartidos están mal modelados, a un equipo se le atribuye una carga que no es suya, el descuento no está aplicado. Todo eso tiene arreglo, y todo eso es letal para la confianza si llega pegado a una línea de presupuesto. En modo mostrar, un número equivocado es un informe de error. En modo facturar, es una acusación.

Mantén el modo mostrar hasta que los equipos dejen de discutir los números, lo que suele ser uno o dos trimestres. Después decide si facturar internamente añade algo. En muchas organizaciones no: la visibilidad más una conversación mensual producen el cambio de comportamiento, y la maquinaria contable interna es puro gasto.

Lo que sí funciona desde el principio es un informe semanal o mensual que llega al equipo, no un panel que tendrían que visitar. Incluye la tendencia, la proporción entre peticiones y uso, y las tres cargas más caras. Tres números, en su canal.

Las etiquetas son toda la base

La atribución es tan buena como los metadatos. Decide un conjunto pequeño y obligatorio de etiquetas, y hazlo cumplir.

Dueño, entorno, centro de coste y aplicación basta. Ponlas en los namespaces y deja que las cargas hereden, porque etiquetar pod a pod se desactualiza de inmediato. Hazlo cumplir con una política en modo auditoría primero, después avisando, después exigiendo, exactamente como en Kyverno o Gatekeeper.

Sigue el porcentaje de coste que cae en "sin atribuir" como tu métrica principal de calidad. Por encima del 10 por ciento, nadie se fía del informe. Bajarlo suele ser una quincena de trabajo de etiquetado y es lo más valioso que puedes hacer antes de comprar ninguna herramienta.

Los namespaces son la frontera natural de atribución, que es una razón más para dar uno a cada equipo, como en varios equipos en un clúster.

Lo que se olvida

• El almacenamiento y la red faltan en el modelo ingenuo. Los volúmenes persistentes son atribuibles por reclamación. El tráfico entre zonas normalmente no, y puede ser una línea grande.
• La mezcla de instancias interrumpibles y bajo demanda distorsiona la comparación. Dos equipos con cargas idénticas pagan distinto si uno cayó en nodos interrumpibles. Informa de la tarifa mezclada o explica la diferencia.
• Los pods de vida corta desaparecen. Un trabajo de integración continua que dura cuatro minutos es coste real. Asegúrate de que tu intervalo de recogida lo captura.
• La recomendación es lo importante. El coste por namespace es un número; "tus peticiones son 3,1 veces tu uso, esta es la cifra corregida" es una acción.
• Multiclúster necesita agregación. Los informes por clúster no le dicen a un equipo cuánto gasta en total, y los equipos suelen abarcar varios clústeres.

Qué hacer esta semana

Instala OpenCost, espera un día y saca el coste por namespace junto con la proporción entre peticiones y uso de cada uno. No se lo enseñes a nadie todavía. Mira primero el porcentaje sin atribuir: ese número te dice si tienes un problema de coste o un problema de etiquetado, y casi siempre es el segundo. Lo hacemos en la fase de costes de un proyecto cloud.