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

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
  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: false

Memory 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.

In this section:

Installation and Upgrade for Kubernetes

Note

Rollback Policy for Kubernetes

Search results