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 > >
