# Support and requirements for virtual machines and containers protection

Use this page to verify that your environment supports Kubernetes protection. Review supported platforms, infrastructure requirements, and storage prerequisites before configuring protection.

Commvault supports protection of container applications and virtual machines running in Kubernetes environments.

## Supported environments

Commvault supports Kubernetes environments that meet the following criteria:

- CNCF-certified Kubernetes distributions

- Kubernetes versions in active maintenance

- CSI-based storage for persistent volumes

- Kubernetes-based virtualization platforms for virtual machines

## Supported virtual machine platforms

Commvault supports protection of virtual machines running on the following Kubernetes-based virtualization platforms. These platforms run virtual machines inside Kubernetes clusters and use Kubernetes-based APIs and storage for protection.

- KubeVirt 1.6 and later

- SUSE Virtualization (Harvester) 1.8.0

- Red Hat OpenShift Virtualization 4.21-4.18

## Access node requirements

Access nodes perform backups, restores, and data movement operations for Kubernetes workloads. For configuration details about access nodes, see Configuration for Kubernetes Access Nodes.

Requirements vary depending on the workload type.

Virtual machines

Use this configuration when you protect virtual machines running on Kubernetes-based virtualization platforms.

Component | Requirement
--- | ---
CPU | 8 vCPUs
Disk space | 100 GB
Memory | 16 GB
Architecture | x86 64-bit

Important

- Access nodes must be deployed as a VM within the Kubernetes/Openshift cluster.

- If the access node is not deployed in the `cv-config` namespace then you must configure the sK8sWorkerNamespace additional setting with value of the namespace where the access node resides.

- Container access nodes cannot be used to protect VMs.

Container applications

Use this configuration for containerized workloads, including namespaces, pods, and cloud-native applications.

Component | Requirement
--- | ---
CPU | 4 vCPUs
Disk space | 100 GB
Memory | 16 GB
Architecture | x86 64-bit and Arm 64-bit

### Supported operating systems

Access nodes support major enterprise Linux distributions and Windows Server versions.

- Amazon Linux 2023

- Oracle Linux 9.x, 8.x

- Red Hat Enterprise Linux 9.x-7.x

- Ubuntu 22.04 LTS, 20.04 LTS

- Windows Server 2022, 2019, 2016

Important

For VM workloads, only Red Hat Enterprise Linux-based access nodes are supported.

### Network requirements

Access nodes must be able to connect to the Kubernetes API server endpoint, either directly or via a Commvault network gateway. For information about setting up a network gateway, see Setting Up the Commvault Network Gateway.

### Container image access

Commvault pulls container images for temporary worker pods that perform data movement during backup and restore operations.

Supported worker pod images include:

Commvault release | Image
--- | ---
Feature Release 38 and later | cvk8sfs
Platform Release 2023 and later | oraclelinux:9
Platform Release 2022E to Feature Release 24 | centos:8
Feature Release 20 | debian:stretch-slim

You can:

- Allow clusters to pull images from Docker Hub

- Configure a private container registry for air-gapped environments

For more information, see Protecting an Air-Gapped Kubernetes Cluster.

Important

Commvault scans worker pod images before each release to verify that no critical vulnerabilities exist.

### Helm application support

If Helm is installed on the Kubernetes access nodes, Commvault can automatically discover, protect, and restore Helm-based applications.

Download the most recent Helm binary for your Kubernetes distribution from helm / helm on GitHub.

#### Requirements

- Install the Helm binary

- Add the Helm binary to the system PATH

- Helm-managed applications must use the following labels:

  - app.kubernetes.io/instance

  - app.kubernetes.io/managed-by

You can disable Helm chart protection if needed. For information about restrictions and known issues, see Restrictions and Known Issues for Kubernetes.

## Architecture support

Commvault supports protection of Linux-based containerized applications running on x86-64 (amd64) and arm64 architectures.

