Hola comunidad, soy Yuanpeng Wang. Durante los últimos 3 años nuestro equipo migró gradualmente parte de las cargas de orquestación desde Azkaban a Apache DolphinScheduler y las contenedorizó en Kubernetes. En este artículo condensamos los principales tropiezos, aprendizajes y buenas prácticas para que los tengas a mano.
Sobre el autor: Yuanpeng Wang, Data Expert en Shanghai Qihoo Technology Co., Ltd., miembro del núcleo SRE Comercial y Big Data, responsable a largo plazo del despliegue y optimización de DolphinScheduler en producción, con experiencia profunda en contenerización y scheduling de big data.
En la operativa diaria de orquestación de big data, DolphinScheduler es una pieza crítica. Históricamente lo ejecutábamos en máquinas físicas, incluso la versión 3.1.9 seguía en bare metal, lo que nos mostró límites en escalado elástico, aislamiento de recursos y eficiencia operativa. Con la aceleración de la estrategia cloud native de la compañía, actualizamos a la versión 3.2.2 en 2025 y migramos parcialmente a Kubernetes.
Motivaciones clave de la migración: escalado elástico para añadir Workers en picos de carga, aislamiento de recursos para evitar interferencias entre jobs, despliegues automatizados con rollbacks más seguros y costos de mantenimiento más bajos, además de alinear la plataforma con la dirección cloud native corporativa.
Construcción de imágenes desde el código a los módulos. El primer paso fue crear una imagen base con Hadoop, Hive, Spark, Flink y Python. Encima de ella construimos la base de DolphinScheduler, incorporando los módulos recompilados y el driver de MySQL. Nota importante: MySQL almacena la metadata de DolphinScheduler, por lo que el JAR del driver debe enlazarse en todos los módulos dolphinscheduler-tools, dolphinscheduler-master, dolphinscheduler-worker, dolphinscheduler-api y dolphinscheduler-alert-server.
Las imágenes de cada módulo se personalizan sobre la base de DS principalmente ajustando puertos y configuración. Para minimizar cambios posteriores mantuvimos los nombres de imagen iguales a los oficiales. Puedes compilar de forma individual, por ejemplo el módulo worker, o lanzar una compilación en lote de todos los módulos. Problemas típicos a evitar: imágenes base demasiado pesadas y builds lentas, JARs personalizados que no sustituían a los antiguos, rutas de driver MySQL mal enlazadas, y desajustes de puertos o scripts entre módulos. Recomendaciones prácticas: separar capas comunes para maximizar caché, usar multistage donde aplique, limpiar JARs antiguos dentro de los scripts de build antes de copiar los nuevos, y unificar puertos y scripts de arranque entre módulos.
Despliegue con Helm en lugar de YAML artesanal. Empezamos con manifiestos a mano, pero la proliferación de configuración y la complejidad de upgrades nos llevó al chart oficial de Helm, que centraliza valores y simplifica upgrades y rollbacks. En un clúster Kubernetes v1.25 creamos el namespace y adoptamos el chart oficial. Consejo previo: sube las imágenes utilitarias a tu registro privado para evitar problemas de red durante el despliegue.
Valores críticos en values.yaml. Imagen: define registro, repositorio, tag y pullPolicy coherentes con tu cadena de suministro. Base de datos externa: desactiva el MySQL embebido y apunta a la instancia corporativa, con planes futuros de migración a PostgreSQL si buscas mayor robustez. Autenticación LDAP: habilitarla simplifica el gobierno de accesos y el inicio de sesión corporativo. Almacenamiento compartido: el StorageClass debe soportar ReadWriteMany para que múltiples Workers compartan artefactos y logs; define tamaño y mountPath consistentes con tu estándar. HDFS: configura defaultFS, el path de trabajo en HDFS y valida que las rutas de herramientas de big data existan previamente. Zookeeper: si usas ZK externo, desactiva el embebido y valida compatibilidad de versiones.
Errores frecuentes y cómo evitarlos. En imágenes: una base muy pesada ralentiza la CI, dependencias divergentes entre módulos generan instalaciones duplicadas, rutas incorrectas del driver MySQL provocan fallos al iniciar, y olvidar sobreescribir JARs antiguos causa excepciones en tiempo de ejecución. En Helm y values.yaml: usa un StorageClass con RWX real, cuida el tamaño del volumen, mountPath y sangrías de YAML, desactiva componentes que no necesites como ZK interno y respeta los requisitos de versión. En upgrades: cada nueva versión de DolphinScheduler implica comparar parches propios, reconstruir imágenes de todos los módulos y revalidar claves de configuración que a veces cambian de nombre, lo que dificulta rollbacks y alarga las ventanas de entrega.
Operación y mantenimiento. Documenta de forma estricta el proceso de build y promoción de imágenes, crea checklists para validar puertos, variables de entorno, dependencias de sistema y enlaces simbólicos del driver. Implementa sondeos de readiness y liveness acordes al tiempo real de arranque de cada módulo, y ajusta requests y limits para evitar throttling que degrade la latencia de scheduling. Añade dashboards para colas, tiempos de ejecución, fallos por tipo de task y uso de recursos por Worker.
Hoja de ruta. Para reducir OPEX a medio plazo priorizamos migrar la metadata de MySQL a PostgreSQL, converger hacia imágenes de la comunidad sin personalizaciones, mover el resto de cargas productivas a K8s, y habilitar una cadena CI CD con observabilidad completa en Prometheus y Grafana. Kubernetes aporta elasticidad, aislamiento y portabilidad superiores a bare metal. Si bien las imágenes y configuraciones personalizadas añadieron fricción, converger hacia estándares de la comunidad disminuirá la complejidad y acelerará la entrega.
Recomendaciones accionables. Estabiliza una imagen base mínima con herramientas de big data y librerías del sistema alineadas con tus jobs; separa las capas que cambian con menor frecuencia para cachear builds. Estandariza scripts de arranque y puertos entre módulos. Precalienta el registro con imágenes dependientes para evitar timeouts. Define un StorageClass RWX fiable y un plan de capacidad para el almacenamiento compartido. Versiona values.yaml por entorno con promoción automatizada y validaciones de esquema. Crea tests de humo que verifiquen conexión a DB, ZK, HDFS y ejecución de un workflow simple tras cada despliegue.
Cómo puede ayudarte Q2BSTUDIO. En Q2BSTUDIO somos una empresa de desarrollo de software y aplicaciones a medida, especialistas en inteligencia artificial, ciberseguridad y servicios cloud. Acompañamos migraciones de orquestadores a Kubernetes, automatizamos pipelines de datos y reforzamos observabilidad y seguridad extremo a extremo. Si tu organización está estandarizando su plataforma de scheduling o adoptando prácticas cloud native, podemos ayudarte con arquitectura, infraestructura como código, hardening y costes. Descubre cómo optimizamos tus despliegues con nuestros servicios cloud en AWS y Azure y cómo elevamos la eficiencia operativa con automatización de procesos.
SEO y tecnología al servicio del negocio. Combinamos software a medida y aplicaciones a medida con capacidades de ia para empresas, agentes IA y analítica avanzada. Complementamos tu gobierno del dato con servicios inteligencia de negocio y cuadros de mando en power bi, integrando seguridad por diseño mediante prácticas de ciberseguridad y pentesting. Nuestro objetivo es entregarte una plataforma de scheduling altamente disponible, extensible y realmente cloud native que acelere el time to value de tus casos de uso de datos e inteligencia artificial.
Conclusión. Migrar DolphinScheduler a Kubernetes aporta elasticidad, aislamiento y eficiencia operativa, siempre que controles la construcción de imágenes, la coherencia de configuración y una estrategia de despliegue y upgrade bien definida. Estándares de la comunidad, CI CD y observabilidad sólida reducen la deuda operativa y preparan el terreno para escalar. Si estás evaluando dar este paso, comparte tus dudas y experiencias, será un placer colaborar.