vuLauncher Prerequisites

Introduction

vuLauncher is VuNet's command-line utility for deploying vuSmartMaps™. It supports two distinct deployment environments — Self-Managed Virtual Machine (VM) based clusters, where vuLauncher installs the base Kubernetes platform before deploying vuSmartMaps, and Customer Managed Kubernetes clusters such as Amazon EKS, Azure AKS, Google GKE, OpenShift, and Rancher, where vuLauncher deploys directly onto an existing cluster within a dedicated namespace.

This document is the single, consolidated reference for everything that must be in place before a deployment is started. It brings together the environment prerequisites, network and port requirements, and the full set of pre-installation checks performed by the pre-check utility (checks.sh), so that a deployment engineer can validate an environment end-to-end using one document, regardless of whether the target is Virtual Machine based or a managed Kubernetes cluster.

The prerequisites in this guide apply irrespective of the underlying infrastructure (on-premise data center, private cloud, or public cloud) and must be validated using the same user account that will subsequently be used to run vuLauncher. All requirements described here should be satisfied across every node in the environment prior to initiating deployment.

note

A separate, dedicated guide covers the step-by-step deployment and installation procedure using vuLauncher for both VM based and Managed Kubernetes environments. This document covers only what must be validated and prepared before that process begins.

Deployment Modes

vuSmartMaps™ can be deployed using vuLauncher in one of two modes. The mode selected determines which set of prerequisites in this document applies, and is controlled by the env_name parameter in the d-spec (Deployment Specification) file.

VM Based Deployment

In this mode, vuSmartMaps is installed on virtual machines running a supported operating system. vuLauncher provides a native Kubernetes cluster on these VMs and then deploys the vuSmartMaps application on top of it. This mode requires the full set of VM, OS, kernel, and network prerequisites described in Section 4 of this document, since Kubernetes itself is being installed as part of the process.

• Set env_name: "vm" in the d-spec file for this mode.

• One VM is designated to run vuLauncher; this VM also facilitates the installation process and is subsequently used for internal platform monitoring.

• Applicable to on-premise, private cloud, or public cloud VMs.

Managed Kubernetes Deployment

In this mode, vuSmartMaps is deployed onto an existing, already-provisioned managed Kubernetes cluster. vuLauncher does not install Kubernetes; it skips all Kubernetes bootstrap stages and begins directly from the service installation phase using Helm charts. This mode requires the cluster-level and cloud-specific prerequisites described in Section 6 of this document.

• Set env_name: "cloud" in the d-spec file for this mode.

• Supported managed Kubernetes platforms include Amazon EKS, Azure AKS, Google GKE, Red Hat OpenShift (ROSA/ARO/OKD), Rancher, Nutanix, and VMware Tanzu Kubernetes Grid.

• The Kubernetes control-plane version must be 1.29 or higher.

• Deployment is invoked with --ignore-preflight --start-from helm-chart-updates, since VM/OS level pre-checks are not applicable to an existing managed cluster.

D-Spec Requirement

The Deployment Specification (d-spec) is a YAML configuration file that is unique to every environment and every customer installation. It defines the list of nodes (or, for managed Kubernetes, existing node names), the mapping of services to nodes, storage class mappings, and the resource limits (CPU, memory, replica counts, disk) for every service that vuLauncher installs.

The d-spec directly drives both the pre-check utility and vuLauncher itself:

• The pre-check script (checks.sh) reads node IP addresses from the d-spec (under .sizing.node[].ip_address) to determine which nodes to validate.

• vuLauncher reads the same file to determine node roles (master/worker), service placement, and resource allocation during installation.

Generating the D-Spec

The d-spec is unique to each environment and can be generated using the sizing calculator available at sizing.vunetsystems.com.

• For VM based deployments, the generated file should follow the naming convention sizing-vm.yaml.

• For Managed Kubernetes deployments, the d-spec references existing Kubernetes node names (as returned by kubectl get nodes) rather than IP addresses, along with storage class mappings for each data tier.

• Validate the file at any time using ./build/launcher_linux_x86 --dspec <path> --validate-config, or perform a full dry-run using --dry-run before starting an actual installation.

note

Contact the VuNet Support team to obtain the environment-specific d-spec file and deployment release links after the VM infra has been provisioned for deployment.

Pre-requisites for VM Based Installation

The following prerequisites must be validated and satisfied on every node before starting a VM based deployment. These requirements have been organised to align with, and fully cover, every automated check performed by the pre-check utility (checks.sh) described in Section 5, so that manual preparation and automated validation are always in sync.

