Virtana Platform deployment prerequisites
This topic describes the infrastructure and configuration requirements to deploy the Virtana Platform with Helm charts.
To prepare your environment, you need to:
Add the Virtana Helm repositories.
Allocate CPU and memory resources for your cluster.
Configure storage and metrics components.
Deploy the Ingress Nginx controller.
Set up external dependencies.
Add the Virtana Platform Helm repository
Before you deploy the Virtana Platform, you must register the Virtana Helm chart repository with your local Helm client and refresh its index. Registering the repository makes the Virtana Platform charts available to Helm so that you can install or upgrade the platform. You run the commands in this topic from a terminal on the host where you manage the deployment.
This topic covers the prerequisites, the command to add the repository, the command to refresh the repository index, and how to confirm that the repository is registered.
Prerequisites
Before you add the Helm repository, make sure your environment meets the following requirements:
Helm 3 is installed and available on your
PATH. To confirm the version, runhelm version.The host can reach the Virtana Helm repository URL over the network. The
helm repo addcommand downloads the repository index, so the URL must be reachable.You have the repository URL for your deployment. Virtana provides this URL in your deployment package.
If the repository is private, you have the username and access token (or deploy token) that Virtana provides.
You don't need access to the Kubernetes cluster to add the repository or refresh its index. You need cluster access only for the later steps that install the Virtana Platform charts.
Add the repository
This section describes how to register the Virtana Helm repository under a local alias and refresh its index. You add the repository once per host. After you add it, you can reuse the alias in later helm install and helm upgrade commands.
To add the Virtana Platform Helm repository:
Open a terminal on the host where you manage the deployment.
Add the repository and give it the local alias Virtana:
helm repo add virtana-repo https://virtana.gitlab.io/helm-charts
Helm confirms the action with a message that the Virtana repository has been added.
Refresh the local chart index so that Helm has the latest chart versions:
helm repo update
Helm reads the index for each configured repository and reports when the update is complete.
Confirm that the repository is registered:
helm repo list
The Virtana repository appears in the list, along with its URL.
List the available Virtana Platform charts to confirm that Helm can read the index:
helm search repo virtana
Helm lists the Virtana Platform charts and their versions. You use these chart names in the deployment steps.
Note
If the Virtana Helm repository is private, the basic helm repo add command fails with an authentication error. Add the repository with the credentials that Virtana provides:
helm repo add virtanahelm-repo-url--usernamerepo-username--passwordrepo-token
Use a token rather than a personal password where possible, and avoid leaving the token in your shell history.
Note
If the repository uses a self-signed or internal certificate authority (CA), the helm repo add command fails with a TLS certificate error. Add the repository with the path to the CA certificate so that Helm can verify the connection:
helm repo add virtanahelm-repo-url--ca-filepath-to-ca-certificate
Note
If the Virtana alias already exists from an earlier deployment, Helm reports that the repository already exists. To replace the existing entry with a new URL, add the --force-update option to the helm repo add command.
Next step
After helm repo update completes and the Virtana repository appears in helm repo list, the Virtana Platform charts are available to Helm. Continue with the Virtana Platform deployment steps, which use the Virtana alias to install or upgrade the charts.
Supported Kubernetes flavors and versions
Virtana Platform supports the following Kubernetes distributions and versions:
Kubernetes Flavor | Supported Versions |
|---|---|
All (including EKS, GKE, AKS, OpenShift, kubeadm, K3s, and more) | 1.21.0 and above |
Before you deploy, make sure your cluster version is within the supported range.
Configure cluster resources
Your cluster must have enough resource to run Virtana. The requirements depend on the size of your IT environment. The following table lists the minimum cluster resources required for each component.
Component | Resource required | Environment Capacity |
|---|---|---|
GlobalView (Common) | 16 vCPU and 64 GB Memory | Can support up to 20K IO devices/20K CO containers and 500,000 alerts per month across all tenants |
CO Frontend | 4 vCPU and 8 GB Memory | Supports small, medium, and large environments |
CO Shared Services (Common) | 16 vCPU and 64 GB Memory | Supports small, medium, and large environments |
CO (Per backend cluster) | 4 vCPU and 32 GB Memory 8 vCPU and 64 GB Memory 16 vCPU and 128 GB Memory | Small (≤ 20 nodes and ≤ 200 pods) Medium (≤ 100 nodes and ≤ 800 pods) Large (>100 nodes or >800 pods) |
CO South (Per backend cluster) | 1 vCPU and 8 GB Memory 3 vCPU and 16 GB Memory 5 vCPU and 24 GB Memory | Small (≤ 500 pods) Medium (500 - 1000 pods) Large (1000 - 4000 pods) |
IO | 16 vCPU and 128 GB Memory | For all integrations enabled. Sizing would vary depending on specific requirements. |
StackStorm | 2 vCPU and 4 GB Memory | - |
Run kubectl get nodes and check the status to ensure all nodes are Ready and have sufficient capacity.
Storage requirements
Your Kubernetes cluster must have following two Storage Classes with Dynamic Provisioning:
Storage Class with RWO (ReadWriteOnce) support (for example, vSphere block storage, AWS EBS, Longhorn).
Storage Class with RWX (ReadWriteMany) support (for example, NFS, AWS EFS) (Only required for IO).
To ensure data stays in sync, your storage must meet a minimum speed of 20 MB/s per physical processor core and a recommended speed of 40 MB/s per physical processor core. See Vertica Documentation for the detailed minimum and recommended input/output performance. This storage speed requirement is specific to the Vertica database that runs within Virtana IO.
Note
Enable data encryption for all persistent volumes. If the underlying storage supports encryption, configure the associated storage class to enforce encryption for data at rest, so that stored data is protected.
Kubernetes metrics server for HPA
Install the Kubernetes Metrics Server to enable HPA (Horizontal Pod Autoscaling).
helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/ helm upgrade --install metrics-server metrics-server/metrics-server
Verify that the Metrics Server is running and healthy before enabling HPA for Virtana components. Run kubectl top nodes. If you see CPU and memory usage for your nodes, the metrics server is active.
Load Balancer
A load balancer enables external access to services deployed in your Kubernetes cluster. You need a load balancer to expose services such as the UI and API outside the cluster, and it must support the Kubernetes LoadBalancer service type. Examples include MetalLB and AWS ALB.
Make sure your load balancer is fully configured and integrated with your Kubernetes cluster.
Deploy Ingress Nginx controller
The Ingress Nginx controller is the receptionist for your cluster. It takes requests from the internet and sends them to the right Virtana service. The controller provides a single entry point that uses a single IP address to manage multiple services. It handles SSL certificates so your data is encrypted and makes sure that when you type virtana.yourcompany.com, you reach the correct dashboard.
Deploy with default values
You can use default values if you are running a standard Kubernetes cluster and do not need any security or networking rules. You can deploy with defaults in simpler environments like standalone VMs, OVA deployments, or on-prem single-node setups where no cloud-specific load balancer annotations or SSL termination at the LB level are needed.
helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ --namespace ingress-nginx --create-namespace \ --version 4.12.2 or more
Deploy with custom values
If you are on a cloud provider like AWS, Azure, or GCP, you need custom values.yaml file to attach a specific SSL certificate from your cloud provider.
To deploy the ingress-nginx controller with a custom configuration, perform the following steps:
Create or update your
ingress-nginx-values.yamlfile with the required settings.title="ingress-nginx-values.yaml" linenums="1" controller: service: annotations: ## e.g., Following input should be used if ingress-nginx is deployed on EKS service.beta.kubernetes.io/aws-load-balancer-type: "nlb" service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<cert_Arn>" ## To perform SSL termination at the LB level targetPorts: https: 80
Run the following command:
helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ -f ingress-nginx-values.yaml \ --namespace ingress-nginx --create-namespace
Full Documentation for more options - Ingress-Nginx Controller.
DNS nameserver and records
A DNS nameserver is required to map domains to the ingress-nginx controller IP.
Get the ingress-nginx controller IP or hostname
Run one of the following commands:
# Get hostname
kubectl -n ingress-nginx get svc ingress-nginx-controller \
-o=jsonpath='{.status.loadBalancer.ingress[0].hostname}'
# OR
# Get IP
kubectl -n ingress-nginx get svc ingress-nginx-controller \
-o=jsonpath='{.status.loadBalancer.ingress[0].ip}' Create DNS records
Create DNS records using the ingress-nginx controller IP (A record) or hostname (CNAME record).
These variables are referenced throughout the documentation:
Variable | Sample Value | Definition |
|---|---|---|
|
| Endpoint to access Keycloak UI |
|
| Endpoint to access Global View UI |
|
| Endpoint to access Growthbook UI |
|
| Endpoint to access Growthbook API |
SMTP client details
Virtana Platform requires SMTP configuration to send emails, such as notifications and alerts. The following SMTP client details are required:
Host
Port
From email address
Username (if auth enabled on SMTP server)
Password (if auth enabled on SMTP server)
Confirm cluster network connectivity to SMTP server
Follow the step to verify connectivity from the cluster network to the SMTP server on the configured port.
Log in to the IO appliance in Virtana Platform.
Navigate to the Settings > Outbound Email Settings.
Enter all fields (such as, host, port, from email address) correctly.
Click the Send Test Email To and enter an email address you can access.
Click Send.
You receive the test email within a minute.
If you receive the email, IO’s SMTP configuration is valid, and IO can reach your mail server.
Reference variables
The following variables are used as references throughout the documentation and in deployment values.
Variable | Sample Value | Definition |
|---|---|---|
|
| Name of the Company. |
|
| ORG_ID is a 16-digit UUID obtained after Global View deployment. |
|
| Name of the K8s cluster to be monitored (Applicable for CO). |
Make sure these values are consistent across your configuration files and deployment scripts.
Licensing
For IO components, a valid license is required. Contact Virtana Support to request and obtain an IO license.
Configure LLM Provider for Virtana AI (Copilot) (Optional)
Virtana AI enhances the user experience by providing a chatbot interface that allows users to interact with documentation, query alert-related information, and generate alert policies.
To enable this functionality, an API key from a supported model provider is required during deployment.
Virtana AI supports the following model providers. Choose one of the options below based on your organization's preferred provider.
Perform the following steps to generate an OpenAI API key:
Go to https://platform.openai.com, log in with your OpenAI account, or sign up if you do not already have an account.
Navigate to the API Keys section. Click your profile icon in the top-right corner, select API Keys, or navigate directly to https://platform.openai.com/account/api-keys.
Generate a New API key. Click Create new secret key, optionally enter a name for identification, and copy the generated key when it is displayed.
Note
The API key is shown only once. Store it securely because it cannot be retrieved later.
Enter this key in the Virtana Helm values to enable Virtana AI.
Perform the following steps to generate a Gemini API key:
Go to Google AI Studio, log in with your Google account.
Navigate to the API Keys section, and click Get API key.
Click Create API key, select the Google Cloud project to associate with the key, and copy the generated key when it is displayed.
Enter this key in the Virtana Helm values to enable Virtana AI.
LiteLLM acts as a proxy layer that routes requests to underlying model providers (OpenAI or Gemini). This option requires additional prerequisite configuration before generating the API key.
In your LiteLLM instance, create models with the exact names. These model mappings are required for all Virtana AI use cases to function correctly. See Configure Virtana AI for more details.
Once all models are created in your LiteLLM instance, navigate to your LiteLLM admin dashboard. Generate a new API key with access to all the model names. Copy and store the key securely.