Cloud Edición diaria
CLOUD KUBERNETES Y PLATAFORMAS
GKE 1.37 lleva el escalado a cero al HPA y traslada el coste al arranque
Google ha integrado en GKE 1.37 el escalado de cargas a cero mediante HPA, métricas externas y el recurso AutoscalingMetric, reduciendo la dependencia de operadores adicionales. La réplica ociosa desaparece, pero la factura y la latencia no: métricas, clúster, imágenes y capacidad de reserva siguen formando parte de la arquitectura.
Google ha incorporado a GKE 1.37 una vía nativa para que el Horizontal Pod Autoscaler reduzca un `Deployment` a cero réplicas y vuelva a activarlo cuando reaparece demanda. Hasta ahora, muchas plataformas recurrían a KEDA u otros adaptadores para convertir colas y eventos en decisiones de escalado. La nueva ruta utiliza `autoscaling/v2`, un recurso `AutoscalingMetric` y métricas externas u objeto procedentes de Cloud Monitoring o Google Managed Service for Prometheus. El cambio simplifica una parte del plano de control, pero no elimina la ingeniería que conecta una señal de negocio con capacidad disponible.
La limitación fundamental es física: cuando no hay pods, tampoco existen métricas de CPU o memoria que permitan despertarlos. Por eso GKE exige una señal externa, como mensajes pendientes en Pub/Sub, peticiones observadas por un balanceador o una medida equivalente. El `AutoscalingMetric`, el HPA y la carga objetivo deben vivir en el mismo espacio de nombres. Esta proximidad reduce ambigüedad, aunque obliga a gobernar nombres, permisos y ciclo de vida juntos. Una métrica ausente, atrasada o mal etiquetada puede dejar el servicio a cero o multiplicar réplicas sin que haya trabajo útil.
Google presenta la integración como una alternativa con menos componentes que KEDA. Es una ventaja operativa real para quien ya concentra observabilidad en su plataforma, pero no convierte toda migración en obligatoria. KEDA mantiene un ecosistema amplio de escaladores y puede seguir siendo adecuado para señales o nubes distintas. La comparación debe medir tiempo de reacción, disponibilidad de la métrica, carga del plano de control, esfuerzo de actualización y posibilidad de volver atrás. Sustituir miles de líneas de configuración por un servicio gestionado sólo ahorra si las capacidades necesarias están cubiertas.
Ahorrar una réplica obliga a diseñar la señal que despierta el servicio y el tiempo que tarda
El problema aparece al pasar de cero a uno. Si el clúster necesita crear un nodo, descargar una imagen y arrancar la aplicación, el usuario paga el ahorro con espera. Google propone `CapacityBuffer`: capacidad activa preparada para aceptar pods y capacidad en espera que puede reanudarse para rellenar el colchón. Un buffer compartido permite que muchas cargas intermitentes renuncien a su réplica permanente. Sin embargo, esa reserva también tiene coste. La promesa de «cero» describe el workload detenido, no una factura total de cero euros.
La economía debe incluir gestión del clúster, nodos base, observabilidad, almacenamiento, tráfico, imágenes y el propio buffer, además del cómputo que aparece durante los picos. Una carga con diez minutos de actividad al día puede beneficiarse mucho; una API interactiva con latencia estricta quizá necesite una réplica mínima o un buffer activo mayor. El cálculo útil es coste por trabajo completado junto con percentiles de arranque, no el número medio de pods. Mantener capacidad caliente para cada servicio reproduce el gasto que se pretendía evitar; compartirla exige cuotas y prioridades.
También hay riesgos de operación. Un mensaje venenoso puede activar y derribar repetidamente workers; una ráfaga puede agotar cuotas antes de que el buffer se reponga; y un despliegue con una imagen enorme puede seguir tardando aunque el nodo exista. La documentación advierte además que, antes de bajar nodos o plano de control a una versión anterior a 1.37, hay que devolver `minReplicas` a uno o más, porque una versión antigua puede dejar la carga atrapada en cero. El cambio de versión forma parte del diseño de recuperación.
La adopción sensata empieza con un proceso asíncrono y reversible. Se registra la profundidad de la cola, el momento en que HPA decide crecer, la asignación del pod, el inicio real de trabajo y el coste del buffer durante una semana. Después se ensayan métricas ausentes, ráfagas y una degradación del servicio de observabilidad. Lo que conviene vigilar es la cobertura de señales, el precio efectivo de los buffers, la estabilidad de `AutoscalingMetric` y el comportamiento durante actualizaciones. GKE ha reducido una pieza de complejidad; demostrar que el ahorro supera el nuevo riesgo sigue siendo trabajo del equipo de plataforma.
La clave
`minReplicas: 0` elimina pods inactivos, no el coste completo del clúster. El caso funciona cuando existe una señal externa fiable, un presupuesto de arranque aceptable y una prueba de que el sistema vuelve de cero sin perder trabajo.
Etiquetas
- GKE
- Kubernetes
- HPA
- FinOps
- scale to zero
BOLDERROR Edición diaria Rubén Campoy