F5 · Approach — FTE y autoescalado por cola, medido contra el cluster vivo

0 · Por qué importa esta fase, y por qué el titular está mal

El runbook y el doc de coste dicen lo mismo, y con razón:

Eso sigue siendo cierto como dependencia lógica y es falso como plan ejecutable, por una razón que no es técnica y que no estaba escrita en ninguna parte: 👇

1 · Los cinco hallazgos, por orden de lo que cambian

① Stackable 25.3 no sabe nada de FTE — y lo tira en silencio

kubectl explain trinoclusters.spec --recursive | grep -iE 'exchange|retry|faultToler'
#   → (nada)

El CRD no tiene ningún campo para el exchange manager. Y lo natural —meterlo por configOverrides, que es map[fichero]map[clave]valor— se acepta y no hace nada:

kubectl patch trinocluster carbon -n trino --type=merge \
  -p '{"spec":{"workers":{"configOverrides":{"exchange-manager.properties":{…}}}}}'
#   → trinocluster.trino.stackable.tech/carbon patched      ✅ verde

kubectl get cm carbon-worker-default -n trino -o jsonpath='{.data}' | …
#   → access-control.properties · config.properties · jvm.config
#     log.properties · node.properties · security.properties
#   ⇒ exchange-manager.properties NO ESTÁ

Es exactamente la trampa de F4·3, que este repo ya tiene escrita: «Stackable copia sólo 5 ficheros fijos … y el access-control es un fichero APARTE que sólo genera un campo del CRD». Allí había campo (clusterConfig.authorization.opa). Aquí no hay ninguno.

⚠️ Y lo que lo hace peligroso no es que falle: es que no falla. kubectl apply da verde, el operador reconcilia, el pod arranca — y Trino nunca ve el fichero. Es el mismo patrón que el -Xmx del §2: el comando no falla y el resultado no está.

② La salida es un initContainer sobre rwconfig — y el subPath NO vale

Cómo arranca Stackable a Trino, leído del command del StatefulSet:

cp -RL /stackable/config/* /stackable/rwconfig
bin/launcher run --etc-dir=/stackable/rwconfig --data-dir=/stackable/data

Y los volúmenes:

La vía obvia —montar el fichero con subPath dentro de /stackable/config, imitando lo que hace catalog— se probó y revienta el contenedor:

Error: failed to create containerd task … error mounting
  "…/volume-subpaths/sonda/trino/10" to rootfs at "/stackable/config/sonda.properties":
  flags=MS_RDONLY|MS_BIND|MS_REC: not a directory

⇒ Anidar un DIRECTORIO dentro de un volumen de ConfigMap funciona (por eso catalog va bien); anidar un FICHERO no, porque el bind-mount necesita que el destino ya exista y el volumen de ConfigMap es de sólo lectura. El worker quedó en CrashLoopBackOff hasta revertir.

La vía que sí funciona, y sale de que rwconfig sea un emptyDir:

podOverrides:
  spec:
    initContainers:
      - name: exchange-manager-config
        image: <la misma imagen>
        command: ["sh","-c","cp /cfg/exchange-manager.properties /stackable/rwconfig/"]
        volumeMounts:
          - { name: rwconfig, mountPath: /stackable/rwconfig }
          - { name: exchange-cfg, mountPath: /cfg }
    volumes:
      - name: exchange-cfg
        configMap: { name: trino-exchange-manager }

El initContainer escribe en el emptyDir antes; el cp -RL del arranque añade los otros seis ficheros encima sin borrar el nuestro (nombres distintos). Trino arranca y encuentra etc/exchange-manager.properties donde lo busca.

③ Workload Identity: la premisa del runbook es media verdad, y la mitad falsa es la que importa

El §7 del runbook dice:

Hay que separarlo en dos, porque Trino tiene dos caminos distintos a GCS:

El primero, verificado en el código de la 470 (GcsStorageFactory), no en la doc — que no lo menciona y por eso se dudaba:

credentials = jsonGoogleCredential.orElseGet(() -> {
    return GoogleCredentials.getApplicationDefault();   // ← sin gcs.json-key* ⇒ ADC
});

El segundo es el que rompe el plan (FileSystemExchangeModule, Trino 470 y 483 — subir de versión no lo arregla):

else if (ImmutableSet.of("s3", "gs").contains(scheme)) {
    binder.bind(FileSystemExchangeStorage.class).to(S3FileSystemExchangeStorage.class)…
    CompatibilityMode compatibilityMode = scheme.equals("gs") ? GCP : AWS;   // ⭐
}

⇒ gs:// NO usa el filesystem GCS nativo. Usa el cliente S3 contra la API de interoperabilidad XML de GCS. Y sus credenciales salen de:

if (accessKey != null) { return StaticCredentialsProvider.create(
        AwsBasicCredentials.create(accessKey, secretKey)); }

o sea exchange.s3.aws-access-key / -secret-key = claves HMAC de GCS. Estáticas. Durables. En un Secret.

⇒ La consecuencia honesta: F5 introduce UNA credencial durable nueva, sí o sí. No hay configuración que lo evite en la 470 ni en la 483. Lo que sí se puede es acotarla: una SA dedicada, con HMAC propias, y permiso únicamente sobre el bucket del exchange — que guarda shuffle efímero, no tablas de nadie. El radio de explosión es pequeño; la afirmación «cero secretos durables donde haya federación» deja de ser cierta y hay que corregirla en el §5 del runbook, no esconderla.

④ No hay sitio para un segundo worker — y por tanto el gate de F5 no se puede ejecutar hoy

El gate de F5 es, literalmente: «matar un worker a mitad de una query larga y que la query termine». Eso exige dos workers: con uno, matarlo deja el cluster sin nadie a quien reasignar la tarea, y lo que se mediría no es FTE.

Al intentarlo, el autoescalador lo dijo:

Warning  FailedScaleUp  cluster-autoscaler
  Node scale up in zones europe-west1-b … failed: GCE quota exceeded

Y la cuota es ésta:

SSD_TOTAL_GB     usage 202    limit 250

⭐ pd-balanced cuenta contra la cuota de SSD. Dos nodos × 100 GB = 200. Un tercero pide 302 > 250. El cluster está a un nodo de su techo, y el techo no es dinero: es cuota.

⑤ Los pods de Trino son Burstable, y el propio doc de coste dice que no deben serlo

Medido en el pod vivo: QoS Class: Burstable, porque cpu: {min: 300m, max: 1} genera requests != limits. Y el §P4 del doc de coste ya lo tiene escrito:

La regla está escrita y no está aplicada. Hoy es un riesgo latente; con FTE y Spot encima pasa a ser un multiplicador: un desalojo por presión de memoria del nodo se sumaría a los desalojos de Spot, y los dos se diagnostican igual. Va en F5, no después.

2 · Lo que queda en pie, y en qué orden

Una variable por fase, como manda el runbook. Con lo medido, F5 se parte en cuatro, y las dos primeras no son las que estaban escritas:

La decisión que este documento NO toma

Dónde vive el exchange, porque las tres salidas tienen precios distintos y ninguno es técnico:

3 · 🏁 EJECUTADO el 2026-08-07 — F5·0 y F5·a CERRADAS

Lo que quedó montado

El gate, con su control negativo

Y la prueba de que el shuffle sale de la máquina, listada durante la query:

gs://carbon-trino-exchange/1a5d86.20260807_113215_00004_j3ded.external-exchange-0.0/0/

⇒ El camino HMAC escribe de verdad, y no por deducción: por ls.

🔴 ⑥ EL HALLAZGO GRANDE: FTE salva la QUERY, pero el WORKER vuelve roto

Matar un worker con --force --grace-period=0 —que es lo que hace un desalojo de Spot— lo dejó en CrashLoopBackOff permanente, con este error:

ERROR: already running as 12

Causa: /stackable/data es un volumeClaimTemplate, o sea un PVC que sobrevive al pod. El launcher de Trino deja ahí var/run/launcher.pid y una muerte súbita no lo limpia. El pod nuevo lo lee y comprueba si ese PID vive — dentro de su propio namespace, donde los PIDs vuelven a empezar en 1, así que casi siempre hay algo con ese número. Conclusión: «ya estoy corriendo». Y no arranca. Nunca. No se cura solo.

Arreglo, en el initContainer que ya existía para el exchange manager:

rm -f /stackable/data/var/run/launcher.pid

Verificado del modo que vale: el worker que llevaba 7 reinicios y estaba atascado para siempre arrancó limpio en cuanto el initContainer llevaba el rm.

🔴 ⑦ El gate dio un FALSO VERDE la primera vez — y el control negativo también

La primera pasada del gate salió «verde» y no probaba nada. El segundo worker existía como pod y estaba Ready, pero aún no se había anunciado al coordinador cuando arrancó la query. La query corrió con un worker, matar al otro no le quitó nada, y el resultado fue correcto y el tiempo también.

Peor: el control negativo (retry-policy=NONE) cayó en la misma trampa y también «sobrevivió» — 219,0 s contra los 221,9 s del run con FTE. Dos veredictos idénticos que parecían confirmar FTE y en realidad decían «esta query tarda 220 s con un worker».

⇒ La regla: antes de un gate de tolerancia a fallo, comprobar system.runtime.nodes y system.runtime.tasks, nunca kubectl get pods. Un pod Ready no es un worker que esté ejecutando. Sólo cuando se verificó dentro de la ventana que los dos nodos tenían tareas RUNNING el control negativo empezó a fallar como debía.

🔴 ⑧ kubectl rollout status dice «complete» sin haber reiniciado nada

Cambiar retry-policy por el CR actualiza el ConfigMap, no el PodTemplate ⇒ el StatefulSet no rueda, y rollout status responde partitioned roll out complete. El pod seguía con la config vieja 15 minutos después.

Es el C5 de F2 otra vez («cambiar el TrinoCatalog actualizó el ConfigMap pero no el proceso»), con una vuelta de tuerca: allí no había nada que dijera lo contrario; aquí hay un comando que afirma explícitamente que sí se ha desplegado. ⇒ Tras cualquier cambio de configOverrides: kubectl rollout restart, y verificar leyendo /stackable/rwconfig/config.properties dentro del pod.

⚠️ ⑨ Y una que queda ABIERTA: FTE sube el suelo de memoria del coordinador

Durante las pruebas el coordinador se murió una vez con OOMKilled con FTE puesto y el heap ya al 65 %. Tiene sentido: con retry-policy=TASK el coordinador guarda los descriptores de tarea para poder reintentarlas (fault-tolerant-execution-task-descriptor-storage-max-memory = heap × 0,15) además de todo lo demás.

⇒ Es la tercera vez que la conclusión es la misma máquina: el hallazgo ⑤ (QoS Guaranteed imposible, sólo 434m libres), el aviso del Helm oficial («fewer pods each having more resources») y ahora esto. n2-standard-2 se ha quedado pequeña, y no por el dato: por el impuesto de sistema, que es fijo por nodo (~1,5 cores y ~1,85 GiB de requests) y en una máquina de 2 vCPU se come el 77 %.

[confirmar] en F6: con n2-standard-4 el mismo impuesto pasa a ser ~38 %, y entonces sí caben un heap holgado, el QoS Guaranteed y el margen que FTE pide.

4 · 🏁 F5·b — EJECUTADO 2026-08-07, y no es lo que el runbook pedía

El runbook pide «autoescalado por COLA, no por CPU (KEDA sobre queries encoladas)». Con Stackable 25.3 no se puede, y las tres medidas que lo cierran:

La métrica está y el motor no se deja escalar. La única forma de que KEDA funcione es clusterOperation.reconciliationPaused: true — verificado: con la pausa puesta, el escalado externo aguanta. Pero eso apaga la reconciliación entera: a partir de ahí kubectl apply del CR da verde y no cambia nada.

⇒ No se hace. En una sola sesión este repo se ha comido tres veces ese fallo exacto —el add del -Xmx, el configOverrides del exchange manager y el rollout status que dice complete sin rodar— y armarlo de forma permanente a cambio de mover workers de 1 a 2 no compensa.

Lo que sí se hizo: F5·b1 · suspensión, por la vía nativa del operador

clusterOperation.stopped: true — un solo campo del CRD, sin pausar nada. infra/gke/trino-suspend.sh {on|off|status}.

Medido de punta a punta:

⚠️ Dos cosas que el stopped NO apaga, y las dos cuestan dinero:

1. El opa-bridge — es un Deployment nuestro (f4-opa-bridge.yaml), no lo gestiona el operador de Trino. stopped no lo toca y se queda ocupando hueco de nodo para no autorizar a nadie. El script lo escala aparte.
2. El nodo de sistema y el cargo de gestión. kube-system necesita dónde vivir ⇒ el pool no baja de 1, y los 63 €/mes de cluster regional se pagan igual. Eso sólo lo quita borrar el cluster (la otra forma de P3, con carbon-compute.sh).

5 · Lo que este approach NO dice

• No dimensiona el exchange. El bucket cobra almacenamiento y operaciones; sin lifecycle crece sin techo. Se mide con el bucket delante, como avisa el §6 del doc de coste.
• No decide si merece la pena FTE a esta escala. Con 1-2 workers, FTE añade latencia (todo el shuffle pasa por almacenamiento remoto) a cambio de una resiliencia que sólo se cobra cuando hay desalojos. Con Spot bloqueado, no hay desalojos que absorber.
• No toca el Gateway (F6) ni el nested-namespace. Son otras fases.