Mantenimiento de aplicaciones de Flink
Las aplicaciones de Flink suelen estar diseñadas para ejecutarse durante largos periodos de tiempo, como semanas, meses o incluso años. Como ocurre con todos los servicios de larga duración, las aplicaciones de transmisión de Flink deben mantenerse. Esto incluye correcciones de errores, mejoras y migración a un clúster de Flink de una versión posterior.
Cuando cambien las especificaciones para los recursos FlinkDeployment y FlinkSessionJob, es necesario actualizar la aplicación en ejecución. Para ello, el operador detiene el trabajo en ejecución (a menos que ya esté suspendido) y lo vuelve a implementar con las especificaciones más recientes y, en el caso de las aplicaciones con estado, con el estado de la ejecución anterior.
Los usuarios controlan cómo administrar el estado en el que las aplicaciones con estado se detienen y se restauran con la configuración upgradeMode del JobSpec.
Modos de actualización
Introducción opcional
- Sin estado
-
Las aplicaciones sin estado se actualizan desde un estado vacío.
- Último estado
-
Las actualizaciones rápidas en cualquier estado de la aplicación (incluso para trabajos con errores) no requieren un trabajo en buen estado, ya que siempre se utiliza el último punto de control correcto. Si se pierden los metadatos de alta disponibilidad, puede ser necesaria una recuperación manual. Para limitar el tiempo que el trabajo puede demorar al seleccionar el último punto de control, puede configurar
kubernetes.operator.job.upgrade.last-state.max.allowed.checkpoint.age. Si el punto de control es anterior al valor configurado, se utilizará un punto de almacenamiento para los trabajos en buen estado. Esto no se admite en el modo de sesión. - Punto de almacenamiento
-
Utilice el punto de almacenamiento para la actualización, ya que proporciona la máxima seguridad y la posibilidad de servir como punto de respaldo o bifurcación. El punto de almacenamiento se creará durante el proceso de actualización. Tenga en cuenta que el trabajo de Flink debe estar en ejecución para permitir la creación del punto de almacenamiento. Si el trabajo está en mal estado, se utilizará el último punto de control (a menos que kubernetes.operator.job.upgrade.last-state-fallback.enabled esté establecido en falso). Si el último punto de control no está disponible, la actualización del trabajo fallará.
