Automated storage options in cloud providers

Default storage providers in Konvoy

When deploying Konvoy using a supported cloud provisioner (AWS, Azure, or GCP), Konvoy automatically configures native storage drivers for the target platform. In addition, Konvoy deploys a default StorageClass for dynamic persistent volume (PV) creation.

Cloud Provisioner Driver Default Storage Class
AWS aws-ebs-csi-driver awscsiprovisioner
Azure azuredisk-csi-driver azurediskprovisioner
GCP gcpdisk-csi-driver gcpdiskprovisioner

When a default StorageClass is specified, persistent volume claims (PVCs) can be created without needing to specify the storage class. For instance, to allocate storage using the default provisioner, simply create a PVC with the following:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi

To start the provisioning of a volume, launch a pod which references the PVC:

...
    volumeMounts:
    - mountPath: /data
      name: persistent-storage
...
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: my-pv-claim

Multiple Storage Classes

The default StorageClass provisioned with Konvoy is acceptable for most workloads and offers a good cost to performance ratio. If your workload has different requirements, you can create additional StorageClass types with specific configurations.

In some instances you can change the default StorageClass. Refer to this procedure:

Driver Information

All default drivers implement the Container Storage Interface(CSI). The CSI provides a common abstraction to container orchestrators for interacting with storage subsystems of various types. Each driver has specific configuration parameters which effect PV provisioning. This section details the default configuration used with Konvoy with links to driver documentation, if further customization is required.

NOTE: StorageClass parameters cannot be changed after creation. To use a different volume configuration, you must create a new StorageClass

Amazon Elastic Block Store (EBS) CSI Driver

Konvoy EBS default StorageClass:

allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubernetes.io/description: AWS EBS CSI provisioner StorageClass
    storageclass.kubernetes.io/is-default-class: "true"  # This tells kubernetes to make this the default storage class
  name: awsebscsiprovisioner
parameters:
  type: gp2  # General Purpose SSD
provisioner: ebs.csi.aws.com
reclaimPolicy: Delete  # volumes are automatically reclaimed when no longer in use and PVCs are deleted
volumeBindingMode: WaitForFirstConsumer  #  Physical volumes will not be created until a pod is created that uses the PVC

Konvoy deploys with gp2 (general purpose SSDs) EBS volumes.

Azure CSI Driver

Konvoy Azure default StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubernetes.io/description: Azure Disk Storage class
    storageclass.kubernetes.io/is-default-class: "true"
  name: azurediskprovisioner
parameters:
  cachingMode: ReadOnly # hypervisor local, RO caching
  kind: managed
  skuname: "StandardSSD_LRS"  # Standard (lower cost) SSDs with local redundancy
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Google Compute Engine CSI Driver (Beta)

The GCE driver is still in beta but has been tested with Konvoy native workloads, such as Elasticsearch and Prometheus.

Konvoy GCE default StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcpdiskprovisioner
  annotations:
    kubernetes.io/description: Google Compute Engine Persistent Disk (GCE PD) Storage class
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
parameters:
  type: pd-ssd
  replication-type: none