VPC Deployment Installation

The Validio application is distributed as a Helm chart. The Helm chart is installable on managed Kubernetes clusters. Validio is available for the following cloud providers:

Google Cloud Platform (GCP): GKE.
Amazon Web Services (AWS): EKS.
Microsoft Azure: AKS.

Prerequisites

Installing Validio on Customer VPC requires knowledge of:

Kubernetes: how to install, configure, and monitor resources on AWS, GCP or Azure.
Helm: how to install and configure helm charts on Kubernetes.

1. Access to docker images using a JSON file provided by Validio. For more information, contact us. 2. Configure a Kubernetes cluster on GCP, AWS or Azure. Considering the following:

All nodes must be in the same AWS availability zone, GCP zone or Azure zone.
Persistent volume provisioning enabled, to create Kubernetes PVC resources.
We also recommend a configured load balancer or ingress controller, such as:

3. Install the following:

kubectl CLI tool and set the kubectl context to the destination cluster.
Helm version 3.8.0 or later with Helm OCI support.

Installation

Complete the following steps to install your VPC deployment. Also, you can refer to VPC Deployment Examples.

1. Create namespace

Create the namespace you want to use for your configuration. In our examples, we use validio.

Bash

kubectl create namespace validio

2. Add the docker-registry secret

Create a Kubernetes Secret to pull the docker images required by the helm chart. This requires the JSON file provided by Validio. First, set the VALIDIO_SECRET environment variable to point to your JSON file:

Bash

export VALIDIO_SECRET=/home/user/Downloads/validio-secret.json

Then, add the Kubernetes Secret:

Bash

kubectl -n validio create secret docker-registry artifact-registry --docker-server=https://europe-docker.pkg.dev --docker-username=_json_key --docker-password="$(cat ${VALIDIO_SECRET})"

3. Install the helm chart

The helm chart installation requires the validio-values.yaml file. For details, refer to configuration and examples.

Bash

helm install validio oci://europe-docker.pkg.dev/validio-platform-prod/charts/validio --version [your-validio-version] --namespace validio --values validio-values.yaml

4. Configure the `validio-values.yaml` file

The Helm chart supports the following keys in the validio-values.yaml file:

Key	Default value	Description
`postgres.resources.*`	`nil`	Resources for Postgres service . Suggested values: memory limit `4Gi`, CPU request `200m`.
`postgres.storage.capacity`	`nil`	Storage capacity for Postgres service. Suggested value: `50Gi`.
`postgres.storage.class`	`nil`	Storage class for Postgres service. For example, `premium-rwo` for GCP and `gp2` for AWS. Leave empty to use cloud provider default.
`redis.resources.*`	`nil`	Resources for Redis service. Suggested values: memory limit `256Mi`, CPU request `50m`. Redis is only lightly used unless streaming sources are enabled; increase the memory limit if you use streaming.
`redis.storage.capacity`	`nil`	Storage capacity for Redis service. Suggested values: `20Gi`.
`redis.storage.class`	`nil`	Storage class for Redis service. For example, `premium-rwo` for GCP and `gp2` for AWS. Leave empty to use cloud provider default.
`surface.env.http_proxy`	`nil`	Set proxy for`HTTP` requests, will be used by Sentry
`surface.env.https_proxy`	`nil`	Set proxy for`HTTPS` requests, will be used by Sentry
`surface.ingress.enabled`	`false`	Set to `true` to enable Kubernetes ingress. Note: This requires an ingress controller and that all ingress parameters are set accordingly.
`surface.ingress.host`	`nil`	The ingress hostname. Note: You must also set a DNS name.
`surface.ingress.path`	`/`	Set the ingress path.
`surface.ingress.pathType`	`Prefix`	Set the Ingress path type.
`surface.ingress.annotations`	`nil`	Set the ingress annotations.
`surface.ingress.managedCert`	`false`	Create a `ManagedCertificate` resource for the ingress. Note: For GCP only.
`surface.ingress.tls.enable`	`false`	Enable Ingress TLS, required for use in Azure with cert-manager
`surface.probes.*`	`nil`	Control the Kubernetes Readiness and Liveness probes.
`surface.resources.*`	`nil`	Resources for Surface service. Suggested values: memory limit `1024Mi`, CPU request `200m`.
`ve.diver.certificate.enabled`	`false`	Set to `true` to enable custom self signed certificates for outbound communication
`ve.diver.certificate.content`	`nil`	Self-signed certificate content, including header and footer.
`ve.diver.encryptionKeys.enabled`	`false`	Set to `true` to encrypt stored credentials with keys that you supply and can rotate. Once enabled, it can’t be turned off. Refer to Manage the Diver encryption key.
`ve.diver.encryptionKeys.existingSecret`	`nil`	Name of the Kubernetes Secret in the release namespace that holds your encryption keys. Required when `ve.diver.encryptionKeys.enabled` is `true`.
`ve.diver.encryptionKeys.key`	`nil`	Name of the entry in `existingSecret` that Diver encrypts with. Required when `ve.diver.encryptionKeys.enabled` is `true`.
`ve.diver.env.http_proxy`	`nil`	Set proxy for HTTP requests when sending notifications to Slack, Microsoft Teams, and Webhook.
`ve.diver.env.https_proxy`	`nil`	Set proxy for HTTPS requests when sending notifications to Slack, Microsoft Teams, and Webhook.
`ve.diver.probes.*`	`nil`	Control the Kubernetes Readiness and Liveness probes.
`ve.diver.resources.*`	`nil`	Resources for Diver service. Suggested values: memory limit `512Mi`, CPU request `200m`.
`ve.ingress.probes.*`	`nil`	Control the Kubernetes Readiness and Liveness probes.
`ve.ingress.resources.*`	`nil`	Resources for Ingress service. Suggested values: memory limit `1024Mi`, CPU request `200m`. Note: This is not a Kubernetes ingress parameter.
`ve.ingress.cache.size`	`1Gi`	Local disk cache for Ingress service. Will be allocated on the host where the pod runs.
`ve.pipelines.probes.*`	`nil`	Control the Kubernetes Readiness and Liveness probes.
`ve.pipelines.resources.*`	`nil`	Resources for Pipelines service. Suggested values: memory limit `1024Mi`, CPU request `100m`.
`ve.pipelines.cache.size`	`1Gi`	Local disk cache for Pipelines service. Will be allocated on the host where the pod runs.

If the default value is false or true, the value type is bool. For all others, the value type is String.

All <service>.resources.* keys supports both CPU and Memory resources, specified only as <service>.resource.*. Available keys for each service:

YAML

<service>:
  resources:
    limits:
      cpu: <value>
      memory: <value>
    requests:
      cpu: <value>
      memory: <value>

The following are memory and CPU recommendations:

Memory: set a limit with <service>.resources.limits.memory. Kubernetes terminates a container that exceeds its memory limit, so the limit caps how much a service can consume.
CPU: set a request with <service>.resources.requests.cpu and leave the limit unset. The request reserves capacity when the pod is scheduled, and with no limit in place a service can use spare CPU on the node instead of being throttled.
CPU limits: if your platform policy requires one, set <service>.resources.limits.cpu to 1000m. That is five times the suggested request, so it bounds worst-case use without throttling normal load.

For more information, refer to Kubernetes resources documentation.

Each service runs as a single replicaEvery Validio service runs as exactly one replica and can’t be scaled horizontally. The Helm chart has no replica count or autoscaling setting, and you shouldn’t scale the deployments or statefulsets beyond one replica by any other means. To give a service more capacity, raise its <service>.resources.* values instead.

If you have special requirements for Kubernetes pod placements, like using affinity, tolerations or nodeSelector that is possible on all our services. Here is an example of how it would be done:

YAML

<service>:
  nodeSelector:
    <label>: "<value>"
  tolerations:
    - key: <key>
      operator: Equal
      value: "<value>"
      effect: NoSchedule

Most services also supports controlling the Kubernetes Liveness and Readiness probes. They are specified above in the table as <service>.probes.*. Available keys are listed below, note that they are enabled by default and the commented values are the default values, so no need to make any changes if you are happy with the default values.

YAML

