Multi Node Kubernetes Installation Guide

Introduction

This IVAAP Installation guide will walk you through all processes for installing IVAAP on large-scale, multi-node orchestration architecture. IVAAP supports deployments on Azure AKS clusters, AWS EKS clusters, and OpenShift clusters. This guide assumes that all requirments for IVAAP have been met described in the Technical Data Sheet.

Starting with IVAAP 2026.1, the same unified zip from the SLB Software Download Center used for k3s provides subcommands for the multi-node workflow. Download the package, extract on a Linux host, and use ivaap retag-images and ivaap generate-yaml from the package directory. You do not need to manually extract a BASE helm tarball or run standalone shell scripts.

Release versions use the form 2026.1.0-1: 2026.1.0 is the IVAAP application version and -1 is the Helm chart revision for that release.

For simplicity, image retagging requires Docker CLI on a Linux host with access to your container registry. Running IVAAP on your Kubernetes cluster has no Docker dependency; only the retag workflow uses the local docker daemon.

# Package contents after extract
2026.1.0-1_IVAAPHelmTemplate_2026-06-07-476858-IVAAPHelmTemplate-config.zip
ivaap
IVAAP_Documentation_20260605T202653Z.exe
IVAAP_Documentation_20260417T204910Z.zip
README.md

./ivaap -v

# example output:
#   IVAAP version:        2026.1.0-1
#   Package name:         2026.1.0-1_IVAAPHelmTemplate_2026-06-07-476858

On Windows, open IVAAP_Documentation_*.exe to read the deployment guide before working on the Linux retag/generate-yaml steps.

Image Retagging

Unlike k3s where images are loaded directly with k3s ctr, multi-node clusters require images in your container registry. The ivaap binary embeds every image tarball — no manual extract step is needed.

Dry-run

Preview what will be loaded and retagged:

./ivaap retag-images --registry myNewRegistry.azurecr.io --dry-run

The output lists each image as it would appear after retagging from caspian.azurecr.io to your registry. Use this list to pre-create repositories in your registry when auto-create is disabled.

Container image structure:

# Full image: <registry>/<repository>:<tag>
myNewRegistry.azurecr.io/ivaap/backend/blobstoragenode:blobstoragenode-3.0-16-f59d956-20260303T181434Z

• Registry: myNewRegistry.azurecr.io
• Repository: ivaap/backend/blobstoragenode
• Tag: blobstoragenode-3.0-16-f59d956-20260303T181434Z

Load and tag

Load images into the local docker daemon and retag (no push):

./ivaap retag-images --registry myNewRegistry.azurecr.io

Below is an example output:

user@linux:~$ ivaap retag-images --registry myRegistry.azuercr.io --dry-run
Dry run — no docker calls. Would process 18 image tarball(s):

  - connectors/witsmlnode-3.1-8.tar.gz
  - connectors/cloudstoragenode-3.1-9.tar.gz
  - connectors/mongonode-3.1-9.tar.gz
  - connectors/geofilesreservoirsnode-3.1-9.tar.gz
  - connectors/blobstoragenode-3.1-10.tar.gz
  - connectors/prosourcenode-3.1-7.tar.gz
  - connectors/geofilesmasternode-3.1-9.tar.gz
  - connectors/petrelstudiodbnode-3.1-8.tar.gz
  - connectors/witsmlliveupdatetask-3.1.9.tar.gz
  - connectors/s3node-3.1-8.tar.gz
  - connectors/witsmlpollingtask-3.1.9.tar.gz
  - connectors/opensdus3r3node-3.1-17.tar.gz
  - connectors/opensducloudstoragenode-3.1-17.tar.gz
  - connectors/opensdublobstorager3node-3.1-17.tar.gz
  - connectors/ppdmnode-3.1-8.tar.gz
  - connectors/geofilesseismicnode-3.1-9.tar.gz
  - connectors/witsmlwelltrajectorypollingtask-3.1.9.tar.gz
  - docker-images.tar.gz

Loaded images would be retagged: caspian.azurecr.io/... -> myRegistry.azuercr.io/...

Push images

Authenticate to your registry, then push:

docker login myNewRegistry.azurecr.io
./ivaap retag-images --registry myNewRegistry.azurecr.io --push

You can watch images push in real time. A successful run ends with a list of images pushed to your registry.

Legacy retag script

The ivaap-helpers/image-retagging/retag-images.sh script remains available inside the extracted Helm payload for environments that prefer the older workflow. The ivaap retag-images subcommand is the recommended path for 2026.1 deliveries. See IVAAP Helpers for script details.

PostgreSQL Database

IVAAP uses a PostgreSQL database to store user information, dashboards, projects, etc. For cloud deployments in large clusters, SLB recommends using a managed cloud database service.

For requirments of the PostgreSQL database, refer to the IVAAP Technical Data Sheet and the Database Administration guide.

The IVAAP package embeds a .sql schema file (visible after ivaap generate-yaml extracts the chart, or via ivaap extract-payload). Load this into your PostgreSQL database once the instance is ready.

For the next section, gather:

1. Database hostname
2. Database name to be used with IVAAP
3. User/Role for IVAAP's database (must meet requirments in DBA Guide)
4. That User/Role's password
5. The port opened for the PostgreSQL instance (default is 5432)

