Asignación de Costos en Kubernetes: Una Guía Práctica para EKS, AKS y GKE

Tienes 12 microservicios corriendo en 3 namespaces dentro de un clúster EKS compartido. Finanzas pregunta: "¿Cuánto nos cuesta la carga de trabajo del Equipo Alpha?" Abres tu factura cloud. Muestra una sola línea: $14,200/mes por el clúster EKS. Sin desglose por equipo, servicio ni namespace.

Este es el problema de la asignación de costos en Kubernetes. Y afecta a toda organización que opera clústeres compartidos en producción.

Por Qué Es Difícil Asignar Costos en K8s

A diferencia de las VMs tradicionales, donde una instancia corresponde a una carga de trabajo, Kubernetes está diseñado para compartir recursos. Pods de distintos equipos corren en los mismos nodos, comparten los mismos núcleos de CPU y consumen memoria de un pool común.

Esto crea tres desafíos fundamentales:

• Nodos de cómputo compartidos: Una sola instancia EC2 (o VM de Azure, o instancia GCE) puede ejecutar pods de 5 equipos distintos. La factura cloud solo muestra el costo del nodo.
• Requests vs uso real: Los equipos solicitan CPU y memoria en las specs de sus pods, pero el consumo real puede ser mucho menor (o mayor durante ráfagas). ¿Cobras por lo que reservaron o por lo que usaron?
• Overhead del clúster: Los namespaces de sistema (kube-system, monitoreo, ingress controllers) consumen recursos reales pero no pertenecen a ningún equipo de negocio. Alguien tiene que absorber ese costo.

Seguimiento de Costos por Namespace

El punto de partida más común es la asignación basada en namespaces. Cada equipo recibe un namespace, y los costos se reparten según los recursos consumidos dentro de él.

El enfoque funciona así:

1. Calcula el costo total de todos los nodos del clúster para un período determinado
2. Para cada namespace, suma la CPU y la memoria consumidas (o solicitadas) por todos sus pods
3. Divide el consumo de recursos del namespace entre el total del clúster para obtener un porcentaje
4. Aplica ese porcentaje al costo total del clúster

Es simple y fácil de explicar a finanzas. Pero se rompe cuando los namespaces tienen perfiles de recursos muy distintos — un namespace con cargas intensivas en memoria subsidia a otro intensivo en CPU si solo mides una dimensión.

Asignación Proporcional por CPU/Memoria

Un enfoque más preciso pondera CPU y memoria por separado. Esta es la fórmula:

Costo del namespace = (proporción de CPU x costo de CPU) + (proporción de memoria x costo de memoria)

Para dividir el costo del nodo en sus componentes de CPU y memoria, usa la relación de precios on-demand entre tipos de instancia equivalentes optimizados para cómputo y para memoria en tu proveedor. Por ejemplo, en AWS, compara el precio de c6i (optimizada para cómputo) contra el de r6i (optimizada para memoria) para derivar el peso relativo de CPU vs memoria.

Este enfoque es más justo, pero requiere mantener tablas de precios y actualizarlas cuando cambian los tipos de instancia.

Chargeback vs Showback

Una vez que puedes asignar costos, la pregunta es: ¿qué haces con los datos?

Showback significa que los equipos ven sus costos pero no son financieramente responsables. Es un ejercicio de visibilidad. Los equipos reciben dashboards, quizá un email semanal. El objetivo es la consciencia — "gastaste $3,200 el mes pasado en tu namespace de staging."

Chargeback significa que los costos se transfieren a los presupuestos de cada equipo. Los engineering managers tienen un presupuesto cloud, y sus costos de K8s cuentan contra él. Esto crea un incentivo financiero directo para optimizar.

La mayoría de las organizaciones deberían empezar con showback. El chargeback exige una asignación precisa (que toma tiempo afinar), respaldo organizacional y un proceso de resolución de disputas para cuando los equipos no estén de acuerdo con sus cargos.

