Как развернуть кластер Flink на Kubernetes через нативную интеграцию?

Есть два реальных способа запускать Flink на Kubernetes: standalone-деплой (Flink понятия не имеет, что он на K8s — вы управляете репликами как любым другим stateless-деплойментом) и нативная интеграция (собственный ResourceManager Flink обращается к Kubernetes API, чтобы запрашивать и освобождать поды TaskManager'ов по мере надобности задач).

Что на самом деле значит «нативная»

При standalone-деплое TaskManager'ы — просто поды в Kubernetes Deployment: Kubernetes перезапускает их при гибели, но сам Flink не может попросить больше или меньше подов исходя из потребности задачи. При нативной интеграции ResourceManager Flink напрямую вызывает Kubernetes API (создание/удаление подов), чтобы масштабировать TaskManager'ы под реальную потребность задачи — ближе по духу к тому, как всегда работала интеграция Flink с YARN, просто с другим планировщиком.

Какой RBAC это реально требует

Поскольку Flink сам создаёт и удаляет поды, его service account нуждается в реальных правах в namespace, где он работает — не просто доступе только на чтение, который был бы нужен обычному приложению:

Это заметно бо́льшая поверхность прав, чем нужна большинству прикладных нагрузок, и стоит заранее обозначить тому, кто владеет политикой безопасности кластера, прежде чем это всплывёт сюрпризом на ревью — это неотъемлемая часть того, как работает нативная интеграция, а не ошибка конфигурации.

Где здесь всё ещё остаётся выбор

Flink Kubernetes Operator (отдельный, более новый проект) работает поверх любого из режимов деплоя и добавляет управление жизненным циклом в стиле Kubernetes — kubectl apply на custom resource FlinkDeployment вместо ручного запуска flink run-application, с оператором, берущим на себя апгрейды, редеплои на основе savepoint и reconciliation. Это не столько третий режим деплоя, сколько слой управления — стоит внедрять, когда у вас больше пары задач Flink в эксплуатации, и не так очевидно того стоит как лишняя движущаяся часть для одной задачи.