Coste del cloud: Kubernetes y platform engineering

Doce pods piden 2 núcleos de procesador (CPU) cada uno. El percentil 95 del uso real, el p95, es 0,22 núcleos. El planificador de Kubernetes empaqueta pods según la petición (request), no según el uso. Reservado: 24 núcleos. Trabajo: 2,6 núcleos. El autoscaler horizontal (Horizontal Pod Autoscaler, HPA) mira el porcentaje del request, ve holgura y no baja el número de réplicas. El Cluster Autoscaler añade otra máquina del mismo tipo, porque el hueco del nodo está ocupado por un request que nadie ha tocado desde la migración.

El coste del cloud no empieza por un descuento del proveedor. Empieza por quién, en platform engineering, puede cambiar el request, la familia de máquinas y la hora a la que se apaga un entorno que no es producción. Un limit demasiado bajo sube la latencia p99 (percentil 99) o mata el proceso por falta de memoria (out of memory, OOM). Un request bien recortado quita nodos que nadie usa.

Tres palabras que en un brief se funden en una línea:

• Platform engineering es el equipo que construye la plataforma interna: clúster, integración y entrega continuas (CI/CD), catálogo de servicios, presupuestos. Los equipos de producto no montan Kubernetes desde cero.
• FinOps (Financial Operations) es el ritmo en el que ingeniería y finanzas ven el coste de una unidad de trabajo, por ejemplo mil peticiones, y no solo la factura de fin de mes.
• Slack es la diferencia entre el limit o el request y el uso real. En Google, los trabajos configurados a mano tenían un 46% de slack. La automatización lo bajó al 23%.

1. Tres lazos que no ven el mismo número

En el clúster corren tres reguladores. Cada uno optimiza una variable distinta. Ninguno ve la factura por sí solo.

1. Request y limit en el pod. El request es una reserva para el planificador. El limit es un techo: por encima, la CPU se estrangula y la memoria acaba matando el proceso. Un request 4× por encima del p95 deja en el nodo un hueco donde no cabe el siguiente pod.
2. Número de réplicas (HPA). El HPA añade pods cuando el porcentaje del request cruza un objetivo, a menudo 50–80%. Si el request es 9× demasiado grande, el uso parece un 11%. El HPA duerme. O oscila, cuando el limit ahoga la CPU y la latencia sube antes de que la media «alcance».
3. Número de nodos (Cluster Autoscaler). El Cluster Autoscaler añade y quita máquinas de un pool definido. El pool es homogéneo: el tipo de instancia escrito en la infraestructura como código (Infrastructure as Code, IaC). Un pod que no cabe en el hueco libre despierta una máquina de la misma familia, aunque una familia más barata (más memoria, menos CPU) hubiera hecho el trabajo con un nodo.

El cuarto elemento no es un regulador. Es un calendario. Dev y staging del tamaño de producción, 24 horas al día, 7 días a la semana. El horario laboral de 8 a 19 son 55 horas de 168. El resto, unos dos tercios de la semana, es una factura por vacío.

resources:
  requests:
    cpu: "500m"       # reserva: el planificador y el HPA miran aquí
    memory: "512Mi"
  limits:
    cpu: "1500m"      # techo; por encima, la CPU se estrangula
    memory: "1Gi"     # por encima, el proceso muere (OOM)

El autoscaler vertical (Vertical Pod Autoscaler, VPA) puede reescribir el request. En modo automático reinicia pods. En memoria puede ocultar una fuga: la aplicación crece, el VPA sube el limit, el fallo sale del gráfico y se queda en la factura. Una recomendación de VPA sin compuerta no es un despliegue.

Las herramientas que eligen el tipo de máquina para pods pendientes (en Amazon Web Services es Karpenter; en otras nubes, node auto-provisioning) rodean el límite del pool homogéneo. No sustituyen el right-sizing del request. Empaquetan lo que los pods piden. Si piden 9× de más, Karpenter compra un empaquetado más limpio del mismo hueco, no cero hueco.

La factura de la unidad gráfica (GPU) y del entrenamiento del modelo es otro lazo: detección de deriva y reentrenamiento, no el empaquetado de nodos. Lo escribimos aparte en el artículo sobre servicios MLOps. Meter ambos encargos en un «DevOps que hace de todo» produce una guardia. No produce FinOps ni reentrenamiento.

2. Qué miden de verdad los trabajos

Una diapositiva de «ahorraremos un 40%» no dice sobre qué montaje ni contra qué base. Cuatro fuentes miden cosas distintas. Sepárelas antes de escribir un porcentaje en un contrato.

