Is the rationale of using a jobID 000000* also roughly the same. As in a Flink job cluster is a single job and thus a single job id suffices ? I am more wondering about the case when we are doing a compatible changes to a job and want to resume ( given we are in HA mode and thus have a chroot/subcontext on ZK for the job cluster ) , it would make no sense to give a brand new job id ?
On Thu, Feb 7, 2019 at 4:42 AM Till Rohrmann <trohrm...@apache.org> wrote: > Hi Sergey, > > the rationale why we are using a K8s job instead of a deployment is that a > Flink job cluster should terminate after it has successfully executed the > Flink job. This is unlike a session cluster which should run forever and > for which a K8s deployment would be better suited. > > If in your use case a K8s deployment would better work, then I would > suggest to change the `job-cluster-job.yaml` accordingly. > > Cheers, > Till > > On Tue, Feb 5, 2019 at 4:12 PM Sergey Belikov <belikov.ser...@gmail.com> > wrote: > >> Hi, >> >> my team is currently experimenting with Flink running in Kubernetes (job >> cluster setup). And we found out that with JobManager being deployed as >> "Job" we can't just simply update certain values in job's yaml, e.g. >> spec.template.spec.containers.image ( >> https://github.com/kubernetes/kubernetes/issues/48388#issuecomment-319493817). >> This causes certain troubles in our CI/CD pipelines so we are thinking >> about using "Deployment" instead of "Job". >> >> With that being said I'm wondering what was the motivation behind using >> "Job" resource for deploying JobManager? And are there any pitfalls related >> to using Deployment and not Job for JobManager? >> >> Thank you in advance. >> -- >> Best regards, >> Sergey Belikov >> >
