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 |
|---|---|---|
Global View (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.
Note
You can scale the Global View deployment beyond these default limits with some configuration changes. Increase replica counts based on observed usage patterns to improve performance and resilience. Increase Kafka partition counts to enable parallel processing and improve the scalability of data-handling services; increasing partitions also requires corresponding updates to the affected service configurations. Contact Virtana Support before you make these advanced adjustments, to confirm they align with system requirements and best practices.
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.
Deploy the ingress-nginx controller on OpenShift
On Red Hat OpenShift, deploy the ingress-nginx controller with elevated privileges to avoid Security Context Constraints (SCC) errors. Create the namespace, and then grant the privileged SCC to the ingress-nginx service accounts before you install the controller.
kubectl create ns ingress-nginx oc adm policy add-scc-to-user privileged -z ingress-nginx -n ingress-nginx oc adm policy add-scc-to-user privileged -z ingress-nginx-admission -n ingress-nginx
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
The Virtana Platform uses different licensing mechanisms depending on the component. Before you deploy, make sure you understand which licenses apply to your environment.
Licensing overview
Each Virtana Platform component uses one of two licensing mechanisms: an appliance-level license file or a platform subscription. The following table summarizes which mechanism applies to each component and when to obtain the license.
Component | License mechanism | When to obtain |
|---|---|---|
Cloud Cost Management (CCM) | Platform subscription (Trial, Professional, or Enterprise tier) | Provisioned during organization setup |
Container Observability (CO) | Platform subscription | Provisioned during organization setup |
Global View | Platform subscription (included with the IO appliance SKU or standalone) | Provisioned during organization setup |
Infrastructure Observability (IO) | Appliance-level license file (Base License plus Wisdom Pack licenses) | Before deployment |
Workload Placement (WLP) | Platform subscription (Trial, Professional, or Enterprise tier) | Provisioned during organization setup |
Infrastructure Observability licensing
Infrastructure Observability (IO) is the only component that requires a license file to be uploaded to the appliance as a deployment prerequisite. IO licensing uses a Base License plus Wisdom Pack licenses model.
Base License: Required for every IO instance. Enables the core IO platform.
Wisdom Pack licenses: Each Wisdom Pack enables monitoring for a specific integration type, for example Operating System, Virtualization, Enterprise Storage, SAN Switch, or IP Networks. You can implement Wisdom Packs individually or in combination, depending on your environment.
To obtain and upload an IO license, follow these steps:
Contact to Virtana Support to request a license.
For IO components, a valid license is required. Contact Virtana Support to request and obtain an IO license.
Download the license file to a system that the IO appliance can access.
In the IO UI, go to Settings and click Licensing in Appliance Configuration section, and then click .
Browse to the license file, and then upload it.
For detailed information about IO license types, Wisdom Packs, and license management, see the Infrastructure Observability Administrator Guide.
Platform component licensing (Global View, CO, CCM, WLP)
Global View, Container Observability, Cloud Cost Management, and Workload Placement are licensed through the Virtana Platform subscription-based licensing system. These licenses are not uploaded as files to an appliance. Instead, Virtana provisions them at the organization level during account setup.
Platform licenses are available in the following tiers:
Trial: Time-limited evaluation with predefined entity limits.
Professional: Production use with defined entity limits based on purchase quantity.
Enterprise: Production use with unlimited entity limits.
Freemium: Limited free access, where applicable.
Virtana generates and manages platform licenses through its backend systems. Your Virtana account team provisions the appropriate license tier when your organization is created or when you purchase additional modules. To view your current platform license usage, go to Settings > License Usage in the Virtana Platform.
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.