• Slack manual 46%, automático 23%. Rzadca, Findeisen, Świderski y otros, Autopilot: Workload Autoscaling at Google (EuroSys 2020). Autopilot fija la escala horizontal (número de tareas) y la vertical (CPU y memoria) a partir del historial. El slack baja del 46% en configuración manual al 23%. El número de tareas muy golpeadas por OOM baja unas 10 veces. En el momento de la publicación, Autopilot cubría más del 48% del uso de recursos de la flota de Google. Eso es Borg, el sistema interno de Google, no un producto para instalar en EKS (Elastic Kubernetes Service). Lo que se traslada es la mecánica: vertical y horizontal juntos, sobre el historial, con el objetivo «menos slack, sin OOM y sin estrangular la CPU».
• Máquinas iguales y una actualización rompen el patrón. Hua, Yang, Qian y otros, Humas (arXiv:2406.15769, 2024). Experimento con 50 microservicios reales y más de 11 000 contenedores. Frente a métodos tratados como estado del arte, Humas mejora la eficiencia de recursos en torno a un 30,4% y la estabilidad en torno a un 48,0%. En la tabla, el slack de las trazas en bruto es 52,87%, en una reimplementación de Autopilot 16,63%, en Humas 11,58%. La asignación media de CPU baja en torno a un 46,8% frente a las trazas en bruto. Aparte: tras una versión nueva, el patrón de uso cambia (deriva de patrón). Un autoscaler entrenado en la versión vieja vuelve a fallar. No es el mismo 23% de Rzadca. Otra traza, otro número.
• Un umbral de CPU por servicio no ve la latencia de extremo a extremo. Sachidananda y Sivaraman, Collective Autoscaling for Cloud Microservices (COLA, arXiv:2112.14845). Cada microservicio escalado solo por un umbral de CPU no sabe que la latencia del usuario es la suma de varios servicios. En Google Kubernetes Engine (GKE), en modo estándar y Autopilot, COLA cumple un objetivo de latencia mediana o de cola en 53 de 63 cargas y entonces es de media un 19,3% más barato que el siguiente autoscaler que también cumple ese objetivo. Es el más barato en 48 de esos 53. En aplicaciones pequeñas, cuyas configuraciones se pueden enumerar, es óptimo en el 90% de los casos. Los autores escriben que el ahorro paga el coste de entrenamiento en unos días. Es su montaje, no una promesa sobre su factura.
• El Cluster Autoscaler no cambia la familia de máquinas. Boghani, Kirimlioglu, Moturi y Tso, Cloud Resource Allocation with Convex Optimization (arXiv:2503.21096, 2025). El Cluster Autoscaler sube y baja pools de instancias idénticas. No elige una mezcla de tipos. El trabajo compara una optimización convexa con ese autoscaler en una simulación (Python, mediana de cinco pasadas), no en una factura de AWS. Escenario 1, aplicación web sencilla desde cero: no hay diferencia relevante. Basta un autoscaler estándar. Escenario 2, ampliar infraestructura existente: un 42,5% más barato (0,12 USD/h frente a 0,07 USD/h). Escenarios 3 a 5: 80,5%, 87,2% y 71,1%. Media de cinco: 56,3%. Carga de memoria (escenario 4): de 1,08 USD/h a 0,14 USD/h. Un sobreaprovisionamiento del orden de miles por ciento aparece en el escenario que solo permite instancias pequeñas. No es una factura típica. Es la prueba de que la familia equivocada multiplica nodos.
• Un VPA sin compuerta de fuga compra memoria para un fallo. Karakaya, Şengül y Kaplan, Safety-Gated Autoscaling (arXiv:2607.26503, 29 de julio de 2026). Un detector de fuga de memoria (regresión lineal, R²) bloquea la recomendación en lugar de agrandar un contenedor roto. En un GKE en vivo, el ahorro del 20–40% es una proyección de «qué pasaría si», no una factura medida. El detector acierta un 83%. Batería de pruebas: 1118, cobertura 80,3%. Hay modo dry-run y aprobación humana. Cite el 20–40% solo con esa reserva.

3. Ejemplo numérico: 24 núcleos reservados, 2,6 en uso

Las cifras de los artículos no se trasladan 1:1 a su factura. El orden sí: primero el request, luego el tipo de máquina, luego apagar lo que no atiende tráfico. Empezar por Karpenter con requests de 2000m y un uso de 220m compra un empaquetado más bonito del mismo hueco.

4. Tabla de decisión

DevOps / SRE / cloud: tarifa del especialista 140–200 PLN/h, tarifa para el cliente 200–325 PLN/h. Margen del proveedor 10–25%. Es un mapa de mercado, no una oferta. El desglose: cuánto cuesta el body leasing IT en 2026. No Fluff Jobs da para el primer trimestre de 2026 bandas B2B de un especialista DevOps de 23,5–28,5 mil PLN. Es su factura, no el precio que paga el cliente.