Commvault does not support protection of arm32v5, arm32v6, arm32v7, ppc64le, s390x, mips64le, riscv64, i386, Windows AMD64 container images or environments. For more information, see Architectures other than amd64? in the Docker library.

## Service account requirements

Commvault requires a Kubernetes service account with sufficient permissions to discover and protect resources. You can use either a custom ClusterRole with required permissions or the cluster-admin role.

## Supported Kubernetes distributions and versions

Commvault supports Kubernetes distributions that:

- Are CNCF-certified

- Expose the Kubernetes API server

- Are in active maintenance at the time of the Commvault release

The following Kubernetes distributions are supported for protecting container applications and virtual machines running in Kubernetes.

Kubernetes distribution | Supported releases
--- | ---
Vanilla Kubernetes | 1.36.x-1.20.x
Amazon EKS Amazon EKS on AWS Outposts Amazon EKS Anywhere Amazon EKS Distro | 1.34.x-1.22.x
AKS | 1.34.x-1.25.x Note: Protection of AKS clusters that use Azure Container Storage (ACS) is supported.
Google Anthos | 1.18.x-1.12.x
Google Kubernetes Engine (GKE) | 1.32.x-1.24.x
Oracle Kubernetes Engine (OKE) | 1.32.x-1.25.x
Red Hat OpenShift (RHOCP) Azure Red Hat OpenShift (RHOCP on Azure) Red Hat OpenShift Service on AWS (ROSA) | 4.22-4.9
VMware Tanzu | Tanzu Kubernetes Grid Integrated Edition (TKGi) 1.19-1.15.xx VMware vSphere Kubernetes Service (VKS) (formerly Tanzu Kubernetes Grid (TKG)) v2.5.0-v2.1.0, 1.6.0, or later vSphere 8.0.0 with Kubernetes 1.24 or later

## Storage requirements

Commvault supports protection of PersistentVolumeClaims (PVCs) that use production CSI drivers. See Kubernetes production CSI drivers list in the Kubernetes documentation.

The CSI driver must support:

- Dynamic provisioning for restores

- Volume snapshots for backups

PersistentVolumes must use a registered StorageClass and a corresponding VolumeSnapshotClass.

For NFS-based CSI storage, configure a root-enabled StorageClass to ensure successful file restores. For more information, see Backup Process for Kubernetes.

### Validated CSI drivers

The following CSI drivers are validated by Commvault:

Platform or storage provider | CSI driver | Snapshot verified
--- | --- | ---
Commvault File System | io.hedvig.csi | Yes
AWS Elastic Block Store | ebs.csi.aws.com | Yes
Azure Blob | blob.csi.azure.com | Not available
Azure Disk | disk.csi.azure.com | Yes
Azure File | file.csi.azure.com | Yes
Ceph FS | cephfs.csi.ceph.com | Yes
Ceph RBD | rbd.csi.ceph.com | Yes
GCE Persistent Disk | pd.csi.storage.gke.io | Yes
Hitachi Vantara | hspc.csi.hitachi.com | Yes
HPE | csi.hpe.com | Yes
NetApp | csi.trident.netapp.io | Yes
Oracle Cloud Infrastructure Block Volume | blockvolume.csi.oraclecloud.com | Yes
Portworx | pxd.portworx.com | Yes
vSphere | csi.vsphere.vmware.com | Yes (vSphere CSI driver v2.5 and later supports CSI snapshots)

### Volume snapshot API support

Commvault supports:

- All released versions of the Kubernetes CSI external-snapshotter
- All API versions of VolumeSnapshot custom resources

To identify the API version used by your cluster, run the following command:

    kubectl describe volumesnapshotclass $[volume-snapshot-class-name] | grep -i version

Example output:

    API Version: snapshot.storage.k8s.io/v1

For more information, see the external-snapshotter.

## DISCLAIMER

Certain third-party software and service releases (together, "Releases") may not be supported by Commvault. You are solely responsible for ensuring Commvault’s products and services are compatible with any such Releases.

×

Loading...