Hi Lorenzo, Thanks for the FIP. I believe a dedicated Fluss Kubernetes Operator will further simplify deployment and operations in large-scale production environments.
I skimmed over the FIP. > We propose introducing a Fluss Kubernetes Operator, implemented in Java [...] 1. The first question that comes to my mind; are there already detailed plans regarding implementation? Do you plan to use the Java Operator SDK framework (https://javaoperatorsdk.io/)? Or just the plain fabric8 Java Kubernetes client (https://github.com/fabric8io/kubernetes-client)? 2. What will be the minimum supported Kubernetes version? Looking forward to this. Thanks. -- Best, Michael On 2026/05/05 09:05:45 Lorenzo Affetti via dev wrote: > Hello community! > > I would like to start a discussion about FIP-41: Fluss Kubernetes Operator. > Here is the motivation: > > Fluss 0.8 introduced a Helm chart > <https://github.com/apache/fluss/issues/779> that simplifies the initial > deployment of a Fluss cluster on Kubernetes by packaging manifests, > configuration, and dependencies into a versioned release. While this is a > good foundation, a Helm chart is fundamentally a one-shot templating tool. > It has no awareness of Fluss's runtime state and cannot react to > operational events such as pod failures, rolling upgrades, or scale-in > operations that risk data loss. > > Running Fluss in production on Kubernetes today requires users to manually > coordinate: > > - Safe rolling restarts of TabletServers, ensuring tablet leadership is > migrated before each pod terminates (Fluss 0.8 introduced the graceful > shutdown > <https://fluss.apache.org/docs/maintenance/operations/graceful-shutdown/> > primitive > that makes this possible, but does not orchestrate it across pods) > - Version upgrades that must sequence CoordinatorServer and TabletServer > updates correctly > - Scale-in operations where a TabletServer must be drained of tablets > before its pod is terminated > - Recovery from partial failures (e.g., PVC reattachment, pod identity > preservation across restarts) > - Leveraging Fluss 0.8's dynamic configuration updates > <https://fluss.apache.org/docs/maintenance/operations/updating-configs/> > for > keys that do not require restart, instead of triggering a rolling restart > for every config change > > This gap between deployment and operations is best addressed by a *Kubernetes > Operator* — a controller that continuously reconciles the desired state of > a FlussCluster resource against the actual state of the cluster, and > executes Fluss-aware transitions safely. > > The Flink and Spark ecosystems have established this pattern successfully > with the Apache Flink Kubernetes Operator > <https://github.com/apache/flink-kubernetes-operator> and the Apache Spark > Kubernetes Operator <https://github.com/apache/spark-kubernetes-operator>. > Fluss should follow suit. > > -- > Lorenzo Affetti > Team Leader of Stream Storage > [email protected] > www.ververica.com > ------------------------------ > > <https://www.ververica.com/> > Ververica GmbH | Herzogspitalstrasse 24 | 80331 München | Germany > > Follow us: > <https://www.linkedin.com/company/ververica/posts/?feedView=all> > <https://www.youtube.com/@ververica> > <https://open.spotify.com/show/2XME9h8iBOyr6YupqM99ir?si=87b064644add42a1>Available > on: <https://aws.amazon.com/marketplace/pp/prodview-luvmqd6leha4i> > <https://marketplace.microsoft.com/en-us/product/saas/ververica.vvc_managed?tab=Overview> > > Pflichtangaben/Mandatory Information > <https://www.ververica.com/mandatory-information> >
