Flink Kubernetes Operator: what it does and where it stops

The Apache Flink Kubernetes Operator lets you declare a Flink job as a Kubernetes custom resource and keeps the running cluster matching it. It deploys, upgrades, suspends, resumes and deletes jobs, runs standby JobManagers for high availability and can adjust parallelism. It does not decide how a job should be upgraded, whether its checkpoints are healthy, which state backend fits, or when the operator itself should be upgraded. Those stay with whoever holds the pager.

The latest operator release is 1.16.1 (23 September 2026) and the latest Flink release is 2.3.0 (25 June 2026), both listed on the Apache Flink downloads page. If you run Flink on Kubernetes, or are choosing between that and a cloud service, the useful question is which jobs the operator does for you and which it hands back. AceMQ's Apache Flink services and its managed Flink on your Kubernetes or ours start from that split.

• Lifecycle. Deploy, suspend, resume, upgrade and delete jobs, with stateful or stateless upgrades. It can also roll back an upgrade that fails to stabilize, a feature its docs mark experimental, and restart unhealthy application deployments when high availability and the health check are switched on.
• Deployment shapes. A FlinkDeployment with a job section is an Application cluster; without one it is a session cluster, and a FlinkSessionJob submits a job into an existing session.
• High availability. Flink's Kubernetes HA services with standby JobManagers, plus leader election for the operator itself.
• Autoscaling and tuning. An autoscaler adjusts per-vertex parallelism from observed utilization, and autotuning right-sizes TaskManager memory.
• Snapshots and events. Savepoints and checkpoints can be triggered and tracked through custom resources, and Kubernetes events record deployments, upgrades, snapshots and scaling.

Each job has an upgradeMode, and every mode works until the state does not restore. The operator's job management documentation defines three.

Flink's own upgrade procedure still applies underneath: give every stateful operator an explicit uid, stop the job with a savepoint, upgrade, and resume from it. Flink's savepoint compatibility table covers the data format, not changes in SQL operators or semantics, so SQL jobs deserve a rehearsal on a copy. The table in the 2.3 docs lists 1.x versions only and says nothing about moving from 1.20 to 2.x, so treat that move as untested until you have tested it.

• The operator's own upgrades. The upgrade page says the custom resource definitions must be replaced by hand with kubectl, and that this step is not part of the Helm install logic. A new release can also drop a Flink version, and resources on a dropped version are rejected at validation after the upgrade.
• Supported Flink versions. The 1.16 compatibility page lists Flink 1.19, 1.20 and the 2.x line as supported, 1.15 to 1.18 as deprecated and 1.13 and 1.14 as rejected. Check every spec.flinkVersion before an operator upgrade, not after.
• Checkpoint health and state backend. The operator reports status. It does not tell you that a checkpoint taking longer every week is about to time out. State larger than memory belongs on RocksDB, which is limited by disk and offers incremental checkpoints that have to be switched on; HashMap is the default.
• Deletion behavior. The setting kubernetes.operator.job.savepoint-on-deletion defaults to false, so deleting a FlinkDeployment does not take a savepoint unless you ask for one.
• Experimental features. The 1.16 documentation describes FlinkStateSnapshot and blue/green rollouts as experimental.
• Sources and sinks. Exactly-once delivery depends on the sink being transactional or idempotent. No operator setting changes that.

The operator's upgrade page gives no rollback procedure beyond keeping a copy of your current manifests, so the order matters more than the speed.

1. Check the flinkVersion in every FlinkDeployment and FlinkSessionJob against the target release's compatibility page, and move any job on a dropped version first.
2. Render the new chart with helm template and compare it with kubectl diff.
3. Replace the custom resource definitions with kubectl replace, or apply any that do not exist yet. The docs say replace leaves running deployments unaffected.
4. Run helm upgrade, then confirm the operator is healthy before touching a job.
5. Upgrade jobs one at a time in savepoint mode, and confirm each restores before starting the next.

Managed Flink exists from several vendors. Amazon sells Amazon Managed Service for Apache Flink. Confluent describes Confluent Cloud for Apache Flink as a cloud-native service with no runtime version selection, where patches and minor upgrades are automatic. Ververica says it was built by the original creators of Apache Flink and lists bring-your-own-cloud and self-managed deployment. Each removes the cluster from your list and puts you inside its rules.

The operator removes toil, not the on-call. AceMQ runs open-source Flink with the operator on your Kubernetes clusters (Tier 3) or on infrastructure it runs (Tier 4), delivered with partner Flink specialists, and the managed Flink page compares the options. For the support side, see Apache Flink support options.

• Apache Flink downloads, flink.apache.org, 4 November 2026.
• Flink Kubernetes Operator 1.16: overview, Apache Flink documentation.
• Flink Kubernetes Operator 1.16: custom resources overview, Apache Flink documentation.
• Flink Kubernetes Operator 1.16: job management, Apache Flink documentation.
• Flink Kubernetes Operator 1.16: compatibility, Apache Flink documentation.
• Flink Kubernetes Operator 1.16: upgrading the operator, Apache Flink documentation.
• Upgrading Applications and Flink Versions, Apache Flink 2.3 documentation.
• State Backends, Apache Flink 2.3 documentation.
• Confluent Cloud for Apache Flink overview, docs.confluent.io.
• Ververica, ververica.com.