Manage Deployments

This page walks through the deployment lifecycle: creating, updating, changing state, triggering savepoints and restarts, and deleting deployments. For field-level reference, see Custom Resource Reference (../custom-resource-reference).

Create a Deployment

Apply a VvpDeployment CR to create a new deployment in Ververica Platform:

1kubectl apply -f my-deployment.yaml

The operator picks up the CR and creates the corresponding deployment in Ververica Platform. Set the initial deployment state to CANCELLED — this creates the deployment definition in Ververica Platform without starting a Flink job. You can then transition to RUNNING when ready.

Once the CR is reconciled, the operator sets Consistent=True and populates status.deploymentId with the Ververica Platform deployment UUID. Check the status:

1kubectl get vvpdeployment my-deployment

The HEALTHY column should show True.

Use initFields (PATCH Mode Only)

In PATCH mode, spec.initFields lets you provide initial field values that are applied only at creation time. After the initial creation, initFields are never included in any subsequent update — even if you modify initFields in the CR later or switch to PUT mode.

This is useful for fields like resources or logging configuration: you want to set sensible initial values, but you do not want the operator to continuously enforce them on every update.

1spec:
2  syncingMode: PATCH
3  deployment:
4    metadata:
5      name: my-deployment
6      namespace: default
7    spec:
8      state: CANCELLED
9      deploymentTargetName: default
10      template:
11        spec:
12          artifact:
13            kind: JAR
14            jarUri: "s3://my-bucket/artifacts/MyJob.jar"
15          engineVersionName: "vera-4.1-flink-1.20"
16  initFields:
17    spec:
18      template:
19        spec:
20          resources:
21            jobmanager:
22              cpu: 1.0
23              memory: "2g"
24            taskmanager:
25              cpu: 2.0
26              memory: "4g"
27          logging:
28            loggingProfile: "default"
29            log4jLoggers:
30              "": "INFO"

initFields is not supported in PUT mode. PUT always sends the full deployment definition, so there is no concept of creation-only fields.

Update a Deployment

To update a deployment, edit the CR and apply it:

1kubectl apply -f my-deployment.yaml

The operator detects the spec change and projects it to Ververica Platform. The SpecAligned condition reflects the result: True/ConfigUpdated on success.

PATCH vs PUT Semantics

The syncingMode determines how updates are projected to Ververica Platform.

PATCH mode sends only the fields present in the CR:

• Ververica Platform preserves its defaults for fields you omit (Flink restart strategy, state TTL, checkpointing intervals, and so on).
• Removing a field from the CR does not clear it in Ververica Platform — it stops being managed by the operator.
• Ideal for managing a subset of the deployment configuration while letting Ververica Platform handle the rest.

PUT mode sends the complete deployment definition:

• Fields you omit are cleared (reset to null or default) in Ververica Platform.
• The CR is the single source of truth for the deployment spec.
• Requires more fields to be specified. See Field Constraints (../custom-resource-reference#field-constraints).
• PUT does not update the deployment description. To change the description, use PATCH mode.
• Ververica Platform system annotations (for example, resource tracking annotations) are preserved through PUT operations and carried over automatically.

Switch Between Modes

You can change syncingMode at any time. The new mode takes effect on the next spec change. When switching from PATCH to PUT, ensure the CR includes all PUT-mandatory fields before applying — otherwise the webhook rejects the update.

Change Deployment State

The deployment state is controlled through spec.deployment.spec.state. To change the state, update this field and apply the CR:

1spec:
2  deployment:
3    spec:
4      state: RUNNING

State changes are projected as part of the normal config projection. After applying a state change, the CR status reflects the transition:

• status.observedSpecState — the desired state from the CR (updates immediately)
• status.actualState — the actual state reported by Ververica Platform (might show TRANSITIONING while Ververica Platform processes the change)

All bidirectional transitions are supported: CANCELLED to and from RUNNING, RUNNING to and from SUSPENDED, and CANCELLED to and from SUSPENDED.

Trigger Savepoints and Restarts

Savepoints and restarts are triggered by changing the nonce fields on the CR. The operator watches for nonce value changes and triggers the corresponding operation.

Trigger a savepoint:

1kubectl patch vvpdeployment my-deployment --type=merge \
2  -p '{"spec":{"savepointNonce": 1}}'

To trigger again later, change the value to any different number:

1kubectl patch vvpdeployment my-deployment --type=merge \
2  -p '{"spec":{"savepointNonce": 2}}'

Trigger a restart:

1kubectl patch vvpdeployment my-deployment --type=merge \
2  -p '{"spec":{"restartNonce": 1}}'

Nonce Behavior

• Any value change triggers the operation. The operator uses equality comparison, not monotonic ordering. Changing from 1 to 2, from 5 to 3, or from null to 0 all trigger the operation.
• The job must be RUNNING. If the job is not in RUNNING state when the operator processes the nonce, the operation is blocked. The NonceAligned condition shows SavepointBlocked or RestartBlocked.
• Blocked nonces require a new value to retry. The operator does not automatically retry blocked nonces. After the job returns to RUNNING, apply a new nonce value to trigger the operation. The blocked nonce is consumed — reverting to the same value does not re-trigger.
• Fire-and-forget. The operator submits the savepoint or restart request to Ververica Platform and records that the nonce was processed. The actual operation runs asynchronously in Flink — the operator does not track whether it completes successfully.

Delete a Deployment

Deleting a CR removes the corresponding deployment from Ververica Platform. The deployment must be in an inactive state before you delete the CR — the operator does not delete deployments that have a running Flink job.

Step 1: Set the deployment to an inactive state:

1kubectl patch vvpdeployment my-deployment --type=merge \
2  -p '{"spec":{"deployment":{"spec":{"state":"CANCELLED"}}}}'

Step 2: Wait for the deployment to reach CANCELLED state:

1kubectl wait vvpdeployment my-deployment \
2  --for=jsonpath='{.status.actualState}'=CANCELLED \
3  --timeout=120s

The state might briefly show TRANSITIONING while the Flink job shuts down.

Step 3: Delete the CR:

1kubectl delete vvpdeployment my-deployment

The operator verifies the deployment is inactive, deletes it from Ververica Platform, and removes the CR finalizer.

If the CR Is Stuck in Terminating

If you attempt to delete a CR while the deployment is still active, the webhook rejects the deletion immediately with an error message. In rare cases — for example, if the deployment's state changed between the webhook check and the operator's cleanup — the CR might enter Terminating state with a DeletionBlocked condition.

You can still patch the CR's spec while it is in Terminating state:

1kubectl patch vvpdeployment my-deployment --type=merge \
2  -p '{"spec":{"deployment":{"spec":{"state":"CANCELLED"}}}}'

Monitor the DeletionBlocked condition:

1kubectl get vvpdeployment my-deployment \
2  -o jsonpath='{.status.conditions[?(@.type=="DeletionBlocked")].status}'

Once the Flink job terminates, the operator removes the DeletionBlocked condition, deletes the Ververica Platform deployment, and releases the CR finalizer.