Version 1.5. This version is supported as outlined in the Anthos version support policy, offering the latest patches and updates for security vulnerabilities, exposures, and issues impacting Anthos clusters on VMware (GKE on-prem). Refer to the release notes for more details. This is not the most recent version.

Storage

This page explains GKE on-prem storage concepts.

Summary

GKE on-prem integrates with external block or file storage systems through VMware vSphere storage, Kubernetes in-tree volume plugins (or "drivers"), and Container Storage Interface (CSI) drivers.

GKE on-prem clusters use a default Kubernetes StorageClass to provision storage for stateful workloads on a vSphere datastore. You can also use a StorageClass to provision different storage volumes.

vSphere storage

By default, GKE on-prem clusters use vSphere storage. The admin cluster requires a pre-provisioned vSphere datastore for its etcd data.

When you create a user cluster, GKE on-prem uses the vSphere Kubernetes volume plugin to dynamically provision new virtual machine disks (VMDKs) in a vSphere datastore. (Note that prior 1.2, user clusters used the same datastore as admin clusters.)

The vSphere datastores used by the admin and user clusters may be backed by NFS, vSAN, or VMFS on a block device, such as an external storage array. In a multi-host environment, each block device must be attached to all the hosts in the environment, and the datastore must be configured on each host via the Mount Datastore on Additional Hosts option.

Default storage

GKE on-prem clusters include a default Kubernetes StorageClass, which determines how Kubernetes should provision storage. After Kubernetes provisions storage volumes, they are represented by Kubernetes PersistentVolumes.

The default StorageClass for a user cluster points to a vSphere datastore, which is set in the datastore field of StorageClass' configuration. By default, Kubernetes PersistentVolumes provisioned for the user cluster are VMDKs of that datastore. This is not necessarily the same datastore used by the admin cluster.

In GKE on-prem, Kubernetes StatefulSets (stateful workloads that typically require persistent storage) use PersistentVolumeClaims backed by StorageClasses that point to vSphere storage by default.

Container Storage Interface

Container Storage Interface (CSI) is an open standard API that enables Kubernetes to expose arbitrary storage systems to containerized workloads. When you deploy a CSI-compatible volume driver to a GKE on-prem cluster, workloads can connect directly to a compatible storage device without having to go through vSphere storage.

GKE on-prem supports CSI v1.0. To use CSI in your cluster, you need to deploy the CSI driver provided by your storage vendor. Then, you can configure workloads to use the driver's StorageClass, or set it as the default StorageClass.

We have partnered with many storage vendors to qualify their storage systems with GKE on-prem. See the full list of qualified storage partners.

vSphere CSI driver

By default, GKE on-prem leverages the in-tree volume plug-in from VMware, vSphere Cloud Provider (VCP), which automatically enables support for VMware datastores including vSAN. The vSphere CSI driver is automatically deployed in GKE on-prem clusters, and is available as a preview feature starting with GKE on-prem version 1.5.

Volume cleanup

When you delete a user cluster, volumes provisioned by the in-tree volume plug-in from VMware might not be deleted. However, when deleting a user cluster, volumes provisioned by the vSphere CSI driver are not deleted. You should confirm that all volumes, PVCs, and StatefulSets are deleted before deleting the cluster.

Kubernetes in-tree volume plugins

Kubernetes ships with a number of in-tree volume plugins. You have the option to use any of these to provide block or file storage for your stateful workloads. In-tree plugins enable workloads to connect directly to storage without having to go through vSphere storage.

Whereas vSphere storage automatically provides dynamic provisioning of volumes inside a datastore backed by any iSCSI, FC, or NFS storage device, many of the in-tree plugins don't support dynamic provisioning. They require that you manually create PersistentVolumes.

The following table describes several in-tree volume plugins:

In-tree volume pluginDescriptionSupported access modesDynamic provisioning
Fibre ChannelGeneric storage pluginRead/write single PodNo
iSCSIGeneric storage pluginRead/write single PodNo
NFSGeneric storage pluginRead/write multiple PodsNo

Configuring cluster storage

If you want to provision storage volumes other than vSphere datastores, you can create a new StorageClass in a cluster that uses a different storage driver. Then, you can set the StorageClass as the cluster's default, or configure your workloads use the StorageClass (StatefulSet example).

Troubleshooting

See Troubleshooting Storage.

Further reading