...
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.
CR Example
The
kind: FlinkDeployment
metadata:
name: flink-wordcount-example
namespace: flink-operator
annotations:
labels:
environment: development
spec:
image: example:latest
flinkVersion: "1.14"
flinkConfiguration:
// everything for flink-conf.yaml
state.savepoints.dir: file:///checkpoints/flink/savepoints
podTemplate:
// everything that a k8s pod template supports
// defaults for both, job and task manager pods
jobManager:
resources:
requests:
memory: "200Mi"
cpu: "0.1"
replicas: 1
podTemplate:
// everything that a k8s pod template supports
// layered over common template
taskManager:
taskSlots: 2
resources:
requests:
memory: "200Mi"
cpu: "0.1"
podTemplate:
// everything that a k8s pod template supports,
// layered over common template
// job can be optional for plain session cluster
job:
jarURI: "file:///wordcount-operator-example-1.0.0-SNAPSHOT.jar"
parallelism: 3
entryClass: "org.apache.flink.WordCount"
args: ""
upgradeMode: (stateless, savepoint)
state: (running, suspended, error)
initialSavepointPath: "s3://mysavepoint"
logging:
// customize logging config in flink container
status:
...
// information about the actual state
// including latest savepoint/checkpoint etc. |
...