Re: Flink native k8s integration vs. operator

rnetes Regards, Alexis. From: Gyula Fóra mailto:gyula.f...@gmail.com>> Sent: Montag, 17. Januar 2022 12:40 To: dev mailto:dev@flink.apache.org>> Cc: Xintong Song mailto:tonysong...@gmail.com>>; user mailto:u...@flink.apache.org>> Subject: Re: Flink native k8s integ

Re: Flink native k8s integration vs. operator

ol > containers such as Spring. I only used javax annotations (soon to be > jakarta), so it’s not tied to Spring. > > > > Something I haven’t considered at all in my code is ingress for Flink’s UI. > > > > Let me know what you think. > > > > [1] > https:

RE: Flink native k8s integration vs. operator

: Xintong Song ; user Subject: Re: Flink native k8s integration vs. operator Hi Yang! Thanks for the input! I agree with you on both points that you made. Even if we might support both standalone and native modes in the long run, we should probably build the first version on top of the native

Re: Flink native k8s integration vs. operator

Hi Yang! Thanks for the input! I agree with you on both points that you made. Even if we might support both standalone and native modes in the long run, we should probably build the first version on top of the native integration. This I feel will result in a much simpler, minimalistic first

Re: Flink native k8s integration vs. operator

Glad to see that the interest of this thread keeps going. And thanks Thomas, Gyula, and Marton for driving this effort. I want to share my two cents about the Flink K8s operator. > Standalone deployment VS native K8s integration There is already some feature requirement issue[1] for the

Re: Flink native k8s integration vs. operator

Thanks for volunteering to drive this effort, Marton, Thomas and Gyula. Looking forward to the public discussion. Please feel free to reach out if there's anything you need from us. Thank you~ Xintong Song On Fri, Jan 14, 2022 at 8:27 AM Chenya Zhang wrote: > Thanks Thomas, Gyula, and

Re: Flink native k8s integration vs. operator

Thanks Thomas, Gyula, and Marton for driving this effort! It would greatly ease the adoption of Apache Flink on Kubernetes and help to address the current operational pain points as mentioned. Look forward to the proposal and more discussions! Best, Chenya On Thu, Jan 13, 2022 at 12:15 PM Márton

Re: Flink native k8s integration vs. operator

Hi All, I am pleased to see the level of enthusiasm and technical consideration already emerging in this thread. I wholeheartedly support building an operator and endorsing it via placing it under the Apache Flink umbrella (as a separate repository) as the current lack of it is clearly becoming

Re: Flink native k8s integration vs. operator

Hi Thomas, Yes, I was referring to a separate repository under Apache Flink. Cheers, Konstantin On Thu, Jan 13, 2022 at 6:19 AM Thomas Weise wrote: > Hi everyone, > > Thanks for the feedback and discussion. A few additional thoughts: > > [Konstantin] > With respect to common lifecycle

Re: Flink native k8s integration vs. operator

Hi everyone, Thanks for the feedback and discussion. A few additional thoughts: [Konstantin] > With respect to common lifecycle management operations: these features are > not available (within Apache Flink) for any of the other resource providers > (YARN, Standalone) either. From this

Re: Flink native k8s integration vs. operator

cc dev@ Hi Thomas, Hi everyone, Thank you for starting this discussion and sorry for chiming in late. I agree with Thomas' and David's assessment of Flink's "Native Kubernetes Integration", in particular, it does actually not integrate well with the Kubernetes ecosystem despite being called