Private Image Registry

Ververica Platform images are hosted in a private registry. In environments without direct access to registry.ververica.cloud, mirror the images into your own registry and point the chart at it.

Configure the Registry

Set the registry once under global, and create a pull secret in every namespace that runs platform or Flink pods.

1global:
2  image:
3    registry: <your-registry-host>
4  imagePullSecretName: ververica-registry

global.image.registry applies to every platform component. Repository paths are relative to it, so mirror images preserving the platform-images/ prefix.

Images to Mirror

Platform Components

Every image in this group carries the platform version as its tag. For version 3.1.2, mirror each at tag 3.1.2.

Without the artifact fetcher, platform pods start normally and every deployment fails while pulling its init container.

Init Containers and Sidecars

These images have independent tags that do not follow the platform version. Read the tags from the chart values for the version you are installing rather than assuming them.

Flink Runtime

Flink JobManager and TaskManager pods pull a separate runtime image. The tag encodes the Flink version, the engine version, and an engine build identifier.

To read the tags that apply to a given chart version, render the chart and inspect the Application Manager configuration:

1helm template <RELEASE_NAME> \
2  oci://registry.ververica.cloud/platform-charts/ververica-platform \
3  --version 3.1.2 \
4  --namespace vvp-system \
5  --values values.yaml \
6  | grep -E "image:|imageTag:|imageRepository:"

This reflects the actual chart you are about to install, including any values overrides.

How the Engine Reaches Flink Pods

The Flink engine is delivered in two independent ways, and both must be available.

The vera-service image contains the engine archives and serves them over HTTP inside the cluster. The Application Manager configuration points the SQL Service at a URL on the in-cluster vera service, and the SQL Service downloads the archive during startup. Each archive is approximately 1 GB. Alongside the archives, vera also serves connector metadata and engine SDK artifacts from the same image.

The vvr-jdk11 and vvr-jdk17 images provide the Flink runtime for JobManager and TaskManager pods, which Kubernetes pulls in the usual way.

Mirroring vera-service is therefore required even though nothing outside the cluster requests the archives. A vera-service image at the wrong version serves the wrong archives, and the SQL Service fails to start.

Engine Build Identifiers

The engine build identifier in the runtime image tag and in the archive path, for example s068aZedK5xh, is fixed by the chart. It is not a Helm value and cannot be selected or overridden.

Mirror the engine images at the exact tags the chart requires. An engine image mirrored at a tag the chart does not reference is never pulled.

Verify the Mirror

After installing, confirm that every pod resolved to your registry:

1kubectl -n vvp-system get pods \
2  -o jsonpath='{range .items[*]}{range .spec.initContainers[*]}{.image}{"\n"}{end}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
3  | sort -u

Confirm that the vera service carries the engine archives for the version you installed:

1kubectl -n vvp-system exec deploy/vera -- ls /usr/share/nginx/html/packaged-vvr-dist/

Each entry corresponds to one engine version and JDK combination, and the identifier in each directory name must match the identifier in the Flink runtime image tags for that chart version.

Finally, start a deployment and confirm that the JobManager and TaskManager pods pull their runtime image without error. Platform pods reaching a ready state confirms the platform images only.