Comparación de Estrategias

Errores Comunes

Después de trabajar con equipos que operan K8s a escala en AWS, Azure y GCP, estos son los errores de asignación que más vemos:

1. Ignorar la capacidad ociosa. Si un clúster está al 40% de utilización, el 60% del costo es capacidad ociosa. ¿Quién la paga? Si asignas solo según el uso, el costo total asignado no cuadrará con la factura. La mayoría de los equipos añaden un "impuesto de ociosidad" — distribuyendo el costo no asignado proporcionalmente entre todos los namespaces.

2. Olvidar los namespaces de sistema. kube-system, cert-manager, istio-system, monitoreo — consumen recursos reales. Deben asignarse como overhead compartido, no ignorarse.

3. Ceguera ante los DaemonSets. Los DaemonSets ejecutan un pod por nodo sin importar el namespace. Un agente de logging que consume 500Mi de memoria en cada nodo es un costo de todo el clúster, no atribuible a un solo equipo.

4. La complejidad de las instancias spot. Si algunos nodos son instancias spot con 70% de descuento y otros son on-demand, el costo de un namespace depende de en qué nodos aterrizaron sus pods. La mayoría de los modelos de asignación ignoran esto por completo.

5. Tráfico entre namespaces. El Servicio A en namespace-alpha llama al Servicio B en namespace-beta 10,000 veces por hora. La CPU que consume el Servicio B para atender esas peticiones la genera el Servicio A. La asignación pura por namespace pierde esta dependencia.

Para una mirada más profunda a cómo los patrones de carga afectan las decisiones de costos, revisa nuestra guía sobre los 6 patrones de picos de CPU que todo equipo FinOps debería conocer.

Cómo Lo Maneja CLARITY

La asignación de costos de Kubernetes de CLARITY funciona en EKS, AKS y GKE con un modelo unificado:

• Descubrimiento automático de namespaces: CLARITY inventaría todos los namespaces y mapea los pods a equipos usando labels y annotations
• Ponderación de doble dimensión: CPU y memoria se ponderan por separado usando precios cloud en tiempo real para los tipos de instancia de tus node pools
• Distribución del costo ocioso: La capacidad no asignada se presenta por separado y puede distribuirse proporcionalmente o asignarse a un centro de costo compartido
• Manejo de namespaces de sistema: El overhead del clúster (kube-system, DaemonSets, control plane) se identifica automáticamente y se asigna como costo de infraestructura compartida
• Asignación consciente de spot: Cuando los nodos usan precios mixtos (on-demand, spot, reservados), CLARITY rastrea qué pods corrieron en qué tipos de nodo y ajusta el costo en consecuencia

Todos los datos de asignación alimentan el análisis con IA de CLARITY, así que las recomendaciones consideran tanto la estructura de costos como los patrones de picos de uso de cada namespace.

Próximos Pasos

Si recién estás empezando con la asignación de costos en K8s:

1. Empieza con showback a nivel de namespace. Consigue visibilidad antes de exigir responsabilidad.
2. Establece estándares de etiquetado. Exige labels de equipo, entorno y servicio en todos los deployments. No puedes asignar lo que no puedes identificar.
3. Contabiliza la capacidad ociosa. Si tu asignación no suma el 100% de la factura, tienes una brecha que erosionará la confianza en los números.
4. Automatízalo. La asignación manual en hojas de cálculo no escala. Usa una plataforma que extraiga los datos de tus APIs cloud y de las métricas de K8s automáticamente.

Lectura relacionada: Entender los patrones de picos de CPU es crítico para un rightsizing preciso en K8s — los picos de despliegue lucen idénticos a la presión genuina en las métricas crudas. Para el panorama completo de por qué importa la precisión de los datos de costos en todos los proveedores, lee Multi-Cloud Cost Management: Why 99.7% Accuracy Matters.