vSphere Container Storage Plug-in V2.0 and above for native Kubernetes clusters supports file volumes backed by vSAN file shares. File volumes can be created statically or dynamically and mounted by stateful containerized applications. When using file volumes with the vSphere Container Storage Plug-in, you can reference the same shared data among multiple pods spread across different clusters. This is a mandatory requirement for applications that need shareability.

Note: File volumes do not work in conjunction with functionalities such as extend volume and encryption.

Requirements for File Volumes with vSphere Container Storage Plug-in

Before provisioning file volumes, make sure that your vSphere environment is appropriately configured.

  • Verify that your vSphere environment meets necessary requirements, see Compatibility Matrices for vSphere Container Storage Plug-in, Supported Kubernetes Functionality, and Configuration Maximums for vSphere Container Storage Plug-in.
  • Enable and configure the file service in your vSAN cluster configuration to create file share volumes, configure the required file service domains, IP pools, network. For more information, see vSAN File Service.
  • Establish a dedicated file share network connecting all the Kubernetes nodes. Ensure this network is routable to the vSAN File Share network. For more information, see Configuring Network Access to vSAN File Share.
  • Configure the Kubernetes nodes to use the DNS server that was used to configure the file services in the vSAN cluster. This helps the nodes to resolve the file share access points with Fully Qualified Domain Name (FQDN) while mounting the file volume to the pod.

    You can retrieve the vSAN file service DNS configuration by navigating to the Configure tab of your vSAN cluster and clicking File Service.The screenshot shows the vSAN file service DNS configuration under the Configure tab of the vSAN cluster.

  • Configure the Kubernetes secret vsphere-config-secret to specify network permissions and placement of volumes for your vSAN file shares in your vSphere environment. This requirement is optional. For more information on vSphere configuration file for file volumes, see Create a Kubernetes Secret for vSphere Container Storage Plug-in. If these parameters are not specified, vSphere Container Storage Plug-in specifies how to place the file volumes in any of your vSAN datastores with file services enabled. In such cases, the file volumes backed by vSAN file shares using the NFSv4 protocol will assume default network permissions, such as Read-Write privilege and root access to all the IP ranges.
  • Required privilege: Host.Configuration.Storage partition configuration. For information, see vSphere Roles and Privileges.

Considerations when Using File Volumes with vSphere Container Storage Plug-in

When you use the file volumes, consider the following:

  • If you have file shares shared across more than one clusters in your vCenter Server, deleting a PVC with the Delete reclaim policy in one cluster might delete the underlying file share. This action might cause the volume to be unavailable for the rest of the clusters.
  • After you finish setting up file services, get started with vSphere CSI file services integration with your applications. For more information, see a video on Cloud Native Storage and vSAN File Services Integration. For Storage Class, PersistentVolumeClaim, PersistentVolume and Pod specs, see Try-out YAMLs.
  • vSphere Container Storage Plug-in can mount vSAN file service volumes only with NFS 4.1. NFS 3 is not supported.
  • When you request a RWX volume in Kubernetes, vSAN File Service creates an NFS based file share of the requested size and appropriate SPBM policy. One vSAN file share is created per a RWX volume. VMware supports 100 shares per vSAN File Service cluster, which means you can have no more than 100 RWX volumes.