DNS Names and Load Balancer

vuSmartMaps is accessed externally via an internal proxy and LB service called Traefik. Traefik is a single point of access for UI and Data collection. On cloud managed k8s installations, traefik will be deployed as a LoadBalancer service, which enables a load balancer IP and name. Still, a meaningful DNS name is recommended for external access of the vusmartmaps UI, pointing to this LB name/IP.

For data collection, each datahub instance will require a unique DNS name which will be routed via traefik using SNI (server name indicator) based routes. For instance, if your vusmartmaps is deployed with 3 datahub instances, we should provision 3 unique DNS A records with the host part of the FQDN as vunet-datahub-<n> pointing to all the datahub tainted nodes.

For example, if the domain name is mybank.com and vusmartmaps is deployed with 3 brokers and the environment is “prod”, the recommended DNS names can be

vsmaps.prod.mybank.com → Point to LoadBalancer service IP/hostname

vunet-datahub-0.prod.mybank.com → DNS A record pointing to all the datahub tainted nodes

vunet-datahub-1.prod.mybank.com → DNS A record pointing to all the datahub tainted nodes

vunet-datahub-2.prod.mybank.com → DNS A record pointing to all the datahub tainted nodes

note

The above is only an illustration; the domain name conventions vary between target environments and the only mandatory requirement is vunet-datahub-<n> should be the hostname part for the DNS names created for datahub nodes. The dnsname for vusmartmaps UI access shall be flexible

Local VM Pre-Checks (In-House / Private Cloud Deployments)

For local dev or testing VM deployments (for example, C4I, e2e, or Azure VMs), run the following one-time setup commands on each VM before starting the pre-checks described in Section 5:

ssh-keygen
cat .ssh/id_rsa.pub >> .ssh/authorized_keys
cat .ssh/id_rsa.pub >> .ssh/known_hosts
sudo chown -R vunet:vunet /data1
sudo sysctl -w fs.inotify.max_user_watches=2099999999
sudo sysctl -w fs.inotify.max_user_instances=2099999999
sudo sysctl -w fs.inotify.max_queued_events=2099999999

Since we don't have DNS FQDNs in local test environments, we have to mimic the same using entries in /etc/hosts for vunet-datahub FQDNs. For example,

10.10.10.10 vunet-datahub-0.cs2ccloud.internal

note

Replace 10.10.10.10 with the actual public IP of the VM, and adjust the hostnames to match the fully qualified domain name appropriate for the test environment.

General Node / VM Requirements

• VMs with sufficient compute, memory, and storage resources must be provisioned as per the sizing agreed for the environment (see Section 3 — D-Spec Requirement).

• Each node must have at least 32 GB of total RAM, with a minimum of 4 GB of memory available at the time of installation. If available memory falls below 50% of total RAM, this is flagged as a warning (Check 21 — Free Memory Availability).

• A minimum CPU architecture of x86_64-v2 is required, which in turn requires a compatible glibc version on every node (Check 12 — Glibc Version).

• Fresh VMs are strongly recommended. Nodes must be free of any pre-existing Kubernetes installation, residual binaries (kubelet, kubectl etc), configuration directories (/etc/kubernetes, /var/lib/etcd, /var/lib/kubelet, /etc/cni, /opt/cni), or running Kubernetes/etcd processes (Check 4 — Kubernetes Installation Absence).

• The kubelet and containerd services must not already be running on any node, and their data directories (/var/lib/kubelet, /var/lib/containerd) must not already exist (Check 7 — Kubelet & Containerd Services).

• Every node must have a unique product UUID (/sys/class/dmi/id/product_uuid) and a unique MAC address. This is particularly important for cloned VMs, which can silently share identifiers (Check 13 — UUID & MAC Address Uniqueness).

Supported Operating Systems

• Ubuntu: 22.04, 24.04

• RHEL: 9.5 or higher

Network Port Requirements

The following ports must be opened between the relevant sources and destinations. If firewalld is enabled at the host level it should be disabled before Kubernetes installation, as it can interfere with pod-to-pod communication.

External Communication

#	Source	Destination	Port(s)	Protocol	Description
1	VM designated to run vuLauncher	download.vunetsystems.com	443	TCP	Download the vuSmartMaps installation package
2	All VMs	ghcr.io/vunetsystems/	443	TCP	VuNet's GitHub container registry
3	All VMs	pkg-containers.githubusercontent.com	443	TCP	VuNet's GitHub package containers
4	Users / administrators	vuSmartMaps VMs	22, 443	TCP	Installation, launch, and configuration access

