El coste de GKE, y por qué Autopilot mueve el desperdicio en vez de eliminarlo

Dos equipos migran de Standard a Autopilot por motivos de coste. Uno ve bajar la factura un tercio. El otro la ve subir. Las cargas son parecidas y los dos resultados eran predecibles a partir de una única medición que ninguno de los dos hizo antes.

Con Standard pagas los nodos. Un pod que pide cuatro núcleos y usa medio es desperdicio que ves como baja utilización del nodo, y resulta tolerable porque el nodo ya está pagado. Con Autopilot pagas lo que pide el pod. Ese mismo pod factura ahora cuatro núcleos directamente, y el desperdicio deja de estar escondido y pasa a estar desglosado.

Autopilot no arregla pedir de más. Le pone precio.

Mide la proporción antes de elegir nada

El número que decide tanto la elección de plataforma como cada optimización posterior es la proporción entre CPU y memoria solicitadas y CPU y memoria realmente usadas, por namespace.

Sácala del Prometheus gestionado, comparando las peticiones de recursos de los contenedores con el consumo real, o de las recomendaciones que produce el escalador vertical de pods. Por encima de 3x estás comprando tres unidades de capacidad para ejecutar el trabajo de una. Por debajo de 1,5x estás en forma razonable.

Si esa proporción es alta, Autopilot va a salir caro, porque cobra directamente por aquello en lo que te estás equivocando. Arregla primero las peticiones y después elige plataforma. La decisión en sí, más allá del coste, está en GKE Autopilot o Standard.

Las palancas de Standard

Peticiones fijadas a partir del uso observado. Las peticiones van cerca del p95 del consumo real. El escalador vertical de pods en modo recomendación produce 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, y sé tacaño con los límites de CPU, que estrangulan en el p99 mientras el nodo está ocioso.

Aprovisionamiento automático de nodos en vez de grupos dimensionados a mano. El autoescalador de clúster escala grupos que definiste de antemano, así que el empaquetado está limitado por los tipos de máquina que adivinaste. El aprovisionamiento automático crea grupos dimensionados para la carga pendiente. Combínalo con el perfil de autoescalado que optimiza la utilización, que consolida de forma más agresiva a cambio de algo más de interrupción.

Máquinas interrumpibles para lo que las tolere. Cargas sin estado, replicadas y tolerantes a reinicios en un grupo interrumpible con una lista diversificada de tipos de máquina, 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 ahí.

Tipos de máquina personalizados. Una ventaja genuina de esta plataforma: si tus cargas son intensivas en memoria respecto a CPU, una forma personalizada evita pagar núcleos que no vas a usar. Casi ningún entorno lo prueba.

Descuentos por uso comprometido contra la línea base corregida, nunca antes. El orden y el razonamiento están en descuentos por uso comprometido en Google Cloud.

Las palancas de Autopilot son otras

Con Autopilot desaparece la optimización a nivel de nodo y todo pasa a girar sobre la especificación del pod.

Las peticiones son la factura. Nada más. Una revisión a la baja de las peticiones se traduce directamente en dinero, que es un bucle de realimentación más claro del que Standard ofrece nunca.

Las clases de cómputo importan. La de propósito general es la de por defecto y hay clases para cargas de escalado horizontal, equilibradas y con acelerador, con características de precio y rendimiento distintas. Elegir a conciencia en vez de quedarse con la de por defecto vale dinero real en un clúster grande.

Los pods interrumpibles están disponibles y son el mayor ahorro individual para cargas tolerantes.

Mínimos y redondeos. Los pods tienen cantidades mínimas de recursos y las peticiones se redondean, así que los pods muy pequeños son menos eficientes de lo que sugiere su especificación. Un despliegue de cuarenta pods diminutos puede costar más de lo que implica la aritmética.

Los DaemonSets también se facturan, y tienes menos control sobre el número de nodos donde aterrizan.

El encuadre honesto: Autopilot elimina el trabajo de gestión de nodos y cobra una prima por unidad de recurso de pod. Gana cuando tus peticiones son exactas y tu utilización de clúster con Standard habría sido mala. Pierde cuando ya empaquetabas bien.

Los costes que no son ni nodos ni pods

• La cuota de gestión del clúster. Por clúster y hora por encima de la franquicia. Cuatro clústeres pequeños donde bastaría uno con namespaces es puro gasto fijo, y es el argumento de varios equipos en un clúster.
• Tráfico entre zonas. En un clúster regional con servicios que ignoran la topología, la mayor parte del tráfico entre pods cruza una frontera de zona y se factura. El encaminamiento consciente de la topología mantiene el tráfico local cuando puede, y en entornos de microservicios parlanchines la diferencia es una línea real.
• Balanceadores y direcciones externas, uno por servicio expuesto salvo que compartas una entrada.
• Registro y monitorización. Los registros de contenedor de todos los namespaces con la configuración por defecto son con frecuencia una línea mayor que un grupo de nodos. Los filtros de exclusión en el receptor son el control de mayor retorno, como se explica en los costes de Cloud Logging y Cloud Storage.
• Discos persistentes huérfanos de reclamaciones borradas con política de retención.

Escalar a cero, bien hecho

El escalador horizontal de pods escala por CPU y memoria, que es la señal equivocada para casi todo lo que necesita escalar. KEDA escala por profundidad de cola, por acumulación en una suscripción de mensajería o por una consulta de Prometheus, y escala a cero. Un despliegue de workers con dos réplicas toda la noche contra una suscripción vacía es un coste pequeño, permanente y completamente evitable.

Para cargas genuinamente irregulares dirigidas por peticiones, la pregunta honesta es si esto pertenece a un clúster siquiera, que es la comparación de Cloud Run o GKE.

Sobreaprovisionar a propósito

Una práctica contraintuitiva que conviene conocer. Si tu problema es que escalar tarda demasiado, el arreglo habitual es tener nodos de sobra, que es caro e invisible.

La versión mejor son los pods globo: pods de relleno con prioridad baja que reservan capacidad y se desalojan de inmediato cuando una carga real necesita el sitio. Consigues planificación rápida sin pagar nodos ociosos que no puedes justificar, y el coste es explícito y ajustable en vez de estar escondido en el mínimo de un grupo de nodos.

Qué hacer esta semana

Calcula la proporción peticiones-uso de tus tres namespaces más grandes. Si está por encima de 2,5x, esa es tu respuesta sea cual sea la plataforma que ejecutes, y el escalador vertical en modo recomendación te dará los números corregidos en dos semanas. No migres a Autopilot para arreglarlo; migra después de arreglarlo, si los números siguen favoreciéndolo. Lo trabajamos en la fase de costes de un proyecto cloud.