Verify that your environment meets the system requirements for Kubernetes.
Your Kubernetes environment must include the following:
At least one Linux or Windows host that can communicate with the Kubernetes cluster. The host must have the Virtual Server Agent (VSA) package installed. This computer is referred to as an access node. See Hardware Specifications for the Access Node for Kubernetes.
A single access node can communicate with multiple Kubernetes endpoints.
A Kubernetes cluster that has access to the kube-apiserver endpoint (for example, https://kube-apiserver
:kube-apiserver_port_number). The default API port is 443.
One of the following, for authentication:
A Kubernetes service account with cluster-wide privilege. See Getting Started with Kubernetes.
Supported Kubernetes Distributions
All CNCF-certified Kubernetes distributions. Kubernetes revision versions 1.19.x-1.14.x.
The following distributions are validated by Commvault:
Red Hat OpenShift Container Platform (RHOCP) version 4.6-4.2, 3.11-3.9.
Note: No CSI integration for OpenShift 3.x. Point-in-time snapshots are not supported. Protection from live volumes only.
Google Anthos 1.7, 1.6, 1.5, and 1.4 (for GKE, AKS, EKS, and Red Hat OKE managed clusters)
Azure Kubernetes Service (AKS)
Google Kubernetes Engine (GKE)
For Docker Enterprise Edition (EE), all worker nodes must be either in mixed mode (recommended) or Kubernetes mode. For more information, go to the Docker blog site.
Supported Cloud Native Storage
Containers must reside on storage that has a registered Cloud Storage Interface (CSI) v1.2, 1.1, 1.0, or 0.3 driver with snapshot support.
Containers must have a registered StorageClass and the access mode set to Read Write Once (RWO).
Note: You must install the CSI driver that is relevant to your storage provider, and configure a Kubernetes storage class to utilize the CSI driver.
For a list of supported CSI drivers, see Kubernetes production CSI drivers list.
The following CSI drivers are validated by Commvault:
For Hedvig, you must shut down the application to perform an in-place volume level restore.
AWS Elastic Block Storage
GCE Persistent Disk
Resource Limits for Commvault Temporary Pods
Commvault spawns temporary pods during backup and recovery operations. Commvault deploys one pod per persistent volume for backup, within the namespace of the volume being protected. The temporary pods are deployed with the following deployment limits:
The temporary pods request compute resources of cpu:250m and memory:64Mi, with a limit of cpu:500m and memory:128Mi.
YAML Snippet of Commvault Pods
Important: Commvault currently does not support customization of pod resource limits.