PersistentVolumeClaim (PVC) requirements


You can use Kubernetes to manage several types of storage used by containers. For BMC Helix, cluster nodes must have access to block storage that is made available to Kubernetes as a Persistent Volume (PV). Claims of reserved memory are then allocated to containers as a Persistent Volume Claim (PVC).

You can configure PersistentVolume and PersistentVolumeClaim in several access modes. The access mode dictates how many nodes or pods can mount and interact with the volume. The following access modes are available:

  • ReadWriteOnce: The volume can be mounted as read-write only by a single node. Multiple pods can use this volume if they are running on the node.
  • ReadWriteOncePod: The volume can be mounted as read-write by multiple nodes. However, only a single Pod can make use of the volume or claim.
  • ReadOnlyMany: The volume can be mounted as read-only by more than one node; for example, NFS.
  • ReadWriteMany: The volume can be mounted as read-write by more than one node; for example, NFS.

BMC Helix makes use of the ReadWriteOnce and ReadWriteMany access modes.

Warning

Important

BMC supports a Bring-Your-Own-Storage class for Kubernetes persistent volumes. Your storage class for the Kubernetes persistent volumes must support volume expansion and dynamic provisioning.

 

 

PVC requirements for BMC Helix Platform

Warning

Important

If you are using VMWare Tanzu to manage your Kubernetes cluster, note the following points:

 

PVC requirements for BMC Helix Operations Management

The following PVC requirements for BMC Helix Operations Management are in addition to the requirements stated for BMC Helix Platform.

 

PVC requirements for BMC Helix Continuous Optimization

The following PVC requirements for BMC Helix Continuous Optimization are in addition to the requirements stated for BMC Helix Platform.

 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC Helix IT Operations Management deployment 26.1