Storage Class
This page describes how to use and configure different storage classes to be used for backups.
A Kubernetes Storage Class is used for automatic hot storage disk provisioning in the tiered storage architecture of Kannika Armory.
It can be configured in two ways:
- on application-level using the
.storage.class
option in the configuration of the operator, - on a per-volume basis using a Volume Storage.
Configuring the storage class using Helm
The default storage class can be configured using operator.config.storage.class
in the Helm chart.
This value will be written to the configuration file of the operator.
Volume Storage Configuration
The Storage Class can be configured in the .spec.volume.storageClass
field of a Volume Storage resource.
Automatic detection of the storage class
The operator attempts to detect which environment it is running in. Based on which environment, it will also attempt to detect which storage class needs to be installed, or needs to be used. Currently, minikube and Google Kubernetes Engine (GKE) are supported.
Minikube
For minikube,
the csi-hostpath-driver
addon must be enabled.
See: CSI Driver and Volume Snapshots
Google Cloud Disks (GCE)
For GKE,
the GcePersistentDiskCsiDriver
must be enabled.
Note that this is enabled by default on new clusters.
The operator will attempt to install a CSI-enabled storage class named kannika-gke-pd-csi
,
if it has not done so yet.
See: Using the Compute Engine persistent disk CSI Driver
Amazon Elastic Block Store (EBS)
No detection is done for AWS EBS yet.
However, you can use the ebs.csi.aws.com
driver by installing it manually.
Here is an example of a StorageClass that can be used that is compatible with the operator and which retains volumes after deletion:
Set the config.storage.class
option to kannika-aws-ebs-csi
to use this storage class in the Helm chart (see above).