Skip to main content
Version: 3.1

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.

Create a Deployment​

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

kubectl 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:

kubectl 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.

spec:
  syncingMode: PATCH
  deployment:
    metadata:
      name: my-deployment
      namespace: default
    spec:
      state: CANCELLED
      deploymentTargetName: default
      template:
        spec:
          artifact:
            kind: JAR
            jarUri: "s3://my-bucket/artifacts/MyJob.jar"
          engineVersionName: "vera-4.1-flink-1.20"
  initFields:
    spec:
      template:
        spec:
          resources:
            jobmanager:
              cpu: 1.0
              memory: "2g"
            taskmanager:
              cpu: 2.0
              memory: "4g"
          logging:
            loggingProfile: "default"
            log4jLoggers:
              "": "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:

kubectl 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.
  • 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.

note

If the SpecAligned condition shows True/SpecUnchanged after an update, the operator did not detect a spec change. Verify that your edit changed a field in spec. Changes to status only do not increment metadata.generation and do not trigger a projection. You can also check the Ververica Platform Events tab for a Config projected event — its absence after an update means the operator did not process the change.

Change Deployment State​

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

spec:
  deployment:
    spec:
      state: RUNNING
StateEffect
RUNNINGStarts or resumes the Flink job.
CANCELLEDCancels the running job. This is the recommended initial state for new deployments.
SUSPENDEDSuspends the job by taking a savepoint and then stopping it.

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:

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

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

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

Trigger a restart:

kubectl patch vvpdeployment my-deployment --type=merge \
  -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.
note

If you changed a nonce but the operation did not happen, check the NonceAligned condition:

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

If the condition shows NoncesProcessed, the nonce was submitted to Ververica Platform. The operation might have failed asynchronously in Flink — check the Ververica Platform deployment directly for the savepoint or job status.

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:

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

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

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

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

Step 3: Delete the CR:

kubectl delete vvpdeployment my-deployment

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

note

The inactive state requirement applies to CANCELLED, SUSPENDED, FAILED, and FINISHED. CANCELLED is the recommended pre-deletion state.

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:

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

Monitor the DeletionBlocked condition:

kubectl get vvpdeployment my-deployment \
  -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.

On this page