Scored on six weighted criteria explained below the rankings, Flex ranks first of five tools for teams running Apache Flink on Kubernetes with 83 out of 100, ahead of Ververica Platform at 63, the Flink Kubernetes Operator at 59, Prometheus with Grafana at 47 and the Apache Flink Web UI at 41. A tool for these teams has to give each engineer control over each job, hold production changes for approval and show every cluster in one place, while staying out of the path between jobs and their sources and sinks, beside the Flink Kubernetes Operator that deploys the jobs. Each option covers part of that, and the operator is a deployment tool rather than a management UI.
Tools compared
| Rank | Tool | Total (out of 100) | Governance per person and job | One view across clusters | Out of the data path | Job lifecycle | Inspecting running jobs | Getting metrics out | Cost a year (modelled) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Flex | 83 | RBAC per job, approvals, expiring access, tenants, SSO, audit | Every cluster in one UI | One pod, no external database | Submit, stop, cancel, savepoint | Topology, backpressure, watermarks, checkpoints | One Prometheus endpoint, webhooks | $6,830 |
| 2 | Ververica Platform | 63 | Namespace roles, SSO, 180-day audit; no approvals | One UI per installation | Platform with its own database | Desired state, upgrades, Autopilot | Links to the Flink Web UI | Bundled reporters | $5,760 before the licence |
| 3 | Flink Kubernetes Operator | 59 | Kubernetes RBAC on resources; no approvals | Resources in one Kubernetes cluster | One deployment, no external database | Desired state, upgrade modes, autoscaler | Resource status and events | Default reporter configuration | $2,880 |
| 4 | Prometheus and Grafana | 47 | Dashboard access only | Every scraped cluster | Self-hosted, own time-series store | None | Metrics over time | Alerting and dashboards | $14,400 |
| 5 | Apache Flink Web UI | 41 | None of its own | One cluster per UI | Built into the JobManager | Upload, start, cancel | The reference views | Current values only | $0 extra |
The tools, ranked for Flink on Kubernetes
Rank 1 Flex
83 out of 100 Total
- Cost a year
- Enterprise from $3,950 per cluster a year with no per-seat fee, plus about $2,880 in operator time, so $6,830 on one licence (modelled)
- On Kubernetes
- Helm chart, one pod, no external database
- Flink support
- Any cluster reachable through v1 of the Flink REST API
- Governance per person and job ×3 weight, this criterion counts 3 times toward the total
- 8 out of 10
- One view across clusters ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Job lifecycle
- 8 out of 10
- Inspecting running jobs
- 8 out of 10
- Getting metrics out
- 7 out of 10
Why these scores for Flex
- Governance per person and job 8 out of 10
- Flex documents RBAC that allows, denies or stages each Flink action (submit, edit, terminate, delete a JAR) per role and per job, tenants that limit a team to its own jobs and JARs, temporary policies that expire, sign-in through SAML, OIDC or LDAP, and an audit log that names the person. It scores below 10 because the audit log is held in memory and shown for seven days, and is kept longer only by sending it on through a webhook.
- One view across clusters 9 out of 10
- Each cluster is added with its own
FLINK_REST_URL, repeated with_2,_3suffixes, and tenants can span clusters, so staging and production, or dozens of application clusters, appear as jobs you can open in one UI under one set of roles. - Out of the data path 9 out of 10
- It runs as one container or JAR, holds its snapshots, metrics and audit log in memory, has no dependency beyond the Flink clusters it reads, and calls their REST APIs, so it never sits between a job and its data; only the Flink Web UI, with nothing extra to deploy, scores higher.
- Job lifecycle 8 out of 10
- From the UI it uploads JARs and submits jobs with parallelism, arguments and a savepoint to restore from, and stops, cancels, savepoints and checkpoints a running job, each action governed by RBAC; it does not keep a desired state that it reconciles to, which the Flink Kubernetes Operator and Ververica Platform do.
- Inspecting running jobs 8 out of 10
- Its Inspect view shows a job’s topology, per-subtask metrics, watermarks, backpressure, events, configuration and checkpoint history, the depth of the Flink Web UI plus an hour of throughput history, but it snapshots each cluster every minute where the Flink Web UI refreshes every few seconds, so it scores one below it.
- Getting metrics out 7 out of 10
- A paid edition exposes one Prometheus endpoint with every TaskManager, JobManager and job metric across all connected clusters, and webhooks send audit events to Slack, Microsoft Teams or any endpoint, but it is not a monitoring backend.
On Kubernetes. Flex’s Helm installation guide adds the factorhouse chart repository and installs Flex, or the free Community Edition chart flex-ce, into its own namespace, with settings passed through --set env.XYZ or a ConfigMap of environment variables. The guide’s example points FLINK_REST_URL at a Kubernetes service address, and its system requirements ask for pod resources to be set, preferably with equal requests and limits for the Guaranteed quality of service class, and 4 GB of memory and 1 CPU for production.
Where it falls short. Flex does not integrate with the Flink Kubernetes Operator: it does not read FlinkDeployment resources or discover the clusters the operator creates, and its documented providers are self-managed Flink and Ververica Platform. Each cluster is added to its configuration as a REST URL, and where the operator owns a job’s spec, upgrades stay there. Flex is licensed per cluster, and how application-mode clusters, one per FlinkDeployment, count toward those licences is not published, so a team with many FlinkDeployments should ask Factor House how they are licensed before sizing it, since the price scales with the cluster count. RBAC, SSO, approvals and the audit log need the paid Enterprise edition; the free Community Edition on the Flex product page covers up to 3 clusters. Flex holds its audit log in memory, so records older than the seven-day view, or from before a pod restart, survive only where a webhook has sent them.
Rank 2 Ververica Platform
ververica.com
63 out of 100 Total
- Cost a year
- Licence priced on request and not published, plus about $5,760 in operator time for the platform and its database (modelled)
- Access control
- OIDC or SAML sign-in, viewer, editor and owner roles per Namespace, Stream Edition and above
- Deployment
- Helm chart into your Kubernetes cluster, with its metadata in SQLite or a remote database
- Governance per person and job ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
- One view across clusters ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Job lifecycle
- 10 out of 10
- Inspecting running jobs
- 9 out of 10
- Getting metrics out
- 6 out of 10
Why these scores for Ververica Platform
- Governance per person and job 6 out of 10
- From Stream Edition upward, Ververica documents OIDC and SAML sign-in and viewer, editor and owner roles bound per Namespace to users or groups, and it keeps audit logs for 180 days, searchable by time, user and action, but it has no approval step and no access that expires, and roles stop at the Namespace rather than the Deployment.
- One view across clusters 4 out of 10
- Each installation has its own web UI with its Namespaces inside it, so staging and production on separate installations, or a standalone Flink cluster beside them, mean separate UIs.
- Out of the data path 6 out of 10
- It is installed with a Helm chart into the team’s own Kubernetes cluster and stays out of the jobs’ data, but its configuration page says it persists its metadata through JDBC, in a remote database or locally in SQLite, the grade this criterion gives a tool with one database.
- Job lifecycle 10 out of 10
- Deployments are its core resource, and the platform reconciles each job to its desired state of running, suspended or cancelled, upgrades it with savepoint-based upgrade and restore strategies, and Autopilot tunes resources from Stream Edition upward, the best on this page beside the Flink Kubernetes Operator.
- Inspecting running jobs 9 out of 10
- Each Deployment links to the Apache Flink Web UI for its running job, alongside the Deployment’s own event log.
- Getting metrics out 6 out of 10
- It bundles reporters for Prometheus, Datadog, InfluxDB and others, set per Deployment in the Flink configuration, and can link a Deployment to a Grafana dashboard, while alerting stays in the monitoring stack.
What it covers. Ververica Platform 2 is installed from Ververica’s Helm chart into a Kubernetes namespace. A Deployment is its resource for a Flink job: you set its desired state and template, and the platform starts, upgrades, suspends and restores the job to match. Authorization binds preset viewer, editor and owner roles per Namespace, and audit logs are kept for 180 days. A team already on it is better served by the best Flink tools for Ververica Platform.
Where it falls short. Its configuration page says the platform persists its metadata in a remote database or locally in SQLite, with remote database persistence available in Stream Edition and above, so it adds a database to run and back up. Access control is available in Stream Edition and above, so Community Edition has no sign-in or roles. Ververica does not publish its prices. Adopting it means moving jobs onto its Deployment resource rather than keeping them as plain Flink on Kubernetes.
Rank 3 Flink Kubernetes Operator
59 out of 100 Total
- Cost a year
- $0 licence, about $2,880 in operator time (modelled)
- What it is
- A deployment operator for Flink custom resources, not a management UI
- Access control
- Kubernetes RBAC on its custom resources; none of its own for people
- Governance per person and job ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
- One view across clusters ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Job lifecycle
- 10 out of 10
- Inspecting running jobs
- 3 out of 10
- Getting metrics out
- 5 out of 10
Why these scores for Flink Kubernetes Operator
- Governance per person and job 5 out of 10
- Its RBAC model covers two service accounts, one for the operator and one for the jobs, not the people who change jobs. Who may change a job is whoever Kubernetes RBAC lets edit its FlinkDeployment, which can be scoped per namespace and per resource and bound to users or groups, but Kubernetes roles are purely additive with no deny rule, there is no approval step or access that expires, and the API server records who changed a resource only when an audit policy is set, so it sits in the band for support that needs work the reader must verify.
- One view across clusters 4 out of 10
- Cluster-scoped by default, one operator handles every FlinkDeployment in its Kubernetes cluster, and they can be listed together as Kubernetes resources with their status, but as resources in a terminal rather than jobs you can open, and the operator works within the one Kubernetes cluster it is installed in.
- Out of the data path 9 out of 10
- It runs as one deployment inside the Kubernetes cluster, keeps what it tracks in the resource status and in ConfigMaps rather than an external database, and reaches the Flink clusters through their REST endpoints, so it never sits between a job and its data; 10 is kept for an option with nothing to deploy.
- Job lifecycle 10 out of 10
- Lifecycle is what the operator exists for, since a job is declared as a custom resource and the operator reconciles toward it, with stateless, last-state and savepoint upgrade modes, rollbacks for failed upgrades, restarts of unhealthy jobs, declarative savepoints, blue/green deployments and an autoscaler, the best on this page beside Ververica Platform.
- Inspecting running jobs 3 out of 10
- It has no UI of its own, so a job’s state appears in the resource status, Kubernetes events trace deployments, upgrades, snapshots and scaling decisions, and it can generate an Ingress per resource so that people reach the Flink Web UI, where inspection happens.
- Getting metrics out 5 out of 10
- Its own metrics, built on Flink’s metric system with pluggable reporters, cover the resources it manages and its Kubernetes API calls, and its default Flink configuration with per-job overrides is one place to set reporters for every job, while alerting stays in the monitoring stack.
What it covers. The Flink Kubernetes Operator follows the Kubernetes operator pattern: a Flink application or session cluster is declared as a custom resource, and the operator reconciles the running cluster toward it. Its job management page describes suspending and resuming as spec updates through state: suspended, and upgrades through spec.job.upgradeMode. It is a deployment operator rather than a management UI: people work with it through kubectl, Helm or a GitOps pipeline, and look at running jobs in the Flink Web UI.
Where it falls short. It has no users, roles or audit of its own; its RBAC page describes the service accounts it and its jobs run as, and governance of people comes from Kubernetes. Deleting a FlinkDeployment removes its status together with the tracked checkpoint history, and a later redeployment starts from empty state unless a starting snapshot is set, so the right to delete the resource is the right to lose a job’s place in its state.
Rank 4 Prometheus and Grafana
prometheus.io
47 out of 100 Total
- Cost a year
- $0 licence, about $14,400 in operator time (modelled)
- Access control
- Grafana roles over dashboards, not over Flink jobs
- Deployment
- Prometheus with its own time-series store, plus Grafana
- Governance per person and job ×3 weight, this criterion counts 3 times toward the total
- 2 out of 10
- One view across clusters ×2 weight, this criterion counts 2 times toward the total
- 7 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Job lifecycle
- 1 out of 10
- Inspecting running jobs
- 5 out of 10
- Getting metrics out
- 9 out of 10
Why these scores for Prometheus and Grafana
- Governance per person and job 2 out of 10
- Grafana’s roles and permissions govern who sees which dashboard, and neither tool can act on a Flink job, so there is nothing to approve and no record of job actions.
- One view across clusters 7 out of 10
- Prometheus scrapes every cluster that has the reporter switched on, so one set of dashboards spans them, as metrics rather than as jobs you can open.
- Out of the data path 6 out of 10
- Both are self-hosted, and Prometheus keeps a time-series database of its own, the grade this criterion gives a tool with one database.
- Job lifecycle 1 out of 10
- Neither tool can submit, stop or cancel a job.
- Inspecting running jobs 5 out of 10
- Dashboards show throughput, lag, checkpoint duration and backpressure metrics over time, but not the job graph or a checkpoint’s detail.
- Getting metrics out 9 out of 10
- Prometheus with Alertmanager and Grafana is the most common place Flink metrics end up, through Flink’s own Prometheus reporter.
What it covers. Flink’s Prometheus reporter exposes job, TaskManager and JobManager metrics on port 9249, and the Flink Kubernetes Operator’s metrics page describes how Prometheus labels its own metrics by namespace and resource. Grafana’s roles and permissions control access to the dashboards, and Factor House publishes a Grafana dashboard for a Flink cluster, built on Flex’s metrics, in its factor-telemetry repository.
Where it falls short. It is a monitoring stack rather than a Flink tool: it cannot open a job, take a savepoint or stop anything, and its running cost is modelled at 10 engineer-hours a month, $14,400 a year at $120 an hour, the figure Factor House’s other pages use for a metrics stack assembled from parts.
Rank 5 Apache Flink Web UI
41 out of 100 Total
- Cost a year
- $0, served by each JobManager (modelled at $0 extra)
- Access control
- None of its own
- On Kubernetes
- A ClusterIP service per cluster, reached by port-forward or Ingress
- Governance per person and job ×3 weight, this criterion counts 3 times toward the total
- 1 out of 10
- One view across clusters ×2 weight, this criterion counts 2 times toward the total
- 1 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 10 out of 10
- Job lifecycle
- 5 out of 10
- Inspecting running jobs
- 9 out of 10
- Getting metrics out
- 2 out of 10
Why these scores for Apache Flink Web UI
- Governance per person and job 1 out of 10
- Flink’s REST endpoint and web UI can be secured with SSL and mutual authentication but have no users or roles of their own, and uploading, starting and cancelling jobs are switched on by default, so anyone who reaches the UI can run or stop a job unless a proxy in front decides otherwise.
- One view across clusters 1 out of 10
- Each JobManager serves its own web UI for its own cluster, so a team with twenty application-mode FlinkDeployments has twenty UIs.
- Out of the data path 10 out of 10
- It is served by the JobManager itself, with nothing to deploy.
- Job lifecycle 5 out of 10
- It can upload a JAR, start a job with a savepoint to restore from, and cancel a job; stopping with a savepoint and triggering savepoints go through the REST API or the command line.
- Inspecting running jobs 9 out of 10
- The job graph, backpressure, checkpoint history and TaskManager views are the reference that the other tools here reproduce.
- Getting metrics out 2 out of 10
- It shows current metrics for one job but keeps no history, and metrics leave the cluster through Flink’s reporters rather than through the UI.
What it covers. Flink’s web UI shows each running job’s graph, backpressure per task and checkpoint history, served from the same REST API that Flex and the Flink Kubernetes Operator read. On Kubernetes, Flink’s native Kubernetes guide exposes it as a ClusterIP service by default, reached with kubectl port-forward, and the operator can generate an Ingress per resource.
Where it falls short. It sees one cluster at a time, keeps no history, and has no users of its own; the REST endpoint can be secured with SSL, which authenticates machines rather than people. Flink’s native Kubernetes guide warns that exposing it as a LoadBalancer service might make the cluster accessible publicly, usually with the ability to execute arbitrary code.
What teams running Flink on Kubernetes need
This page is about teams that run open-source Apache Flink on their own Kubernetes clusters, usually through the Flink Kubernetes Operator and sometimes through Flink’s native Kubernetes integration, rather than on a managed Flink service. Teams running Flink standalone or on YARN are covered by the best Flink tools for self-managed Apache Flink, and teams already on Ververica Platform by the best Flink tools for Ververica Platform. For the engine itself, see Apache Flink: the complete guide.
On Kubernetes the deployment layer is usually settled before a management tool is chosen. The Flink Kubernetes Operator declares each Flink application as a custom resource and reconciles the running cluster toward it, and its overview says a single instance is built to manage hundreds or thousands of pipelines. What it does not add is a place for people to work: it has no UI, no users and no record of who did what. The question this page answers is what sits beside it.
Governance per person and job
Flink’s security model states that running arbitrary code through a submitted JAR, DataStream program or UDF is by design, so whoever may submit a job can run code on the cluster. On Kubernetes, the operator’s RBAC page covers the service accounts the operator and the jobs run as, not people, so the right to change a job is the right to edit its FlinkDeployment.
Kubernetes can scope that per namespace and per resource, but its RBAC documentation says permissions are purely additive, with no deny rules, so a team cannot grant broad edit rights in a namespace and then carve out its most sensitive job. Nor does Kubernetes hold a change for a second person’s approval or grant access that expires. A tool with its own Allow, Deny and Stage decisions per job fills that gap for the actions taken through it, which is why this criterion carries the most weight.
An audit trail that names the person
Kubernetes auditing can answer who initiated a change and on what, but the API server logs nothing unless it is started with an audit policy file. Flink itself records no user. A management tool that keeps its own record of each action, with the person from the identity provider, gives the team an answer that does not depend on how the cluster was set up.
Deleting a job is a state decision
The operator’s job management page says deleting a FlinkDeployment removes its status together with the tracked checkpoint history, and that a later redeployment starts from empty state unless a starting snapshot is set explicitly. On a stateful pipeline, kubectl delete is therefore closer to dropping a table than to stopping a process, and the people allowed to do it in production deserve the same scrutiny. When restarts rather than deletions are the problem, why a Flink job keeps restarting walks through the causes.
One view across clusters
Flink’s native Kubernetes guide recommends application mode for production because it isolates applications better, and an application-mode FlinkDeployment is a Flink cluster of its own, with its own JobManager, web UI and REST endpoint. Twenty pipelines are twenty web UIs, and separate Kubernetes clusters for development, staging and production multiply them again. A tool scores well here when it shows every cluster and every job together, with one set of roles across them.
Out of the data path, and inside the cluster
Flink jobs read from their sources and write to their sinks directly from their pods. The operator’s security page says the Flink REST endpoint is only reachable inside the Kubernetes cluster by default, and that exposing it is an explicit choice.
Reaching the UI without exposing Flink
That default shapes the choice of tool. A web UI reached from a laptop needs either kubectl port-forward, which means granting each engineer rights on the Kubernetes API in that namespace, or an exposed service, and Flink’s native Kubernetes guide warns that a LoadBalancer service might make the cluster accessible publicly, usually with the ability to execute arbitrary code. A tool that runs as a pod in the same cluster reaches each REST service by its internal address, so nothing is exposed and the network review lists the Flink REST endpoints and nothing on the data side.
Staying off the jobs’ path
Flink’s REST API documentation describes the monitoring API as the one Flink’s own dashboard uses and one designed for custom monitoring tools. A tool that only reads it is not a hop that records pass through, and nothing is installed inside the jobs or on the Flink cluster, so a fault in the tool does not become a fault in a pipeline.
A second store to secure
A tool that brings its own database adds one more thing to back up, patch and bring into an audit. Ververica Platform’s configuration page says it persists its metadata through JDBC, in a remote database or locally in SQLite, and Prometheus keeps a time-series store. Flex’s system requirements say its snapshots, metrics and audit log are held in memory and that it needs nothing beyond at least one Flink cluster, which is why it scores 9 on this criterion and why its audit log has to be sent on by webhook to outlive a pod restart.
Job lifecycle
The operator controls how a job is stopped and restored through spec.job.upgradeMode, with three values, stateless, last-state and savepoint, and rejects a stateful upgrade mode with no checkpoint or savepoint directory configured. Where the operator or a GitOps pipeline owns a job’s desired state, changes belong in that spec, and a management tool is used to watch the job and govern who may act on it. Lifecycle counts once for that reason.
Inspecting running jobs
Debugging a stuck task means reading per-subtask backpressure, watermarks and checkpoint history. On Kubernetes, the Flink Web UI that shows them lives behind a port-forward or an Ingress per cluster, and keeps no history once a job is gone.
Getting metrics out
Flink’s Prometheus reporter listens on port 9249 by default, and the operator’s default Flink configuration is one place to switch it on for every job. The criterion scores how well a tool gets job metrics to the alerting the team already runs.
Where Flex adds least
A team with one FlinkDeployment, one team using it, GitOps review on every change and no need for expiring access or a per-person record of actions will find the operator plus the Flink Web UI behind an Ingress covers most of what it needs. A team that wants one vendor platform for deploying and upgrading jobs will find Ververica Platform stronger on lifecycle. Flex adds most where several teams share Flink on Kubernetes, where application mode has multiplied the clusters, and where the team has to show who may stop which job and who approved it.
Who runs Flex on Kubernetes
No Factor House customer has yet described running Flex beside Flink on Kubernetes in public, so this page names none. The pattern this page scores is a central team running Flink for many application teams. Netflix and Uber are described from their engineers’ own posts and talks in the Apache Flink use cases on this site, and are cited as examples of that pattern, not as Flex customers. On Kubernetes specifically, a Lyft engineer’s QCon London talk describes moving from one shared cluster for every Flink job to dedicated JobManager and TaskManager pods for each application, the one-cluster-per-application shape that application mode gives, and Lyft’s use case covers its later move to the Flink Kubernetes Operator. Lyft is not a Flex customer either. Flex reads Flink’s REST API and does not modify or extend Flink itself, as Introducing Factor House 2.0 describes.
How a team runs Flink on Kubernetes with Flex
Installing it with Helm
A team adds the Factor House chart repository and installs Flex into its own namespace, following the Helm installation guide, with the licence and FLINK_REST_URL passed through --set env.XYZ or, more maintainably, a ConfigMap referenced by envFromConfigMap. The guide’s notes reach the UI with a port-forward to port 3000 for a first test; a team then puts its usual Ingress and TLS in front of the Flex service, so engineers reach Flex rather than each Flink cluster. Flex’s system requirements ask for pod resources to be set, preferably with requests equal to limits so the pod gets the Guaranteed quality of service class, and recommend 4 GB of memory and 1 CPU for production. They also say Flex should run close to the Flink clusters, and that multi-region installations are not officially supported, so a team with Kubernetes clusters in several regions plans one Flex per region.
Connecting each cluster
Each Flink cluster is one FLINK_REST_URL, with an optional FLINK_ENVIRONMENT_NAME that labels it in the UI, and further clusters repeat the settings with _2, _3 suffixes, as in the Flink cluster configuration. The Helm guide’s example uses a Kubernetes service address, so the REST endpoints stay internal to the cluster. Flex does not discover FlinkDeployments or read the operator’s resources: each cluster is added to its configuration, and with many clusters the same page says memory and CPU may need to rise so that each snapshot cycle finishes within thirty seconds.
Signing people in
Engineers sign in to Flex through SAML, OpenID Connect or LDAP, and their directory groups map to Flex roles. Those engineers need no rights on the Kubernetes API to see or act on a job, which keeps kubectl access for the platform team.
Scoping each team to its own jobs
RBAC policies grant each role Allow, Deny or Stage on the four Flink actions, FLINK_SUBMIT, FLINK_JOB_EDIT, FLINK_JOB_TERMINATE and FLINK_JAR_DELETE, for any cluster, a single cluster or a named job. Unlike Kubernetes RBAC, a Deny can carve one job out of a broader grant. Tenants include or exclude jobs and JARs by name, prefix or suffix, and whole clusters, so a tenant on payments* shows the payments team its own jobs in every environment and nothing else. Using the same prefix for the FlinkDeployment name and the Flink job name keeps those rules short.
Inspecting a job
The Jobs view shows a job’s topology with per-subtask metrics, watermarks and backpressure levels, its lifecycle events, its configuration and its checkpoint history, plus an hour of throughput graphs, and the cluster overview shows available and total task slots, TaskManager count and running, finished, cancelled and failed jobs, which on Kubernetes is the quickest check that the TaskManager pods a job asked for actually arrived.
Keeping changes where they belong
Where the Flink Kubernetes Operator owns a job’s spec, upgrades, suspensions and deletions stay in that spec and the pipeline that applies it, and Flex is used to inspect the job and govern who may act on it through Flex. Where jobs are submitted to a session cluster rather than declared as resources, Flex’s Jobs view uploads a JAR and submits it with an entry class, parallelism, arguments and a savepoint path, and stops, cancels, savepoints or checkpoints a running job.
Putting a person between a request and production
A policy with the Stage effect turns an action taken in Flex, such as terminating a production job, into a request that an admin approves or denies in Flex’s staged mutations view. Temporary policies grant a role extra rights for a set time. Because the Flink REST API and the Kubernetes API stay open to whoever holds rights on them, these controls hold when Kubernetes network policies and roles leave Flex, the operator and the platform team as the only paths to the REST endpoints and the FlinkDeployments.
Keeping the record
The audit log records each action with the user from the identity provider, the request and the policies that allowed or denied it, and shows the last seven days in the UI. Because Flex holds it in memory, a webhook that sends each record to Slack, Microsoft Teams or any HTTP endpoint is how a team keeps it past a pod restart or beyond seven days.
Alerting
Flex exposes every TaskManager, JobManager and job metric on one Prometheus endpoint, across all connected clusters, for the alerting the team already runs. The endpoint is not secured by default, and setting a username and password puts basic authentication on it.
Running Kafka beside it
Factor House builds Kpow for Apache Kafka on the same model, so a team running Kafka beside Flink on Kubernetes can connect both to the same identity provider and write the same kind of RBAC policies for both; the Kafka side is compared in the best Kafka tools for self-managed Apache Kafka. Factor Platform brings Kpow and Flex together as one control plane for Kafka and Flink.
FAQ
What is the best Flink management tool for Flink on Kubernetes?
On this page’s rubric, Flex ranks first with 83 out of 100, ahead of Ververica Platform at 63 and the Flink Kubernetes Operator at 59. Flex leads on governance per person and job, with roles per job, approvals, expiring access and an audit log that names the person, and on one view across every cluster, from one pod outside the data path. The operator and Ververica Platform lead on job lifecycle.
Is the Flink Kubernetes Operator a management UI?
No. It is a Kubernetes operator that deploys and upgrades Flink clusters from custom resources and reconciles them toward their declared state. It has no UI or users of its own; people work with it through kubectl, Helm or GitOps, and look at running jobs in the Flink Web UI, which the operator can expose through an Ingress.
Does Flex integrate with the Flink Kubernetes Operator?
No. Flex does not read FlinkDeployment resources or discover the clusters the operator creates, and its documented providers are self-managed Flink and Ververica Platform. Flex connects to Flink clusters through REST URLs set in its configuration, and where the operator owns a job’s spec, upgrades belong in that spec.
How do engineers reach the Flink Web UI on Kubernetes?
Flink’s native Kubernetes guide exposes the REST endpoint and web UI as a ClusterIP service by default, reached with kubectl port-forward, and offers NodePort and LoadBalancer types, warning that a LoadBalancer might make the cluster publicly accessible. The operator can generate an Ingress per FlinkDeployment. A tool that runs inside the cluster, such as Flex, reaches the REST services internally and puts its own sign-in in front of them.
Can Kubernetes RBAC stop one person deleting one Flink job?
Only by never granting that right. Kubernetes RBAC permissions are purely additive, with no deny rules, so restricting one FlinkDeployment means writing roles that list every other resource a person may change. It has no approval step either. Flex’s RBAC adds Deny and Stage per job for the actions taken through Flex.
Is Flex free to try on Kubernetes?
Yes. The Helm guide installs the free Community Edition from the flex-ce chart, which covers up to 3 clusters, per the Flex product page. Roles, SSO, approvals and the audit log need the paid Enterprise edition.
How these tools were scored
Four of the six criteria start from the Apache Flink, Flink Kubernetes Operator and Kubernetes documentation; the other two are where the tool runs and what it does with metrics. They are listed here in order of weight. Each criterion is scored 0 to 10: 10 where a tool is the only one here doing it or clearly the best, 8 for a clean documented pass, 5 or 6 for partial support or support that needs work the reader must verify, 1 to 4 for a weak or indirect form, and 0 where it is absent. Weights add up to 10, so totals are out of 100. The rubric and the scores of Flex, Prometheus and Grafana and the Apache Flink Web UI are the same as on the best Flink tools for self-managed Apache Flink. Ververica Platform carries the scores the Ververica Platform page gives its web UI on every criterion but one: there it is already running and scores 10 for out of the data path, while here it is a platform a team would install, with a metadata database of its own, and scores 6. That database is the only reason for the difference. The Flink Kubernetes Operator is on neither sibling page and is scored here on the same ladders from its own documentation.
1. Governance per person and job (counts three times). Flink has no users of its own, and on Kubernetes the right to change a job is the right to edit a resource under roles that only add permissions. This criterion scores what a tool adds for the people working through it: roles per person and per job, production access granted on request and expiring, an approval step before a job is stopped or deleted, directory sign-in, tenants for teams sharing clusters, and an audit trail that names the person. The requirements regulated teams bring are covered in Kafka governance tools for financial services.
2. One view across clusters (counts twice). Where application mode gives each FlinkDeployment a cluster, or a team runs separate Kubernetes clusters for each environment, a tool scores well when it shows them together, as jobs you can open, with one set of roles across them.
3. Out of the data path (counts twice). The tool should run inside your environment, reach the Flink clusters over their REST APIs, and keep no data outside your own infrastructure. Scored lower: tools that need an external database of their own, and tools whose data leaves for a hosted service or that need a component on every node. A self-hosted container with no external database and no proxy scores 9, a tool with a database of its own 6, one with several databases or a component on every node 4, and one that needs both a database and a proxy for its controls 3; 10 is kept for an option with nothing to deploy at all, here the Flink Web UI. The same ladder is used on the best Flink tools for self-managed Apache Flink, where Flex, Prometheus and Grafana and the Flink Web UI carry the same scores.
4. Job lifecycle (counts once). Submitting a job, restoring it from a savepoint, stopping it with a savepoint, cancelling it, and for operators and platforms, reconciling it to a declared state. It counts once because on Kubernetes this already belongs to the Flink Kubernetes Operator or a GitOps pipeline.
5. Inspecting running jobs (counts once). Reading a job’s graph, backpressure, watermarks and checkpoint history is the day-to-day debugging work, and the Flink Web UI is the reference.
6. Getting metrics out (counts once). Flink’s metric reporters send job metrics to a monitoring system. This criterion scores how well a tool gets them to the alerting a team already runs.
Costs are modelled for 25 engineers and 10 Kubernetes nodes running Flink, at $120 per engineer hour, using assumed hours a month per tool class that are modelling assumptions rather than measurements. Tools with a licence carry the published price plus 2 hours a month to run. Flex’s $6,830 uses the Enterprise price of $3,950 per cluster a year with no per-seat fee, as published on the Flex product page, on one licence; how application-mode clusters count toward Flex’s cluster licences is not published, so the figure assumes one, and if each of 20 FlinkDeployments counted as a cluster the licence alone would be $79,000 a year. Ververica Platform’s licence is priced on request and not published, so its figure is 4 hours a month, $5,760 a year, for running and upgrading the platform and its database, before the licence. The Flink Kubernetes Operator has no licence fee and no database and carries 2 hours a month, $2,880 a year. The open-source monitoring stack, assembled from parts, carries 10 hours a month, $14,400 a year. The Flink Web UI comes with every cluster and is modelled at nothing extra.
The criteria map onto Flink on Kubernetes defaults in the figure below.
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Governance per person and job counts three times, One view across clusters counts twice, Out of the data path counts twice, Job lifecycle counts once, Inspecting running jobs counts once and Getting metrics out counts once, for a total out of 100. Governance per person and job counts three times, because on Kubernetes the right to change a Flink job is the right to edit a resource, Kubernetes roles only ever add permissions, and whoever may submit a job can run code on the cluster, so roles per person and per job, an approval step before a production job is stopped or deleted and an audit trail that names the person decide who may touch what. One view across clusters and out of the data path count twice: in application mode every FlinkDeployment is a cluster of its own, and a tool between a job and its data becomes part of every pipeline. Job lifecycle, inspecting running jobs and getting metrics out count once, because every option here does some of each, and on Kubernetes lifecycle usually belongs to the Flink Kubernetes Operator. This page is published by Factor House, which makes Flex. Every option is scored on the same rubric and the same sources: Flex's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Flex ranks first on its total of 83 out of 100. The other options follow by total.