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|
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
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:
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.
Amazon Elastic Block Store (EBS) CSI Driver
Konvoy EBS default
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
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
- Driver documentation: azure-disk-storage
- Additional information: azure-disk-dynamic-provisioning
- Azure storage pricing: azure-storage
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
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 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:
- Support for
VolumeSnapShotto create volume snapshots.
- Ensure token authorization and encryption for
- Support for sharing volumes.
- Portworx documentation
- Portworx with CSI for more information.
- Portworx release notes
- Portworx licensing
- Portworx support
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.
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.
- Hedvig Documentation
- Hedvig Release Notes
- Hedvig Technical Overview
- Hedvig Product Datasheet
- Hedvig with Kubernetes
- Persistent Storage for Kubernetes with Hedvig
- Hedvig Container-Native Storage Solution Brief
- hedvig support
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.
- OpenEBS Documentation
- OpenEBS Release Notes
- OpenEBS GitHub Site
- OpenEBS User Guides
- License Information
- MayaData Product