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. The table below lists the driver and default StorageClass for each supported cloud provisioner.

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, 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 for drivers used with Konvoy. This section also has 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

On Premises and other storage options

In an on premises situation, accessible storage can be used for PV and PVCs. Using the Kubernetes CSI and third party drivers, you can use your local volumes and other storage devices in your data center. Possible storage and third party driver options are:

Portworx

Portworx is a solution for running stateful containers, designed with DevOps in mind. With Portworx, you can manage any database or stateful service on any infrastructure using Kubernetes. Portworx solves the five most common problems DevOps teams encounter when running stateful services in production: persistence, high availability, data automation, security, and support for multiple data stores and infrastructure.

Portworx offers the following features:

  • Provision PersistentVolumes and PersistentVolumeClaims.
  • Support for VolumeSnapShot to create volume snapshots.
  • Ensure token authorization and encryption for PersistenVolumeClaim and StorageClass objects.
  • Support for sharing volumes.

Pure Storage

Pure Storage provides dynamic storage provisioning capabilities for stateful applications on demand.

Pure Storage offers the following features:

  • On demand automated container storage.
  • File and block on shared infrastructure.
  • Seamless scaling across arrays without the need for manual intervention.
  • Automatic failover that does not disrupt current running services.

Hedvig

The Hedvig Distributed Storage Platform provides a modern software solution that lets you tailor a flexible and efficient data management system built on industry-standard x86 server hardware to support any application, hypervisor, container, or cloud.

Hedvig offers the following features:

  • Dynamic provisioning of application-tailored storage for containers.
  • Data persistence and always-available volumes, even for migrated containers.
  • Support for containers, VMs, and bare metal. This eliminates the need to replace or introduce additional storage silos.
  • Hybrid cloud and multi-cloud applications.

Mayadata OpenEBS

MayaData offers software to accelerate the building and operations of stateful applications on Kubernetes based clouds, whether on-premises, on public or hybrid clouds. Mayadata leverages the open source OpenEBS and other open source components.

OpenEBS is the leading open-source project for container-attached and container-native storage on Kubernetes. OpenEBS adopts a Container Attached Storage (CAS) approach, where each workload is provided with a dedicated storage controller. OpenEBS implements granular storage policies and isolation that enables users to optimize storage for each specific workload.

OpenEBS runs in user space and does not have any Linux kernel module dependencies.

NOTE: Support licenses are available for the Portworx and Purestorage products. Refer to their company support sites for more information.