This document is intended for application owners and platform administrators
that run Google Distributed Cloud. This document shows you how to create and use
storage classes for VMs that use VM Runtime on GDC. A StorageClass
lets you define different storage configurations to provide for the various
needs of your VMs.
Before you begin
To complete this document, you need access to Google Distributed Cloud version 1.12.0
(anthosBareMetalVersion: 1.12.0) or higher cluster. You can use any cluster
type capable of running workloads. If needed,
try Google Distributed Cloud on Compute Engine
or see the
cluster creation overview.
Storage classes overview
You use a StorageClass to define the type of storage you make available to
VMs. Different storage classes might map to a different type of storage
hardware, file system, or performance. You can create and use storage classes to
support your compute workloads in VM Runtime on GDC. For more
information, see
Storage Classes.
A default StorageClass can be defined in the custom resource for
VM Runtime on GDC. If you don't define a specific class when you
create a VirtualMachineDisks, this default StorageClass is used. No initial
StorageClass is configured and set as default. In the following section, you
learn how to
set or update this default StorageClass.
Set or update the default StorageClass
Initially, Google Distributed Cloud with VM Runtime on GDC have no default
StorageClass configured. To create a VirtualMachineDisk without specifying a
StorageClass, you must first
create a StorageClass
and then set it as default.
If you want to initially set or update the default StorageClass that
VM Runtime on GDC uses when you create a VirtualMachineDisk, update
the VMRuntime custom resource.
Edit the
VMRuntimecustom resource:kubectl edit vmruntimeAdd or update the
spec.storagesection that specifies the defaultStorageClassto use:apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: true storage: defaultStorageClass: STORAGE_CLASS_NAME ...Edit
STORAGE_CLASS_NAMEwith the name of the defaultStorageClassyou want to use. If you need to first create aStorageClass, see Create aStorageClass.Save and close the
VMRuntimecustom resource in your editor.The
StorageClassyou specified is now used when you now create a virtual machine disk and don't specify aStorageClass. The following section shows you how to create a disk and use a specific StorageClass.Existing
VirtualMachineDiskresources are not updated to use the newly specifiedStorageClass.
Use a specific StorageClass
If you don't want to use the default StorageClass when you create a
VirtualMachineDisk, use the storageClassName field to specify a different
StorageClass.
To use a specific, already-defined StorageClass when you create a
VirtualMachineDisk, complete the following steps:
Create a
VirtualMachineDiskmanifest, such asmy-disk.yaml, in the editor of your choice:nano my-disk.yamlCopy and paste the following YAML manifest:
apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: DISK_NAME spec: size: 10Gi storageClassName: STORAGE_CLASS_NAMEReplace the following values:
DISK_NAME: the name for your disk.STORAGE_CLASS_NAME: theStorageClassto use for your disk. ThisStorageClassmust already exist. If you need to first create aStorageClass, see Create a StorageClass.
Save and close the disk manifest in your editor.
Create the disk using
kubectl:kubectl apply -f my-disk.yaml
Configure storage profiles
Storage profiles provide extra configuration options associated with each
StorageClass. These configuration options include which access mode and volume
mode to use for VirtualMachineDisks that use the StorageClass.
Without a configured storage profile, disks default to the ReadWriteOnce
access mode. This access mode isn't sufficient for production workloads, as
features like live migration don't work. The default volume mode without a
configured storage profile is Filesystem.
VM Runtime on GDC automatically generates one storage profile for
each StorageClass in a cluster. The storage profile is the same name as the
associated StorageClass. The following example output shows that the cluster
has four storage classes and associated profiles:
$ kubectl get storageprofiles
NAME AGE
anthos-system 11d
node-disk 11d
standard 11d
nfs 11d
To edit a storage profile and change the access mode or volume mode, complete the following steps:
Edit the
StorageProfilecustom resource for editing:kubectl edit storageprofile STORAGE_PROFILE_NAMEReplace
STORAGE_PROFILE_NAMEwith theStorageProfileyou want to edit.Add a single entry to the
spec.claimPropertySetslist of theStorageProfile:apiVersion: cdi.kubevirt.io/v1beta1 kind: StorageProfile metadata: name: nfs spec: claimPropertySets: - accessModes: - ACCESS_MODE volumeMode: VOLUME_MODEThe
accessModeandvolumeModeuse the underlying Kubernetes components. The values you set depend on the storage driver you use. Replace the following values as appropriate for the storage you use:ACCESS_MODE: the access mode that you want to use. If supported by the associatedStorageClass, the preferred access mode isReadWriteMany.- Acceptable values include
ReadWriteOnce,ReadOnlyMany,ReadWriteMany, andReadWriteOncePod. If not specified,ReadWriteOnceis used based on the VM Runtime on GDC defaults. For more information, see Access modes.
- Acceptable values include
VOLUME_MODE: the volume mode that you want to use.- Acceptable values include
FilesystemandBlock. If not specified,Filesystemis used based on the Kubernetes defaults. For more information, see Volume modes.
- Acceptable values include
Save and close the
StorageProfilecustom resource in your editor.The storage profile settings you defined are used when you now create any virtual disks. Existing
VirtualMachineDiskresources are not updated to use the defined storage profile settings.