Lo que cuesta AKS: las decisiones de node pool que fijan tu factura

Azure no cobra prácticamente nada por el plano de control de AKS en el nivel gratuito, lo que lleva a los equipos a pensar que AKS es la opción barata. Luego llega la factura y es toda máquinas virtuales, discos gestionados, balanceadores y ingesta de Log Analytics. Nada de eso es AKS. Todo eso lo decidiste al construir los node pools.

Este es el orden en que desmontamos un clúster.

Mide antes de tocar nada

Peticiones frente a uso real, por namespace. La proporción entre CPU y memoria solicitadas y CPU y memoria realmente consumidas es el número más útil del clúster. Por encima de 3x estás pagando tres nodos para ejecutar el trabajo de uno. Container Insights te lo da, o Prometheus gestionado de Azure Monitor si lo quieres bien hecho, comparando kube_pod_container_resource_requests con el consumo real.

Asignable frente a solicitado, por nodo. AKS reserva una porción considerable de cada nodo para el kubelet y los demonios del sistema, y esa reserva es proporcionalmente brutal en SKU pequeñas. En un nodo de 2 vCPU puedes perder un cuarto de la máquina antes de que se planifique un solo pod de carga. Si tus pools están hechos de Standard_D2s, eso solo ya es un impuesto grande e invisible.

Coste por namespace. OpenCost o Kubecost, o un reparto manual de la factura de nodos según las peticiones. Sin una cifra por equipo, nadie acepta que el desperdicio es suyo y no cambia nada.

Ingesta de Log Analytics desde el clúster. Container Insights, con la configuración por defecto, recoge stdout y stderr de todos los contenedores de todos los namespaces, más eventos de kube e inventario. En un clúster con trabajo real esto es habitualmente una línea mayor que un node pool entero. La solución está en la factura de Azure Monitor.

Los cuatro cambios que suelen partirla por la mitad

Separa pool de sistema y pools de usuario, y deja de pagar la SKU equivocada. El pool de sistema ejecuta CoreDNS, metrics-server y compañía. Necesita ser fiable, no grande. Dale un pool pequeño con el taint CriticalAddonsOnly y dimensiona los pools de usuario según lo que las cargas piden de verdad. Los pools únicos de propósito mixto son la razón de que haya clústeres con nodos optimizados en memoria ejecutando servicios web sin estado.

Fija las peticiones a partir del uso observado. Las peticiones deben estar cerca del p95 del consumo real, no en una cifra redonda que alguien escribió cuando el servicio era nuevo. Vertical Pod Autoscaler en modo recomendación te da los números sin actuar sobre ellos. Déjalo dos semanas y aplica la salida a mano. Pon límites de memoria, porque la alternativa es un evento de falta de memoria que se lleva el nodo entero, y sé tacaño con los límites de CPU, que provocan estrangulamiento en el p99 mientras el nodo está ocioso.

Activa el aprovisionamiento automático de nodos en lugar de pools hechos a mano. El autoescalador de clúster escala los pools que definiste de antemano, así que tu empaquetado está limitado por las SKU que adivinaste hace meses. El aprovisionamiento automático de nodos, que por debajo es Karpenter, elige el tamaño de VM que encaja con los pods pendientes y consolida las cargas en menos nodos cuando encogen. Solo la consolidación suele quitar entre un 20 y un 30 por ciento de los nodos de un clúster que lleva un año funcionando. Define un presupuesto de interrupción y anota las cargas con estado con karpenter.sh/do-not-disrupt antes de encenderlo.

Pon en pools Spot lo que corresponde. Las cargas sin estado, replicadas y tolerantes a reinicios van en un node pool Spot con una lista diversificada de SKU y un núcleo bajo demanda para todo lo que toque al plano de control. El descuento es profundo. Lo que hace daño es un servicio con estado y una sola réplica en Spot, con desalojo a las tres de la madrugada. Los pools Spot llevan por defecto el taint kubernetes.azure.com/scalesetpriority, así que tienes que apuntar las cargas deliberadamente, que es el sentido correcto.

Lo que se olvida siempre

• Clústeres de desarrollo y preproducción ociosos. Escala los pools de usuario a cero fuera del horario de trabajo. El pool de sistema tiene que seguir arriba, así que el ahorro es parcial, pero en un entorno grande de no producción sigue siendo dinero real. Una cuenta de automatización y una programación; una tarde.
• Un balanceador Standard y una IP pública por clúster, más una NAT gateway para la salida. Cuatro clústeres pequeños donde bastaría uno con namespaces son puro gasto fijo.
• DaemonSets sobredimensionados. Un agente de logs que pide 500m de CPU en 40 nodos son 20 núcleos que pagas y no usas, y se planifica en cada nodo nuevo que levante el aprovisionamiento automático.
• Discos gestionados huérfanos de PersistentVolumeClaims borradas con política de recuperación Retain. Azure los conserva y los factura para siempre.
• Nivel Premium que no necesitabas. El nivel Standard compra un SLA de disponibilidad con respaldo económico y es el valor por defecto correcto en producción. El gratuito vale para desarrollo. Premium es para soporte prolongado sobre una versión vieja de Kubernetes, lo cual es un motivo para actualizar, no para pagar.

Escalar a cero, bien hecho

Horizontal Pod Autoscaler escala por CPU y memoria, que es la señal equivocada para casi todo lo que de verdad necesita escalar. KEDA, que viene como complemento de AKS, escala por profundidad de cola, mensajes en Service Bus, retraso en Event Hubs o una consulta de Prometheus, y escala a cero. Un despliegue de workers con dos réplicas toda la noche procesando una cola vacía es un coste pequeño, permanente y completamente evitable.

Cómo se ve un clúster sano

Un AKS sano funciona al 55-70 por ciento de asignación media de CPU, mantiene las peticiones dentro de 1,5x del uso, levanta un nodo en menos de dos minutos y sobrevive a la pérdida de cualquier nodo sin despertar a nadie. Llegar ahí son dos o tres semanas de trabajo y no reescribe nada.

Solo entonces tiene sentido un compromiso. Los nodos de AKS son máquinas virtuales normales, así que las reservas y el plan de ahorro de Azure para cómputo se les aplican igual que al resto — y por eso este trabajo va antes de la compra, en el orden que explicamos en la factura de Azure. Lo hacemos en la fase de costes de un proyecto cloud.

Qué hacer esta semana

Calcula la proporción peticiones-uso de tus tres namespaces más grandes y saca los últimos 30 días de ingesta en Log Analytics atribuida a Container Insights. Uno de esos dos números es casi con seguridad tu respuesta, y ninguno lleva más de una hora.