<service>:
  probes:
    liveness:
      enabled: true
      # failureThreshold: 3
      # initialDelaySeconds: 0
      # periodSeconds: 10
      # successThreshold: 1
      # terminationGracePeriodSeconds: 30
      # timeoutSeconds: 1
    readiness:
      enabled: true
      # failureThreshold: 3
      # initialDelaySeconds: 0
      # periodSeconds: 10
      # successThreshold: 1
      # terminationGracePeriodSeconds: 30
      # timeoutSeconds: 1

Migrator jobs and init containers

Two Kubernetes Jobs run database migrations: ve-migrator for the Validation Engine and surface-migrator for Surface. The Jobs run when you install Validio, and when you upgrade to a release that includes a new version of the Validation Engine or Surface. A helm upgrade that only changes values in your validio-values.yaml file doesn’t run them. Before Diver, Ingress, Pipelines, and Surface start, an init container in each of their pods waits for the migrations to finish. Ingress also runs one init container for each custom database driver that you configure. The migrator Jobs have no default resources. If your cluster enforces resource quotas, requires resource requests on every container, or only schedules pods on tainted nodes, set the resources and pod placement for the Jobs as well:

YAML

ve:
  ve-migrator:
    resources:
      limits:
        memory: <value>
      requests:
        cpu: <value>
        memory: <value>
    tolerations:
      - key: <key>
        operator: Equal
        value: "<value>"
        effect: NoSchedule
surface-migrator:
  resources:
    limits:
      memory: <value>
    requests:
      cpu: <value>
      memory: <value>

Delete the migrator Job before you change its settingsKubernetes can’t change an existing Job. If you change the resources or pod placement of a migrator in a release that doesn’t include a new migrator version, helm upgrade fails. Delete the existing migrator Job first, then upgrade the Helm release. You don’t need to do this when the upgrade includes a new migrator version, because a new Job is created.

To find and delete a migrator Job:

Bash

kubectl -n validio get jobs
kubectl -n validio delete job <job-name>

The init containers have small default resources. To change them, use the following keys:

Key	Description
`<service>.init.waitForMigratorJob.useMigrator.resources`	Resources for the init container that waits for migrations. Available for every service except Postgres and Redis.
`ve.ingress.init.drivers.resources`	Resources for the init containers that install custom database drivers in Ingress.

If a migrator Job fails, the services don’t start. Check the Job logs with kubectl -n validio logs job/<job-name>. For alerting on failed Jobs, refer to Monitoring VPC Deployments.

Sizing for large catalogs

The suggested resource values in the table above suit catalogs of up to about 10,000 assets. Larger catalogs mainly increase the memory that Surface and Postgres use and the storage that Postgres uses. Ingress and Pipelines stay well within their suggested limits, even with more than a million assets. Diver only needs more headroom in the Large tier. Use the following tiers as a starting point, then adjust them based on the memory usage that you observe. For more information, refer to Monitoring VPC Deployments.

Catalog size	Diver memory limit	Ingress memory limit	Pipelines memory limit	Surface memory limit	Postgres memory limit	Postgres storage
Small: up to 10,000 assets	`512Mi`	`1024Mi`	`1024Mi`	`1024Mi`	`4Gi`	`50Gi`
Medium: 10,000 to 100,000 assets	`512Mi`	`1024Mi`	`1024Mi`	`1536Mi`	`4Gi`	`100Gi`
Large: more than 100,000 assets	`1024Mi`	`1024Mi`	`1024Mi`	`2048Mi`	`6Gi`	`250Gi`

Postgres storage also grows with the number of validators and the amount of history, not only with catalog size. If your storage class supports volume expansion, you can increase postgres.storage.capacity later.

Manage the Diver encryption key

The Diver service encrypts the credentials and integration secrets that Validio stores. By default, the Helm chart generates a single encryption key that can’t be changed. From Validio 11.1, you can supply your own encryption keys and rotate them with the ve.diver.encryptionKeys keys. Validio never has access to your encryption keys and can’t recover data encrypted with a key that you lose. Include the key Secret in your backups. For more information, refer to Backing up VPC Deployments.

Create the key Secret