Telemetry / Data Source Access

#	Source	Destination	Port(s)	Protocol	Description
1	Nodes with vuSmartMaps agents	All DataHub VMs	443 (default) / 9094 (host-IP based only)	TCP	Data collection channel
2	Application servers with APM agents	vuSmartMaps VMs	4317, 4318	TCP	APM traces and logs collection; must be opened on all VMs since the collector may run on any node
3	vuSmartMaps VMs	SNMP-capable network devices	161	UDP	SNMP-based polling
4	vuSmartMaps VMs	Systems polled over HTTP	443	TCP	HTTP polling / Prometheus scraping
5	vuSmartMaps VMs	Databases (JDBC)	DB listener port	TCP	JDBC-based database performance metrics collection
6	Network devices	vuSmartMaps VMs	162	UDP	SNMP trap ingestion
7	Network devices	vuSmartMaps VMs	514	UDP	Syslog ingestion

Intra-Cluster Communication

It is preferred that all VMs are within the same VLAN/subnet for unrestricted access. If access control policies are enforced, the following ports must be opened.

vuLauncher VM ↔ vuSmartMaps VMs

#	Port	Protocol	Description
1	22	TCP	SSH — required from the vuLauncher VM to all vuSmartMaps VMs
2	443	TCP	Main UI access, between all vuSmartMaps servers and the vuLauncher VM

Between all vuSmartMaps VMs

#	Port	Protocol	Description
1	6443	TCP	Kubernetes API server (Check 2 — validated as available, not in use, before install)
2	10250	TCP	Kubernetes orchestration service port
3	10259	TCP	Kubernetes orchestration service port
4	10257	TCP	Kubernetes orchestration service port
5	8472	UDP	Kubernetes VXLAN overlay (Flannel) port
6	2379	TCP	Kubernetes key-value store (etcd) port
7	2380	TCP	Kubernetes key-value store (etcd) port

note

For a single-node deployment, ports must be opened internally on the same node rather than across nodes; port opening is not required if all VMs are in the same subnet. For a multi-node deployment, ports must be opened internally on all nodes. Section 4.4.3 corresponds to Check 3 — Inter-Node Port Connectivity, which validates every port in both directions between every node pair, plus a self-test on each node.

Prechecks Utility

The requirements above are validated automatically by the standalone pre-check utility (checks.sh, usually found in launcher/static_files/scripts/launcher_prechecks/), which runs the following 21 checks in sequence and reports a PASS, FAIL, or WARN result for each. Each check is numbered so that a failure can be traced directly back to the corresponding requirement earlier in this section. See Section 5 for how to run and troubleshoot this utility.

#	Check	What It Checks
1	Firewall Status Check	Reports whether firewalld is Active, Inactive, Failed, or Not Installed on each node — an active or failed firewall can silently block Kubernetes inter-node traffic.
2	API Server Port Availability Check	Confirms TCP port 6443 (the Kubernetes API server port) is not already in use on any node.
3	Inter-Node Port Connectivity Check	Validates every required TCP/UDP port is reachable in both directions between every node pair, plus a self-test on each node.
4	Kubernetes Installation Absence Check	Confirms no pre-existing Kubernetes binaries, residual configuration directories, or running Kubernetes/etcd processes remain on any node.
5	OS Version Compatibility Check	Confirms each node's OS and version is on the supported list (PASS), the best-effort list (WARN), or unsupported (FAIL).
6	Mount Point Ownership Check	Confirms all custom mount points exist and are owned by the designated installation user on every node.
7	Kubelet & Containerd Services Check	Confirms kubelet and containerd are not already running, and that their data directories do not already exist, on any node.
8	IP Forwarding Check	Confirms IPv4 and IPv6 IP forwarding are enabled at the kernel level on every node.
9	Swap Disabled Check	Confirms swap is fully disabled (reports 0) on every node.
10	SELinux Configuration Check	Confirms SELinux is set to Permissive or Disabled — not Enforcing — on every node.
11	/var/lib Mount Options Check	Confirms the /var/lib filesystem is not mounted with the noexec option on any node.
12	Glibc Version Check	Confirms glibc is installed and functional on every node (verified via ldd --version).
13	UUID & MAC Address Uniqueness Check	Confirms every node has a unique product UUID and MAC address, catching identifier collisions common in cloned VMs.
14	iSCSI Service Check	Confirms the iSCSI initiator package or service is installed and running, using the appropriate method for the OS family detected on each node.
15	DNS Nameserver Check	Confirms DNS nameservers are configured in /etc/resolv.conf, flags localhost-based nameservers, and optionally verifies an external FQDN resolves from every node.
16	Default Network Interface Check	Confirms every node has a default network interface with a configured default route.
17	CIDR Range Availability Check	Confirms the 10.32.0.0/20 pod-network CIDR range is not already assigned to any interface on any node.
18	Hosts File Entries Check	Confirms every node's /etc/hosts file contains correct IP-to-hostname entries for every other node in the cluster.
19	RHEL Package Dependency Check	Ensures required host packages (conntrack-tools, git, fio, container-selinux) are installed on RHEL-family nodes; non-RHEL nodes are skipped automatically.
20	NTP Time Synchronization Check	Confirms an active time-sync service (chronyd, ntpd, or systemd-timesyncd) is running on every node, since Kubernetes TLS is sensitive to clock drift.
21	Free Memory Availability Check	Confirms every node has at least 32 GB total RAM and 4 GB currently available, and warns if available memory falls below 50% of total.

