re: jobManagerDeploymentStatus -> podDeploymentStatus Yeah, that makes sense - I've updated that, thanks.
re: MiniCluster launcher I've fleshed that out more. I think if the MiniCluster classes were promoted as I've described in the updated paragraph, the remaining launcher logic becomes very small, so I think that makes it more reasonable to keep the launcher as an example (in the vein of the existing SQL launcher). Kind regards D -- dalelane.co.uk On Thursday, 13 August 2026 at 10:01, Robert Metzger <[email protected]> wrote: > Thanks a lot for kicking off a discussion on adding this to the Kubernetes > Operator! I've seen many Flink users who would benefit from this. > > Some comments: > * " jobManagerDeploymentStatus: READY" --> is "jobManagerDeploymentStatus" > still a good name within "kind: FlinkMiniCluster"? how about > miniClusterPodDeploymentStatus? I do like the idea of reusing the entire > status field. It's difficult :) But If you are going to propose to > introduce a new CR for FlinkMiniCluster for the purpose of having it > properly typed, then we should go all in? > * on the "Flink MiniCluster launcher: Or this could be a bootstrap class > added to core Flink, so that it is available out of the box in a regular > Flink image.": The proposal is fairly vague here. How about we provide the > required example code for pre-Flink 2.4? versions, and starting from 2.4 we > add the launcher to core and it works out of the box? > * It would be really nice to consider how hard it would be to integrate > this with the autoscaler, so that the autoscaler can scale down into a > minicluster, our out of the minicluster into a full cluster? Not using a > dedicated FlinkMiniCluster CR, but further extending the FlinkDeployment CR > would potentially make that easier? ... however, in that case, the > semantics of jobManager / taskManager resources would be messed up -- > because suddenly when transitioning from a regular Flink cluster to a > MiniCluster, the meaning of either a job manager or taskmanager resource > would change. We could introduce a 3rd "miniCluster" field for the > resources? It would probably be most elegant if the autoscaler could do the > transition from FlinkDeployment to FlinkMiniCluster automagically? > > CCing Gyula for additional feedback > > On Wed, Aug 5, 2026 at 5:11 PM 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 > > > > >
