Skip to main content
Version: 3.1

Kubernetes Operator

A Kubernetes Operator is a Kubernetes-native application controller that extends the Kubernetes API to manage and automate the deployment, configuration, and lifecycle of complex applications. The Kubernetes documentation provides a good overview of Operators.

Ververica Platform provides a custom Kubernetes Operator that gives you a Kubernetes-native way to manage Flink deployments. Instead of managing deployments through the Web UI or the Ververica Platform API, the operator lets you define deployments as VvpDeployment Custom Resources and manage them with standard Kubernetes tooling such as kubectl and Helm. The Ververica Platform 3 Kubernetes Operator is an improved evolution of the Ververica Platform 2 operator, redesigned to align with the Ververica Platform 3 architecture. For migration guidance, see Migration from Ververica Platform 2.

Key Capabilities​

  • Deployment lifecycle management: Create, update, and delete Flink deployments using Custom Resources (CRs).
  • Two sync modes: PATCH sends only the fields present in the CR and preserves Ververica Platform defaults for omitted fields. PUT sends the full deployment definition and resets omitted fields.
  • State management: Transition deployments between RUNNING, SUSPENDED, and CANCELLED.
  • Savepoint and restart triggers: Use nonce fields to trigger on-demand savepoints and job restarts without extra tooling.
  • Conditions: Kubernetes-native health reporting through Healthy, Consistent, SpecAligned, NonceAligned, ParallelismAligned, and DeletionBlocked conditions.
  • Events: The operator emits lifecycle and warning events to the Ververica Platform Events tab. Ververica Platform job and deployment events are also mirrored to Kubernetes Events, making them accessible through kubectl get events and standard monitoring tools.
  • Autopilot integration: Provides observability into Autopilot's runtime scaling via the ParallelismAligned condition; the operator always projects the CR's parallelism to Ververica Platform.
  • Webhook validation: The operator validates CRs before they reach the cluster, providing immediate feedback through kubectl.

How It Works​

Ververica Platform remains the source of truth. The operator acts as a synchronization layer that translates your Kubernetes-native intent into Ververica Platform API calls. All lifecycle management, including job scheduling, failure recovery, and autoscaling, continues to run in Ververica Platform.

The sync loop works as follows:

  1. You create or update a VvpDeployment CR in your Kubernetes cluster.
  2. The operator detects the change and projects it to Ververica Platform through the AppManager API.
  3. Ververica Platform processes the change (starts a Flink job, applies configuration, triggers a savepoint, and so on).
  4. The operator updates the CR status with the current state from Ververica Platform.
note

Operator-managed deployments can only be modified through the operator. Once you create a deployment through a CR, the Ververica Platform UI and API block direct modifications. To make changes, update the CR. Deployments created through the UI or API cannot be claimed by the operator. This is a change from the Ververica Platform 2 operator, which allowed UI edits on operator-managed deployments but silently reverted them at the next reconciliation cycle.

CRDs and CRs​

The Kubernetes Operator uses two resource types:

  • Custom Resource Definition (CRD): A Kubernetes YAML manifest that defines the schema and behavior of the operator. The CRD ships with the Ververica Platform Helm chart.
  • Custom Resource (CR): A resource instance that manages a single deployment in Ververica Platform.

You can think of the CRD as a class definition and a CR as an object that instantiates the class.

On this page