note

The pre-check utility (checks.sh) currently supports VM based deployments only. Integration of automated pre-checks for Managed Kubernetes deployments is yet to be done; until then, the Managed Kubernetes prerequisites in Section 6 must be verified manually.

Before running the prechecks utility

Before executing checks.sh, ensure the following are in place on the machine that will run it:

• The d-spec YAML configuration file is present and populated with the correct node IP addresses.

• The yq utility (bundled with the package) is accessible on the PATH — it is used to parse the YAML configuration.

• Passwordless SSH access has been configured between the deployment host and all target nodes.

• The installation user has passwordless sudo access (sudo -n true must succeed) on all nodes.

• All supporting scripts are present in the same directory as checks.sh and are executable.

Required Arguments

checks.sh requires three arguments and will fail immediately if any are missing or point to a non-existent file:

Argument	Example	Description
--username <user>	vunet	SSH username for all target nodes
--private-key <path>	~/.ssh/id_rsa	Path to the SSH private key file
--dspec <path>	dspec.yaml	Path to the d-spec YAML containing node IPs under .sizing.node[].ip_address

Example Invocations

Scenario	Command
Run all checks, stop on first failure (default)	./checks.sh --username vunet --private-key ~/.ssh/id_rsa --dspec dspec.yaml
Run all checks, continue even if some fail	./checks.sh --continue-on-fail --username vunet --private-key ~/.ssh/id_rsa --dspec dspec.yaml
Re-run from the beginning (ignore persisted state)	./checks.sh --from-beginning --username vunet --private-key ~/.ssh/id_rsa --dspec dspec.yaml
Verbose / live output	./checks.sh --debug --username vunet --private-key ~/.ssh/id_rsa --dspec dspec.yaml
Dry-run (validate prerequisites only, then exit)	./checks.sh --dry-run --username vunet --private-key ~/.ssh/id_rsa --dspec dspec.yaml
Run a single check by ID	./checks.sh --start 3 --username vunet --private-key ~/.ssh/id_rsa --dspec dspec.yaml
Resume from a specific check, continuing on failure	./checks.sh --start-from 10 --continue-on-fail --username vunet --private-key ~/.ssh/id_rsa --dspec dspec.yaml
Show help	./checks.sh --help

Logs and State

• Logs are written to ./logs/prechecks-YYYYmmdd-HHMMSS.log.

• Check state is persisted to /.status.json to support resume behaviour (--start-from).

• Use --from-beginning to discard persisted state and re-run all checks.

note

Always review the timestamped log file under ./logs/ for the exact command executed and the raw error returned for any failure — this is the fastest way to diagnose a FAIL result before escalating to the VuNet Support team.

Troubleshooting Tips

• Re-run with --debug for verbose, live output that shows each command as it is executed against every node — useful when a failure needs more context than the summary table provides.

• If every check fails immediately for a node, first confirm SSH and sudo access independently of the script (ssh <user>@<node> and ssh <user>@<node> sudo -n true) before re-running checks.sh.

• If only Check 2 or Check 3 fails (port availability / inter-node connectivity), check for host-level firewalls, security groups, or NACLs blocking the specific port reported, then re-run just that check with --start <id> to confirm the fix quickly.

