Page History

...

1. Standalone mode
1. supported by existing OSS operators
2. operator only entity that creates k8s objects
3. users can interact with k8s objects directly to manage job resources, scaling etc
4. Flink processes don’t require access to API server to create pods
5. job submission by operator without Flink client dependency
2. Flink native (embedded) k8s integration [2]
1. simple job management through Flink client without need to create k8s objectsreuse native integration client within operator for job submission
2. no support for reactive scaling, operator handles parallelism change
3. users should not interact with k8s objects directly as those are managed by flinkFlink
4. requires wider access privileges for Flink jobmanager process (creates taskmanager pods)
5. introduces tighter coupling between operator and supported Flink versions due to dependency on Flink client 

In the long run it might make sense to support both deployment modes in the operator, however initially we should focus the development effort on a single approach. Maybe start with support for [2] since we could reuse the code in a Java based implementation.

...