> Software > Protect > Kubernetes

System requirements for Kubernetes

Verify that your environment meets these requirements to protect Kubernetes workloads with Commvault. This page summarizes supported platforms, infrastructure requirements, storage requirements, and networking considerations.

Access node requirements

Access nodes perform backups, restores, and data movement operations for Kubernetes workloads.

For best performance:

  • Install the Virtual Server package on the access node

  • Place the access node within LAN or MAN proximity to the Kubernetes clusters

  • Ensure network connectivity to the Kubernetes API server and storage endpoints

For configuration details about access nodes, see Configuration for Kubernetes Access Nodes.

Hardware requirements

The requirements vary based on workload type.

Use this configuration when you protect virtual machines running in Kubernetes environments such as Red Hat OpenShift Virtualization.

Access nodes for VM workloads must run inside the OpenShift cluster.

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

Use this configuration for standard Kubernetes workloads, including containers, namespaces, 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

The following operating systems are supported for Kubernetes access nodes:

  • Amazon Linux 2023 AMI

  • Oracle Linux 9.x, 8.6

  • Red Hat Enterprise Linux 9.x, 8.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.

Kubernetes API server connectivity

access nodes must be able to connect to the Kubernetes API server endpoint, either directly or via a Commvault network gateway.

To identify the Kubernetes API server endpoint, run the following command:

kubectl cluster-info

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.

Custom worker pod images aren't supported.

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.

vsphereVolume Snapshot Support

For vSphere-backed Kubernetes environments, Commvault access nodes must be able to connect to the vCenter SDK endpoint URL on port 443.

This connectivity is required to:

  • Authenticate with vCenter

  • Create and delete VMDK snapshots

  • Create VMDK volumes

Kubernetes architectures

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.

Kubernetes service accounts

Commvault requires a Kubernetes service account token with either a custom ClusterRole or the cluster-admin role.

Supported Kubernetes platforms

Commvault supports protection of Kubernetes distributions that meet the following criteria:

  • CNCF-certified Kubernetes distributions that are listed and expose the kube-apiserver.

  • Kubernetes releases that are in active maintenance at the time of the Commvault release into General Availability (GA).

Supported Kubernetes distributions and versions

Kubernetes distribution Supported releases
Vanilla Kubernetes 1.35.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.21-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
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.

Istio service mesh support

Commvault supports protection of Kubernetes applications in clusters that use the Istio.io service mesh. Commvault supports all currently supported Istio releases, for all Kubernetes releases that are supported by Commvault.

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