• A WARN result (for example, Check 5 on a best-effort OS version, or Check 19 on an air-gapped node with missing packages) is not blocking, but should still be reviewed and resolved manually before proceeding.

• If a check that previously passed starts failing after infrastructure changes, use --from-beginning to rule out stale state in .status.json before investigating further.

vuLauncher pre-flight option

Note that the vuLauncher installer also performs an automated pre-flight validation stage at startup. All the checks part of the prechecks utility explained in the previous section is included in these pre-flights. If you have already ensured the readiness of cluster nodes by running prechecks utility in standalone mode, you can choose to skip by using ignore-preflight option with launcher. Do not add ignore-preflight option with vuLauncher unless cluster nodes readiness was prevalidated.

• The pre-flight stage runs automatically every time vuLauncher is started; no separate invocation is required for VM based deployments.

• The --ignore-preflight flag skips this validation stage. This is intended for Managed Kubernetes deployments, where VM/OS-level pre-flight checks are not applicable, and should not be used to bypass pre-flight validation on VM based deployments.

• Use --dry-run to validate all inputs, including the d-spec, without starting an actual installation — recommended as a final check before every deployment.

Pre-requisites for Managed Kubernetes

The following prerequisites apply when vuSmartMaps is deployed onto an existing, already-provisioned managed Kubernetes cluster (env_name: "cloud" in the d-spec). Unlike the VM based mode, vuLauncher does not install Kubernetes itself in this mode — it connects to and deploys onto a cluster that has already been provisioned and made accessible.

Common Prerequisites

• Deployment Host: a system with kubectl access to the target managed Kubernetes cluster is required to execute vuLauncher.

• Managed Kubernetes Environment: a supported managed Kubernetes environment with the number of worker nodes provisioned per the agreed sizing estimate (see Section 3 — D-Spec Requirement).

• Storage classes that support dynamic provisioning must be configured for each data tier required by the sizing.

• Supported Kubernetes Version: the cluster must be running Kubernetes 1.29 or higher.

• Launcher Configuration: the YAML configuration files that define the installation environment and per-service resource limits must be prepared before deployment, specific to the installation.

• Container Registry access: either outbound access to VuNet's public registry (ghcr.io) so images can be pulled directly at runtime, or, where internet access is restricted, a customer-managed private registry to which VuNet-provided image binaries have been uploaded and referenced in the d-spec.

• DNS Names and Load Balancer: vuSmartMaps is accessed externally through an ingress proxy and load-balancer service (Traefik), which is typically deployed as a LoadBalancer service on cloud-managed Kubernetes, provisioning an external IP/hostname. A meaningful DNS name should point to this address for UI access, and each DataHub instance requires a unique DNS name (hostname portion vunet-datahub-<n>) routed via SNI-based ingress rules.

Example — for domain mybank.com with 3 DataHub instances in a "prod" environment: vsmaps.prod.mybank.com (UI, points to the LoadBalancer service IP/hostname); vunet-datahub-0/1/2.prod.mybank.com (DataHub nodes).

note

Where unique DNS names cannot be created for vuSmartMaps, host-IP-based data collection must be used as a fallback, which requires opening the additional TCP port 9094. DNS-based collection remains the preferred approach for production deployments.

RBAC and Namespace Prerequisites

Every managed Kubernetes flavour requires role-based access control (RBAC) manifests and a dedicated namespace to be applied before the launcher installs any Helm charts. At a minimum, the following must be completed on the target cluster prior to deployment:

• Apply the RBAC manifests provided under launcher/static-files/cluster-setup, granting the necessary permissions to application components.

• Create the dedicated vsmaps namespace (kubectl create ns vsmaps) that vuSmartMaps will be deployed into.

• Create a container registry secret (kubectl create secret docker-registry ...) in the vsmaps namespace so the cluster can authenticate and pull the required images, whether from VuNet's GHCR or a customer-managed registry.

• For a shared cluster, set the environment variable export shared_cluster=true before running the launcher, to avoid conflicts with existing workloads on the cluster.

• For managing the cluster we would typically need a project owner or namespace owner role.

• The following helm charts must be run as cluster-admin of the managed k8s cloud as they contain certain resources (CRDs) creatable only by cluster admin. Having said that, the entire platform will work under vsmaps namespace and does not interfere with any other applications in the cluster.

  • ch-operator

  • ch-database

  • minio-operator

  • traefik

  • kafka cluster (only broker chart has the CRD for SNI based traefik routes)

