Thank you Gyula! > Is this actually solving a real production need compared to sizing down > TM/JMs to the minimum or is this more of an experimental / development tool.
I have implemented and deployed a Minicluster-based Flink deployment in production at a previous company. We've chosen that approach to have the smallest possible resource footprint. There were no production issues specific to the minicluster and it worked well. I'm talking to a lot of Flink users at my current company (Confluent), and I had one customer very strongly asking for this solution, as they can not deploy many small Flink SQL queries on a shared session cluster due to compliance reasons (financial services). Rather, they want each query in a separate Flink cluster. But the current minimums for a JobManager+TaskManager couple are around 2GB of memory. With minicluster, I was able to run Flink at 250MB, processing 100MB/s (For a simple filtering pipeline only. More operators will need more memory) https://speakerdeck.com/rmetzger/tiny-flink-minimizing-the-memory-footprint-of-apache-flink?slide=17 . I think Minicluster is closing an interesting sweet spot. And it is counter intuitive to run a stream proc framework that has been specifically designed for distributed, large-scale execution as small as possible ... but it allows users to cover a wide range of use cases with one technology. I'm not opposed to the idea of 2 Flink containers in a single pod. We would probably have Pekko RPC overhead between the two processes, and we need to pay the price for two JVMs. The heap to non-heap ratio in my experiments was 100mb to 150mb. So if we are able to split the heap into 2x 50mb, we'd have 2x50 + 2x150mb = 400mb (2containers) vs 250mb (minicluster). This feels like it defeats the purpose of providing a ultra-low memory footprint. I 100% agree that we should avoid the "standalone mode" situation. I am personally surprised by that information, because native mode requires a lot more permissions (JM needs to manage pods) than standalone mode (only CM creation permission for JM) ... and I would expect some Flink users to face issues from their internal security / k8s cluster ops teams. It's not like people are queuing up on the mailing list asking for the minicluster feature (which was the case for autoscaling) ... on the other hand, it's not an obvious idea. Maybe people will use it once it's there, because they couldn't imagine it. I think chances that Dale and I will talk about the feature at conferences / blogs are high. Best, Robert On Fri, Aug 14, 2026 at 3:33 PM Gyula Fóra <[email protected]> wrote: > I just had an offline discussion with Dennis and we have discussed an > alternative approach that could work instead of the MiniCluster. > > What if we would simply create 2 Flink containers in the single pod instead > of a single flink-main-container. > We could instead have: taskmanager-container, jobmanager-container > > This may need a new deploy/service integration similar to how standalone is > different from Native but otherwise almost all FlinkDeployment concepts and > spec remain intact and sensible. > > This way we also wouldn't try to promote something (minicluster) that is > clearly for local environments into a prod like env. > > Gyula > > On Fri, Aug 14, 2026 at 1:41 PM Gyula Fóra <[email protected]> wrote: > > > Hey All! > > > > I think this is an interesting proposal and I definitely see the > > theoretical whole it would fill, my main question is who would actually > use > > this in production? > > Is this actually solving a real production need compared to sizing down > > TM/JMs to the minimum or is this more of an experimental / development > tool. > > > > From an API / spec standpoint if this new mode requires different spec > > fields and a completely different submission path and specialized logic > to > > manage the jobs/upgrades etc > > then it would be better to have it as a completely separate CRD. The > spec > > already has a hierarchical structure and it would make sense to share as > > much as possible, jobspec, status parts etc. > > > > I agree that we have to consider autoscaler integration as well. > > > > One situation I would like to avoid is what we currently have with the > > standalone mode to some extent. The standalone mode has been added to > > support some older flink versions and specific environments but I think > > there is very little prod usage compared to the native, some things don't > > work at all by design etc. So we should only add this if we believe that > we > > are bringing true value here instead of just adding to our tech debt over > > time. > > Being able to scale down idle FlinkDeployments into miniclusters would > > actually be an interesting idea but that would also bring up some > questions > > related to the API, pushing toward a more unified approach. > > > > Cheers > > Gyula > > > > On Thu, Aug 13, 2026 at 5:11 PM Dennis-Mircea Ciupitu < > > [email protected]> wrote: > > > >> Hi Dale, all, > >> > >> Thanks for the FLIP, +1 on the motivation. To your first question: yes, > I > >> see this need regularly. Small or intermittent jobs that need isolation, > >> where the two-pod baseline dominates the actual cost of the job. > >> > >> On the open questions in the thread: > >> > >> 1. New kind vs extending FlinkDeployment (Robert's question): +1 for the > >> separate kind. Beyond the union-shaped spec, a `mode: minicluster` field > >> would turn a mode edit into an in-place topology migration inside the > >> reconciler of the operator's most critical API. The upgrade machinery > >> today > >> treats spec diffs as upgrades within one topology. Tearing down a single > >> pod and standing up a JM/TM pair mid-flight (or the reverse) is a > >> different, riskier operation, better kept out of FlinkDeployment. > >> > >> 2. Recovery semantics: I would give this its own section in the FLIP. > In a > >> single pod the JobManager dies with every failure, so the resume path is > >> always the same: pod restarts, launcher boots a fresh MiniCluster, HA > >> recovers the job. Three things worth pinning down: > >> * the job needs a fixed JobID, so checkpoint lineage survives pod > >> restarts > >> * the launcher behaviour when the dispatcher has already recovered the > >> job from HA: tolerate DuplicateJobSubmissionException, like > >> ApplicationDispatcherBootstrap does for application mode today > >> * what `upgradeMode: last-state` means when the whole cluster dies > with > >> the pod: HA metadata availability, and storage guidance (PVC vs object > >> storage) > >> > >> 3. Memory mapping: MiniClusterConfiguration applies > >> TaskExecutorResourceUtils.adjustForLocalExecution, so memory inside the > >> pod > >> does not follow the distributed TM model. The mapping from > spec.resources > >> to Flink memory settings is worth specifying, for sizing guidance now > and > >> for tuning later. > >> > >> 4. On Robert's autoscaler question, the two halves differ: > >> * Parallelism: the overrides are realized generically today (they land > >> in > >> spec.flinkConfiguration), and MiniCluster itself can run parallelism > > 1. > >> But in-place rescaling in the operator requires the adaptive scheduler > and > >> updates resource requirements over REST, and that path is only wired for > >> the native service today. Even wired up, a single pod bounds it: slots > are > >> fixed at boot and the pod's CPU/memory are the ceiling. In practice a > >> parallelism decision for a MiniCluster job translates into a full pod > >> redeploy until in-process rescaling is supported end to end, and beyond > >> the > >> pod's capacity it becomes a promotion (point 5). > >> * Vertical: for a one-pod topology, right-sizing the pod is the lever > >> that actually matters, and it needs a tuning decision with its own > >> trigger, > >> decoupled from scaling decisions. That is exactly the decoupling I'm > >> proposing in [1]. FlinkMiniCluster would be a natural future consumer of > >> that decision point, with no new scope for either proposal. > >> > >> 5. Automatic transitions: I have spent some time researching > >> cross-topology > >> moves. JobID regeneration on restore, per-cluster HA metadata, and the > >> differing jar distribution models make this a savepoint-boundary > >> orchestration problem, not an in-place mutation. I think it belongs in a > >> separate orchestrator kind in the same way as FlinkBlueGreenDeployment > >> (transition state machine in status, owning the children it creates), > >> building on exactly the manual migration workflow this FLIP defines. I > >> would be happy to draft that follow-up FLIP once this one lands. So +1 > >> also > >> on keeping automatic promotion out of scope here. > >> > >> 6. Launcher and version support: I would go one step further than the > >> pre-2.4 / 2.4 split. Make Flink 2.4 the minimum supported version for > >> FlinkMiniCluster in the operator, so operator support begins exactly > where > >> the promoted API and the core launcher exist. That removes the separate > >> per-version compatibility tracking the test plan describes, gives one > >> clean > >> contract (flinkVersion >= v2_4, enforced at validation), and matches how > >> other operator features are version-gated already (in-place rescaling > >> requires 1.18+). Example code can still serve pre-2.4 experimentation, > >> just > >> outside the operator's supported surface. > >> > >> [1] https://lists.apache.org/thread/vk6j8793rx2y78vhh1yvfjf4qntpfkm9 > >> > >> Best regards, > >> Dennis > >> > >> On Thu, Aug 13, 2026 at 12:01 PM 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 > >> > > > >> > > > >> > > >> > > >
