Thanks @Robert Metzger for the explanation, Overall I think this is a good idea and hopefully we can reuse most of the controller flow that we already have. It would be nice to share the spec/status as much as reasonably possible.
Whether it should be a different CRD I think should depend on the overlap with the FlinkDeployment. If we are exposing essentially the same spec (podTemplate, jobSpec, flinkConfig, ingress..) then it feels like we should reuse the CRD and simply introduce a new deployment mode next to native and standalone. Cheers Gyula On Thu, Aug 20, 2026 at 11:26 AM Dale Lane <[email protected]> wrote: > > This bit that I added to the FLIP is perhaps worthy of a bit more scrutiny, > as it's based on my assumptions (misunderstandings?) of how the FKO project > works. > > In the section "Promoting MiniCluster to a stable API" I asserted: > > > For the Flink Kubernetes Operator project to provide a launcher > > as an example project would depend on the core Flink project > > promoting some MiniCluster components to @PublicEvolving ... > > This is not a technical requirement, as the current > > proof-of-concept demonstrates that the existing API is sufficient > > - the promotion recommended here is of MiniCluster’s existing > > submission surface. The requirement is about the Operator project > > managing risk by building upon a stable contract. ... > > Is that really a requirement or have I just invented that? :) > > Looking more closely at the existing code, I can see we already have plenty > of uses of flink-runtime classes that don't have @Public / @PublicEvolving > annotations, so my usage of flink-runtime classes like the MiniCluster and > MiniClusterConfiguration wouldn't be without precedent. > > While I still think it'd be lovely to build this feature solely on stable > APIs, maybe I'm creating an unreasonably high bar to clear by framing it this > so strongly. > > What do you think? What are the norms here? > > Kind regards > > Dale > -- > dalelane.co.uk > > > On Wednesday, 5 August 2026 at 16:02, Dale Lane > <[email protected]> wrote: > > > I'd like to start a discussion on > > FLIP-XXX : Running Flink jobs in MiniCluster using the Kubernetes Operator > > https://docs.google.com/document/d/1dtGjPYcsBkx1vxHPs1QnDtPxeH_Acz_pl8gx4b1BLB4/edit?usp=sharing > > > > The aim of the FLIP is to extend the Flink Kubernetes Operator to offer a > > single-pod, light-weight deployment option for low-throughput jobs. > > > > From the motivation: > > A single-pod, self-contained Flink job that starts fast and needs no > > multi-pod coordination could be a good fit for low-throughput jobs that > > aren't suitable for session clusters because they need isolation. > > > > Looking forward to feedback, both on the general motivation (Have you seen > > a need for very small lightweight Flink jobs where fast crash-consistent > > resume is good enough without a full distributed Flink cluster?) and the > > suggested implementation approach (Do you think a new custom resource kind > > is the best way to represent this capability?) > > > > Kind regards > > > > Dale > > -- > > dalelane.co.uk > >