Deployment Configuration YAML

Run ivaap generate-yaml from the package directory after images are retagged (and pushed) to your registry. This subcommand:

1. Probes the FlexNet license server (host + port prompts).
2. Prompts for cluster type (OpenShift, EKS, AKS, or K3s).
3. Prompts for namespace, FQDN, and container registry (skipped when --registry is passed).
4. Prompts for external PostgreSQL connection details.
5. Generates Circle of Trust keys, ActiveMQ password, and encrypted database password (via docker run against adminserver/activemq images — retag-images must have been run first so those images exist in the local docker daemon).
6. Extracts IVAAPHelmTemplate/ to the working directory and writes a timestamped ivaap.values-<UTC>.yaml.

./ivaap generate-yaml

Example output:

# example output:

user@linux:~/ivaap-staging$ ivaap generate-yaml

==> ivaap generate-yaml
Will write: /home/user/ivaap-staging/ivaap.values-20260610T233426Z.yaml


==> License server
FlexNet license server hostname or IP: flex-license.example.com
FlexNet license server port [27000]: 27000
INFO: server:    27000@flex-license.example.com

✔ flex-license.example.com resolves to 10.0.4.27

✔ lmgrd port reachable: flex-license.example.com:27000

✔ lmgrd responded: license server UP

✔ slbsls vendor daemon is UP

✔ Parsed 4 FEATURE(s)

✔ IVAAPServer entitlement present

Kubernetes cluster type.
Options: Openshift, EKS, AKS, K3s
cluster type: AKS
INFO: cluster.type.aks.enabled = true
IVAAP namespace [ivaap]: ivaap-dev

Fully-qualified domain name for IVAAP (no http:// prefix).
Example: ivaap.example.com
FQDN: ivaap-dev.aks.slb.com

Container registry base.
ACR example: caspian.azurecr.io
ECR example: 245634265005.dkr.ecr.us-west-2.amazonaws.com
registry: myNewRegistry.azuercr.io

External PostgreSQL connection info.
  host: azure-managed-postgres.host
  database name: ivaapdb
  port [5432]:
  username: ivaapserver
  password:

==> Generating CoT keys, ActiveMQ password, encrypted DB password (docker)
INFO: adminserver image: caspian.azurecr.io/ivaap/adminserver:adminserver-3.1.8-c91476e-eclipse-temurin-21-jdk-noble-202606012339Z
INFO: activemq image:    caspian.azurecr.io/ivaap/activemq:activemq-6.2.5-a3a0cd9d-202606011431Z

✔ Keys generated

==> Writing values.yaml

✔ Wrote /home/user/ivaap-staging/ivaap.values-20260610T233426Z.yaml

Extracting IVAAPHelmTemplate to /home/user/ivaap-staging ...

✔ Helm chart:       /home/user/ivaap-staging/IVAAPHelmTemplate
✔ Generated values: /home/user/ivaap-staging/ivaap.values-20260610T233426Z.yaml

Deploy with:
  helm upgrade --install ivaap /home/user/ivaap-staging/IVAAPHelmTemplate \
    -f /home/user/ivaap-staging/IVAAPHelmTemplate/values.yaml \
    -f /home/user/ivaap-staging/ivaap.values-20260610T233426Z.yaml \
    -n <namespace>

Re-run with --force only when you intend to overwrite an existing IVAAPHelmTemplate/ directory or output file.

Now you will see in your working directory, you have the IVAAPHelmTemplate, as well as you configured yaml to use in your deployment.

user@linux:~/ivaap-staging$ ls --tree --depth=3
 .
├──  ivaap.values-20260610T233426Z.yaml
└──  IVAAPHelmTemplate
    ├──  Chart.yaml
    ├──  collect-image-list.sh
    ├──  deployment-examples
    │   ├──  deploy-with-gitops
    │   └──  deploy-with-two-values-files
    ├──  templates
    │   ├──  _helpers.tpl
    │   ├──  aws
    │   ├──  azure
    │   ├──  common
    │   ├──  deployment.yaml
    │   ├──  k3s
    │   └──  openshift
    └──  values.yaml

Bootstrap defaults

generate-yaml writes TLSSecret.enabled: false and sets the proxy to http. This is intentional for first-time smoke testing. Plan production TLS before go-live — see Post-Deployment Advanced Configuration.

Deploy with Helm using two values files:

helm upgrade --install ivaap ./IVAAPHelmTemplate \
  -f ./IVAAPHelmTemplate/values.yaml \
  -f ./ivaap.values-20260610T143022Z.yaml \
  -n ivaap --create-namespace

For environment-specific prerequisites (secrets backends, ingress classes, storage classes), refer to:

• AWS EKS
• Azure AKS
• OpenShift
• Deployment Methods in General Helm Configuration

Verify and Next Steps

After Helm reports deployed:

1. Confirm all pods are Running: kubectl get pods -n ivaap
2. Check backend health through your ingress FQDN (during bootstrap, use http://)
3. Log in to the admin client and confirm database connectivity

Credentials for local authentication are embedded in the generated values YAML secrets. If you need to rotate them, refer to IVAAP Configuration.

Continue with Post-Deployment Advanced Configuration for TLS go-live, external authentication, and day-2 operations.