Note: This applies to Ververica Platform 2.2 - 2.6
This article describes the requirements imposed by Ververica platform on the underlying Kubernetes cluster.
Kubernetes Versions:
The current Ververica Platform release works with:
-
Kubernetes 1.11+
-
OpenShift 3.11+
Previous versions' Kubernetes compatibility is listed in our documentation.
Outside Network Access:
Ververica Platform requires access to registry.ververica.com during the installation and later for fetching Flink-related artifacts. The registry is provided without SLA and it is recommended to set up a private registry with all the required images.
Persistent Volume Claims:
By default, Ververica Platform persists its metadata locally using a SQLite DB on a persistent volume (PV). The PV claim has to be satisfied with:
-
8Gi capacity
-
ReadWriteOnce accessMode
If you do not have access to writable PVs, an alternative option is to store the metadata in an external DB such as MySQL, PostgreSQL, or MS SQL Server.
High-level Overview:
The following diagram depicts a high-level overview of the resources involved in running a Ververica Platform installation. It depicts a recommended setup, where Flink jobs are deployed into separate namespaces (`vvp-jobs-1`, `vvp-jobs-2`) from the namespace where Ververica Platform is installed (`vvp`). Such separation creates the basis for multi-tenant setups. API access requirements across the namespaces are discussed in more details in the later section of this article.
Note: RDBMS is optional, an embedded SQLite database can be used instead.
Kubernetes API Access Requirements:
ServiceAccount:
Ververica Platform will attempt to create a service account with the required permissions for managing the cluster. You can also reuse an existing service account if it has corresponding permissions:
rules:
- apiGroups: ["apps", "extensions"]
resources: ["deployments"]
verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
- apiGroups: [""]
resources: ["configmaps", "pods", "services", "secrets", "serviceaccounts"]
verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["roles", "rolebindings"]
verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
Kubernetes Resources for Deployments and SessionClusters
The Kubernetes resources that Ververica Platform will create depend on the kind of Flink deployment, i.e. a standalone Deployment or a shared SessionCluster, and the features used.
Standalone Deployment (default)
Session Cluster
Multi-tenant Deployments:
Namespaces where Flink jobs will be deployed need to be first created using native Kubernetes tooling and then added to the `values.yaml` file before installing/upgrading via helm, for example:
vvp:
...
rbac:
additionalNamespaces:
- vvp-jobs-team-1
- vvp-jobs-team-2
Appending those namespaces will result in their addition to the ServiceAccount with the ClusterRole permissions listed above.
Other cross-namespace access requirements:
For network access policies, see this KB article.
OpenShift-specifics:
By default, a specific `fsGroup` is set in the platform’s charts. Those are controlled directly by OpenShift and need to be “unset“ by adding an empty `securityContext` to the `values.yaml` file:
vvp:
...
securityContext:
Note: `securityContext` is at the same root configuration level, as `vvp`.
Hardware Resources:
Ververica Platform itself (without any Flink jobs running) requests the following resources from Kubernetes:
appmanager:
resources:
limits:
cpu: "1"
memory: 1Gi
requests:
cpu: 250m
memory: 1Gi
gateway:
resources:
limits:
cpu: "1"
memory: 2Gi
requests:
cpu: 250m
memory: 2Gi
ui:
resources:
limits:
cpu: 100m
memory: 32Mi
requests:
cpu: 100m
memory: 32Mi