Percona, a provider of open source database services and support, wants to have storage automatically scaled in Kubernetes environments, and has opened up about its efforts.
If a Kubernetes-orchestrated database is growing, it could run out of capacity and constrain applications using it. Percona thinks K8s databases and other cloud-native apps should be able to have their capacity automatically scaled, yet the structure of Kubernetes makes this difficult.
Kubernetes defines the upper level abstract concept of a Persistent Volume (PV) – a piece of storage capacity and its contents, its state, that is not deleted when a container using it is wound down. It persists. Such a PV is defined by K8s admins and can provide block storage, NFS (files), objects, a database or a cloud service. A cloud storage service can, in turn, provision block, file, or object storage. The details of how this is done vary between cloud service providers such as AWS, Azure, and Google.
The provisioned storage uses capacity on disk drives or SSDs attached to the cluster.
Kubernetes also has a StatefulSet concept that persists Pods and includes the ability to persist storage used by those Pods.
Auto-scaling PVs obviously implies that the underlying implemented storage has to be capable of being automatically scaled. That means there needs to be a detection or monitoring function tracking its use, which alerts a scaling function when the use meets a defined threshold.
Containers in Kubernetes Pods request access to persistent storage by issuing requests to K8s called PersistentVolumeClaims (PVCs). These claims include StorageClass specifications, which detail information about the profile of the required PV – such as protection level and quality of service.
Setting up persistent storage in Kubernetes Pods is not simple, and there are many types of storage services that can be used in any particular persistent volume – all of which would need to support auto-scaling for a general capability to exist.
A Percona blog lists some existing but limited ways to enable storage auto-scaling:
- pvc-autoresizer – An open source project that detects when the free amount of storage is below a defined threshold in PVCs and relies on Prometheus metrics. It does not work with K8s StatefulSets and is not integrated with K8s Operators.
- Kubernetes Volume Autoscaler – This increases a PVC’s size automatically when it is becoming full or based on its node usage and is similar to pvc-autoresizer, relying on Prometheus as well.
- EBS Params controller – This does not scale capacity but can control IOPS and throughput parameters for EBS volumes provisioned by EBS CSI Driver.
A Kubernetes Event-Driven Autoscaling (KEDA) resource can automatically scale out container instances (horizontal scaling) for some K8s resources, including Azure Blob Storage based on the blob count in a blob container. It does not support capacity (vertical) scaling, though.
Percona supports the idea of auto-scaling K8s storage and aims to help the development of such a facility. It wants more people to join the Data on Kubernetes community on Slack to help bring this about.
Bootnote
Kubernetes Operators are software extensions using custom resources to manage applications and their components. Red Hat states that they are a method of packaging, deploying, and managing a Kubernetes application – an application-specific controller.
