Kestra 2.0 reescribe el motor para facilitar el autohospedaje
El orquestador de flujos de código abierto sustituye el modelo centralizado por controladores y trabajadores sin estado, manteniendo el mismo YAML para Docker, proceso o Kubernetes.
Kestra 2.0 ya está disponible. El orquestador de flujos de trabajo de código abierto ha publicado su nueva versión mayor, y su creador ha explicado en detalle qué cambia. El motor se ha reescrito en gran parte con un objetivo: simplificar el autohospedaje y el escalado. La versión sigue siendo Apache 2.0, y se puede probar fácilmente con Docker.
El cambio arquitectónico más importante: en 2.0 ya no hace falta que cada trabajador se conecte directamente a la base de datos central. Ahora un controlador actúa como intermediario. Los trabajadores pasan a ser sin estado, no guardan credenciales de bases de datos y abren una única conexión saliente gRPC con autenticación mutua TLS. No hay puertos abiertos hacia los trabajadores, algo que el autor justifica con casos reales: una fábrica que no permite tráfico entrante, un banco con red aislada o un hospital que hace inferencia GPU. Esa misma lógica sirve para un equipo dentro de una red doméstica detrás de un router.
La forma de definir los flujos no cambia: se usa YAML y cada tarea puede dispararse por cron, webhook, la llegada de un fichero, un mensaje MQTT o Kafka, o la finalización de otro flujo. Las tareas pueden ser plugins (hay más de dos mil) o scripts en cualquier lenguaje. Cada script se ejecuta por defecto en un contenedor propio, pero basta con cambiar una propiedad para que corra sobre el proceso anfitrión o como pod de Kubernetes. El mismo YAML funciona en los tres casos.
Para desplegarlo es más ligero que antes. Ya no hace falta Kafka ni Elasticsearch: con Postgres o MySQL basta para la cola, el estado y los metadatos. Los plugins se descargan bajo demanda, así que la imagen base no incluye conectores que no se usen. El servidor es una aplicación JVM y necesita unos 4 GB de RAM para ir desahogado, según su CTO. Se publican imágenes para linux/amd64 y arm64, y esta última es la misma que se usa para Graviton, por lo que una Raspberry Pi 4 o 5 con 8 GB puede ejecutar el servidor sin problema, aunque no se recomienda un Pi Zero.
También se añaden herramientas interesantes para operarlo. Hay un CLI (kestractl) para validar y desplegar flujos desde CI, sincronización con git, y un proveedor de Terraform para gestionar flujos como recursos. Además, se pueden escribir pruebas unitarias para los flujos y usar un playground para ejecutarlos tarea a tarea mientras se desarrollan. La versión LTS tendrá correcciones durante un año.
Para quienes ya usaban Kestra 1.x, el autor dice que el cambio de arquitectura es transparente a nivel de definición de flujos: el mismo YAML de siempre funciona contra la nueva versión. Quien quiera entrar sin más, puede probarlo con un solo docker run y una base de datos en memoria, como se explica en la página de lanzamiento. El código fuente está disponible en GitHub y es apto para contribuciones.