You create and manage the key Secret yourself, for example by syncing it from your secret manager. The Helm chart never generates it. The Secret holds one entry per key. To generate a key:

Bash

openssl rand -base64 32 | tr -d '\n'

For example, to create a Secret named diver-encryption-keys with one key entry named v1:

Bash

kubectl -n validio create secret generic diver-encryption-keys --from-literal=v1="$(openssl rand -base64 32 | tr -d '\n')"

Enable rotatable keys

Create the key Secret in the release namespace.

Add the following to your validio-values.yaml file:

YAML

ve:
  diver:
    encryptionKeys:
      enabled: true
      existingSecret: diver-encryption-keys
      key: v1

Upgrade the Helm release.

On the first start after the upgrade, Diver re-encrypts everything stored under the original key with the key that ve.diver.encryptionKeys.key names. Leave your existing encryption key configuration unchanged, and keep the original key for as long as you have backups taken before this change. Restoring one of those backups needs the original key.

Enabling rotatable keys is one-wayAfter Diver has re-encrypted your data, setting ve.diver.encryptionKeys.enabled back to false stops Diver from starting.

Rotate the key

Add a new entry to the key Secret, for example v2. Keep the existing entries.
Set ve.diver.encryptionKeys.key to the name of the new entry.
Upgrade the Helm release. Diver restarts and re-encrypts all stored secrets with the new key.

If you change ve.diver.encryptionKeys.key before the updated Secret has reached the Diver pod, Diver restarts until the new entry is available. This usually takes less than a minute.

Verify the key in use

After you enable rotatable keys or change the key, check the Diver logs for one of the following messages:

Re-encrypted stored secrets with the configured encryption key: Diver re-encrypted your data with the new key.
Stored secrets already use the configured encryption key: Diver found your data already encrypted with the configured key. Diver logs this on every later start.

Keep old keys

Don’t delete a key entry while backups taken under that key still exist. To restore such a backup, the key Secret must contain the entry that was in use when the backup was taken. This also applies to the original encryption key that Diver used before you enabled rotatable keys. Keep it for as long as you have backups taken before that point, even after you have rotated to a new key. The first time you sign in to the Validio platform, you must use the admin credentials created in the Kubernetes Secret.

CautionDo not change or update anything in the Kubernetes Secret. You can change the password in the Validio platform.

Bash

kubectl -n validio get secrets validio-postgres -o=jsonpath='{.data.validio_app_auth_password}' | base64 -d ; echo

Access your Validio platform: In your browser, navigate to the hostname specified in the surface.ingress.host key. For example, https://validio.example.com/ If you did not configure an ingress, use port-forward to forward the Validio platform to your localhost:

Bash

kubectl -n validio port-forward svc/validio-surface 8889

Then, you can find it on http://localhost:8889/

Introduction

Using Validio

Validio Tutorials

AI Features

Credentials

Sources

Validators

Catalog

Lineage

Incidents & Errors

Notifications

Integrations

Schema & Profiling

Filters

Windows

Segmentation

Thresholds

Access & Settings

Deployment

Security

Other

VPC Deployment Installation

Prerequisites

Installation

1. Create namespace

2. Add the docker-registry secret

3. Install the helm chart

4. Configure the `validio-values.yaml` file

Migrator jobs and init containers

Sizing for large catalogs

Manage the Diver encryption key

Create the key Secret

Enable rotatable keys

Rotate the key

Verify the key in use

Keep old keys

​Prerequisites

​Installation

​1. Create namespace

​2. Add the docker-registry secret

​3. Install the helm chart

​4. Configure the validio-values.yaml file

​Migrator jobs and init containers

​Sizing for large catalogs

​Manage the Diver encryption key

​Create the key Secret

​Enable rotatable keys

​Rotate the key

​Verify the key in use

​Keep old keys

​Sign in to the Validio platform

Prerequisites

Installation

1. Create namespace

2. Add the docker-registry secret

3. Install the helm chart

4. Configure the `validio-values.yaml` file

Migrator jobs and init containers

Sizing for large catalogs

Manage the Diver encryption key

Create the key Secret

Enable rotatable keys

Rotate the key

Verify the key in use

Keep old keys

Sign in to the Validio platform