5. Anti-patrones que no están en el tutorial de HPA

1. HPA al 80% de un request que es 4× demasiado grande. El autoscaler ve ociosidad. Los nodos se quedan. El panel de «uso del clúster» muestra un 20% y nadie lo une al manifiesto.
2. VPA en modo auto sobre memoria, sin detector de fuga. La recomendación crece con el fallo. El incidente de OOM desaparece. La factura no. El dry-run existe para que una persona vea la tendencia antes de que el limit suba.
3. Cuatro pools «por si acaso» y un Cluster Autoscaler que solo sabe añadir el mismo tipo. Boghani: en una aplicación sencilla desde cero no hay ganancia. La ganancia está donde la forma de los pods no coincide con la familia escrita en Terraform hace dos años.
4. FinOps como PDF y un DevOps al 20% de una jornada. CI/CD, guardia, coste, Kubernetes y además GPU. Una persona en cinco lazos no cierra ninguno. Una herramienta de coste en solo lectura, sin derecho a cambiar un request, es un PDF más caro.

6. Playbook: a quién alquilar y en qué orden

No empiece por otro clúster. Empiece por la pregunta de qué lazo sostiene la factura: el request, el tipo de máquina, los entornos que no son producción o la GPU.

1. El clúster, la identidad (IAM, identity and access management) y Terraform ya están. Falta un dueño de los requests, del presupuesto del namespace y de la revisión semanal. Eso es el body leasing de un ingeniero DevOps clásico: una persona, su reunión diaria, su definición de hecho. Body leasing aquí significa alquilar un especialista dentro de su equipo, normalmente por tiempo (time and materials, T&M). No vendemos un banquillo con nombre para el lunes por la mañana.
2. Nadie es dueño del clúster. Cuatro cuentas, sin IaC, dev del tamaño de producción, manifiestos con un request copiado de un tutorial. Una persona no cose eso en un sprint. Un equipo de plataforma: alguien del clúster y del IaC, alguien de CI/CD, alguien con derecho a decir «este namespace se apaga a las 19». Eso está más cerca del leasing de equipos IT que de «compramos otro DevOps». Cuándo un equipo y cuándo un rol: team leasing frente a body leasing 2026.
3. Los datos y el kubeconfig no salen a un portátil. El contratista trabaja en su IAM y en su nube, con acuerdo de confidencialidad (NDA) y encargo de tratamiento. Exportar un kubeconfig «para calcular requests más rápido» es acceso a producción. Cláusulas: contratos, márgenes, derechos de autor.
4. Puesta en marcha. Una persona en un equipo existente: primeros perfiles en días, inicio tras sus entrevistas y el contrato. Un equipo desde cero: semanas, porque se cosen permisos y una definición de hecho para cambiar un request en producción. La promesa de «tres séniores de plataforma desde el lunes» es un CV o un banquillo que no tenemos.

Commoditech hace T&M y contratación fija desde Varsovia desde 2012. En la red hay más de 80 especialistas. No los tenemos parados en un banquillo. Un brief de body leasing o de contratación (honorarios de éxito, sin contratación no hay honorarios) también se deja desde el editor, por MCP para agentes de IA (Model Context Protocol, el protocolo con el que un asistente en el IDE llama a herramientas). Una persona pone el precio del stack concreto. Las bandas están en el artículo de tarifas, no en una respuesta automática. Contacto: el formulario.

FAQ

Fuentes

• Rzadca, K., Findeisen, P., Świderski, J. et al. (2020). Autopilot: Workload Autoscaling at Google. EuroSys 2020. doi.org/10.1145/3342195.3387524. research.google.
• Hua, Q., Yang, D., Qian, S., Cao, J., Xue, G., Li, M. (2024). Humas. arXiv:2406.15769. arxiv.org/abs/2406.15769.
• Sachidananda, V., Sivaraman, A. (2022). Collective Autoscaling for Cloud Microservices. arXiv:2112.14845. arxiv.org/abs/2112.14845.
• Boghani, S., Kirimlioglu, E., Moturi, A., Tso, H.-T. (2025). Cloud Resource Allocation with Convex Optimization. arXiv:2503.21096. arxiv.org/abs/2503.21096.
• Karakaya, A., Şengül, E., Kaplan, A. (2026). Safety-Gated Autoscaling. arXiv:2607.26503. arxiv.org/abs/2607.26503.
• Commoditech — tarifas de body leasing 2026, ingenieros DevOps, team leasing frente a body leasing.