Cloud-Specific Prerequisites

Azure Kubernetes Service (AKS)

• List available clusters (az aks list --output table) and retrieve credentials (az aks get-credentials --resource-group <rg> --name <cluster>).

• Verify cluster access and confirm all nodes are Ready (kubectl get nodes -o wide).

• Before running the launcher, set export shared_cluster=true. This step aligns the deployment with AKS-managed networking, storage, and ingress, avoiding conflicts with non-Azure components while ensuring cloud-native load balancing, high-performance disks, and a safe deployment in a shared Kubernetes cluster without impacting other workloads.

• Apply RBAC manifests, create the vsmaps namespace, and create the container registry secret as described in Section 6.2.

• Update the storage class to premium_ssd in the d-spec, and ensure the LoadBalancer setting for the ingress (Traefik) service is enabled.

Amazon EKS

• Verify AWS CLI configuration (aws configure list) and list available clusters (aws eks list-clusters --region <region>).

• Generate the kubeconfig (aws eks update-kubeconfig --region <region> --name <cluster>) and verify node access (kubectl get nodes).

• Associate an OIDC identity provider with the cluster (eksctl utils associate-iam-oidc-provider ...) — mandatory for IAM roles for service accounts, required by the EBS CSI driver.

• Install the Amazon EBS CSI driver add-on (aws eks create-addon --addon-name aws-ebs-csi-driver ...) to enable dynamic PersistentVolume provisioning.

• Apply RBAC manifests, create the vsmaps namespace, and create the container registry secret as described in Section 6.2.

Google Kubernetes Engine (GKE)

• List available clusters (gcloud container clusters list) and confirm the active project (gcloud config list).

• Generate the kubeconfig (gcloud container clusters get-credentials <cluster> --zone <zone> --project <project-id>) and verify node access (kubectl get nodes).

• Apply RBAC manifests, create the vsmaps namespace, and create the container registry secret as described in Section 6.2.

OpenShift Cluster (OCP)

• If admin access is not available, apply the required CRDs and RBAC manifests (oc apply -f launcher/static-files/cluster-setup).

• Assign Security Context Constraint (SCC) policies — both non-root and anyuid must be applied to every created service account (oc adm policy add-scc-to-user anyuid -z <service-account> -n <namespace>), since vuLauncher does not configure these automatically and they are mandatory for pods to run with the UIDs specified in the Helm charts.

Network Port Requirements

External Communication

#	Source	Destination	Port	Protocol	Description
1	Jump Server (vuLauncher)	download.vunetsystems.com	443	TCP	Download the vuSmartMaps installation package
2	All nodes	ghcr.io/vunetsystems/	443	TCP	VuNet GitHub Container Registry (not required if a local registry is used)
3	All nodes	pkg-containers.githubusercontent.com	443	TCP	GitHub package containers (not required if a local registry is used)
4	Users / administrators	vuSmartMaps cluster	443	TCP	UI access, installation, and configuration
5	Jump Server (vuLauncher)	Kubernetes control plane node(s)	443 or 6443	TCP	API server access via kubeconfig

Intra-Cluster Communication

All nodes should reside within the same VLAN/subnet where possible. If access control policies are enforced, the following ports must be opened between the vuLauncher VM and the vuSmartMaps nodes.

#	Port	Protocol	Description
1	22	TCP	SSH access from the vuLauncher VM to all vuSmartMaps nodes
2	443	TCP	Main UI access, between all vuSmartMaps nodes and the vuLauncher VM

Configuration Files

Two primary YAML files must be reviewed and verified before initiating a managed Kubernetes deployment:

• Environment Configuration File — contains cluster/VM access credentials and connection details.

• Deployment Specification (d-spec) — specifies node references (by node name, not IP, for managed clusters), service-to-node mappings, storage class mappings, and resource limits for each service, as described in Section 3.

note

For managed Kubernetes deployments, always start the launcher with --ignore-preflight --start-from helm-chart-updates, since the VM/OS-level pre-flight checks in Section 5 do not apply to an already-provisioned cluster. Always validate the d-spec with --dry-run before a full installation.

Conclusion

This guide is the single, consolidated reference for validating an environment before deploying vuSmartMaps™ with vuLauncher, covering both VM based and Managed Kubernetes deployment modes. Completing the applicable sections above — and, for VM based deployments, running the standalone pre-check utility — is the most reliable way to ensure a smooth, uninterrupted installation.