Flink
Senior¿Cómo despliego un cluster de Flink en Kubernetes usando la integración nativa?
Flink no solo corre dentro de Kubernetes - con la integración nativa, habla directamente con la API de Kubernetes para gestionar sus propios pods de TaskManager. Eso es un despliegue significativamente distinto a "Flink en un contenedor".
Hay dos formas reales de correr Flink en Kubernetes: el despliegue standalone (Flink no tiene idea de que está en K8s - usted gestiona réplicas como cualquier otro Deployment sin estado) y la integración nativa (el propio ResourceManager de Flink habla con la API de Kubernetes para solicitar y liberar pods de TaskManager según los jobs lo necesiten).
Qué significa realmente "nativa" aquí
Con el despliegue standalone, los TaskManagers son solo pods en un Deployment de
Kubernetes - Kubernetes los reinicia si mueren, pero Flink mismo no tiene capacidad de pedir más o menos
según la demanda del job. Con la integración nativa, el ResourceManager de Flink llama directamente a la
API de Kubernetes (crear/eliminar pods) para escalar TaskManagers según lo que un job realmente necesite -
más cercano en espíritu a cómo siempre ha funcionado la integración de Flink con YARN, solo hablando con un
scheduler distinto.
El RBAC que esto realmente requiere
Porque Flink está creando y eliminando pods él mismo, su service account necesita permisos reales en el namespace donde corre - no solo el acceso de solo lectura que necesitaría un pod de aplicación normal:
Esa es una superficie de permisos significativamente mayor de la que necesitan la mayoría de las cargas de trabajo de aplicación, y vale la pena señalarlo a quien posea la política de seguridad del cluster antes de que aparezca como sorpresa en una revisión - es inherente a cómo funciona la integración nativa, no una mala configuración.
Dónde esto todavía deja una elección
El Flink Kubernetes Operator (un proyecto separado, más nuevo) se sienta encima de cualquiera
de los modos de despliegue y agrega gestión de ciclo de vida nativa de Kubernetes - hacer
kubectl apply de un custom resource FlinkDeployment en vez de correr
flink run-application a mano, con el operator manejando upgrades, redeploys basados en
savepoint, y reconciliación. No es tanto un tercer modo de despliegue sino una capa de gestión - vale la
pena adoptarlo una vez que tiene más de un par de jobs de Flink que operar, menos claramente valioso como
pieza móvil adicional para un solo job.
Fuera del alcance de opti-pipe: el motor de reglas lee cualquier métrica que exporte un job de Flink corriendo o completado - no le importa si los TaskManagers de ese job fueron aprovisionados por la integración nativa, un Deployment standalone, o el Kubernetes Operator, ya que nada de eso cambia lo que significan las métricas.
Vea cómo se ve esto en su propio pipeline.
Suba un event log real de Spark, un run_results.json de dbt o una exportación de métricas de Flink y obtenga recomendaciones concretas, que debe aprobar antes de aplicar - no otra regla general.