Hi everyone. TLDR: Is it possible to configure sta...
# random
b
Hi everyone. TLDR: Is it possible to configure stabilization window for TM pod using Flink official K8s operator? Backgroud: We are using GCP Flink-on-k8s-operator for creating flink session cluster(JM & TM pods are up all the time, multiple clusters are there). Then for submitting a job to a cluster, we use the Flinks REST API and submit the job to Jobmanager. All clusters job manager have Jars to run the job(they are downloaded when Flink JM starts) at web.upload.dir Now we are working on migrating to Flink's official K8s operator. I have been doing a POC, and so far I am able to create a Flink Deployment which creates the JM only and when a job is submitted the TM pod comes up and the job is scheduled and after the job is completed the TM pod goes down. I want to know if it is possible to configure a stabilization window period here(like in K8s HPA)? Say I want the TM pod to go down after 5min(configurable) of sitting idle. Currently, it goes down in almost a minute I guess if there are no jobs to run. We need it because, the nature of our jobs is they are submitted every few minutes during particular periods of the day, this way our TM pod keeps coming up & down, and it adds time to overall execution. Our jobs are time sensitive, we want to reduce this time taken if we have such a configuration. I tried looking at docs, but couldn't find it, if there's already such config can someone please share? If no, what would be the alternatives to it? Thanks for your time reading this.
g
Why do you use the rest api for submission and not application deployment or the FlinkSessionJob CR?
(Just curious , I will try to find you the config for the TM idleness timeout soon when I am back at my laptop )
馃檶 1
resourcemanager.taskmanager-timeout
b
Hi Gyula, thanks for the response. I will try this. We are submitting via REST API because our jobs are time sensitive, taken at max a few seconds/minute to run and on demand cluster adds startup time to overall job execution time. We were using session cluster for that reason.
g
Ok, in any case the FlinkSessionJob CR might be interesting for you, if you want to get rid of your rest api logic 馃檪
馃憤 1
b
Thanks, we will explore session jobs.
g
With session jobs you still have a separate session FlinkDeployment like now, but you delegate the REST submission to the operator itself
the logic is probably very similar to what you are executing locally, but in a slightly more user friendly way 馃檪
馃憤 1