Installation and Upgrade for Kubernetes
Introduction
This document provides detailed instructions for installing and upgrading the Virtana Platform in a Kubernetes environment. It covers the necessary prerequisites, how to add integrations, and how to restore databases.
Prerequisites
Deployment Flexibility: GlobalView (GV) and IO components do not need to co-exist in the same environment. They can be deployed independently, in different environments, based on deployment architecture and customer requirements.
IO Architecture: IO functions as a self-contained unit that monitors the environment where it is deployed and transmits relevant data to Global View.
GV Integration Requirements: The IO component must be configured to communicate with the GV endpoint:
The GV HTTPS endpoint (port 443) must be accessible from the IO environment.
GV credentials (Client ID and Client Secret) specific to each tenant must be configured within IO.
Data Flow Characteristics:
Communication between IO and GV is logically unidirectional, where IO initiates all requests to GV.
However, as part of the response to IO's API calls, GV will return configurations, policies, or initiate handshake mechanisms.
Clarification: While GV does send configuration data in response to IO requests, it does not independently initiate outbound communication to IO. This maintains the overall model of IO-initiated unidirectional communication, with GV acting purely in a responding role.
Network Access Requirement: Ensure that outbound traffic on port 443 (HTTPS) from the IO environment to the GV endpoint is allowed, to enable successful communication and configuration synchronization.
Add Virtana Helm Repositories
To begin the installation process, add the Virtana Helm repositories by running the following command:
helm repo add virtana-repo https://virtana.gitlab.io/helm-charts
Deploy Infrastructure Monitoring
Service Account Configuration
We have introduced below configuration to handle service accounts for IO components:
global:
serviceAccount:
create: true
name: "virtana-io-sa"This configuration supports multiple scenarios for assigning service accounts:
Use an existing service account: If a service account already exists in your cluster (created outside the virtana-io Helm chart), set create: false and specify the existing service account name in the name field. The IO deployment will use this service account for all pods.
Create a new service account with a custom name: To have the Helm chart create a new service account, set create: true and specify the desired service account name in the name field. The chart will create the service account and use it for all pods.
Create a new service account with a default name: If create: true is set and the name field is left empty, the Helm chart will create a service account with the autogenerated name virtana-io-serviceaccount.
Infrastructure Monitoring Input File
To configure your Infrastructure Monitoring deployment, create a new file named infra-mon-values. yaml with the following content. Be sure to modify the values according to the comments provided.
global:
# Provide Dockerhub login credentials
serviceAccount:
create: true
name: "virtana-io-sa"
dockerRegistryCredentials:
DOCKER_SERVER: "https://index.docker.io/v2/"
DOCKER_USERNAME: "username"
DOCKER_PASSWORD: "password"
filestorage:
# Provide RWX (e.g NFS, SMB, AWS EFS) storageclass
storageClassName: "<filestorage-storageclass-name>"
blockstorage:
# Provide RWO (e.g vsphere block storage, EBS) storageclass
storageClassName: "<blockstorage-storageclass-name>"
brandingtheme:
name: virtana
image:
registryUrl: index.docker.io/virtana/ # Must include ending /
ntp:
servers:
- "time.server" # Enter your time server
# Enable integrations by providing "true"
integration:
integration-ibmsvc: false
integration-emcisilon: false
integration-emcvmax: false
integration-vcs: false
probe-hw-proxy: false
probe-os-proxy: false
probe-scaleio-proxy: false
probenetflow: false
probesw-snmp-proxy: false
probevm-aix-proxy: false
probevm-vcenter-proxy: false
probevm-windows-proxy: false
translator-cbts-infinibox: false
translator-hnas: false
translator-hpe3par: false
translator-hvsp: false
translator-kubernetes: false
translator-kvm: false
translator-linux: false
translator-ntap: false
translator-nexus: false
translator-nutanix: false
translator-powerstore: false
translator-psdo-ucs: false
translator-pure: false
translator-solaris: false
translator-unity: false
translator-vicm-xtremio: false
translator-vplex: false
translator-windows: false
vw-ciscogrpc-proxy: false
vw-integration-slack-app: falseMemory Resource
Users can now override default CPU and memory resource values for VW services using io-values.yaml.
To override resource limits for vw_fabric_service, use the following override in io-values.yaml:
global:
resources_limits:
vw_fabric_service:
resources:
requests:
memory: "2Gi"
cpu: "50m"
limits:
memory: "2Gi"
cpu: "100m"Installation and Upgrade Commands
# Check latest version of virtana-repo/virtana-global-view helm search repo virtana-repo/virtana-infra-mon --devel helm upgrade --install io-infra virtana-repo/virtana-infra-mon \ --namespace virtana-ipm --create-namespace -f infra-mon-values.yaml --set tags.infra=true \ --version <LATEST_VERSION> helm upgrade --install io-dbs virtana-repo/virtana-infra-mon \ --namespace virtana-ipm --create-namespace -f infra-mon-values.yaml --set tags.dbs=true \ --version <LATEST_VERSION> helm upgrade --install io-core virtana-repo/virtana-infra-mon \ --namespace virtana-ipm --create-namespace -f infra-mon-values.yaml --set tags.core_services=true \ --version <LATEST_VERSION> helm upgrade --install io-integrations virtana-repo/virtana-infra-mon-integrations \ --namespace virtana-ipm --create-namespace -f infra-mon-values.yaml \ --version <LATEST_VERSION>
Instructions
Create the File: Create a new file named infra-mon-values.yaml in your desired directory.
Edit the File: Copy and paste the above content into the file, and make the necessary modifications to the values based on your environment and requirements.
Deploy: Use this configuration file when deploying the Infrastructure Monitoring service in your Kubernetes environment.
Ensure that you carefully follow the instructions for modifying the placeholder values to match your specific configuration needs.
Note
The following settings have been disabled:
Settings → Software Upgrade
Settings → Remote Wisdom
Settings → Shutdown Appliance
Settings → Restart Appliance
Settings → Network
Settings → Disable editing
Settings → Syslog configuration
Settings → Backup and Restore
Settings → System Properties → Java Service dropdowns → Generation and Download of JMX and Memory Dumps
Rollback Policy for Kubernetes
IO does not support rollbacks. Users must not attempt to perform a rollback when deploying IO in Kubernetes environments. Rollback operations can lead to unexpected behavior or system inconsistencies.
In Kubernetes, always perform a forward upgrade.
Rollbacks are explicitly unsupported and should be avoided.