kalafoto - stock.adobe.com
Portworx to add application profiles to persistent container storage
Kubernetes persistent container storage that runs from inside the cluster will add application storage profiles for applications such as Apache Kafka, Elasticsearch and Postgres
Container persistent storage specialist Portworx plans to add application-specific profiles to its software.
Portworx is a software-defined product that provides persistent storage capacity for applications that use Kubernetes container orchestration.
CTO Gou Rao could not be exact about timescales but said customers could expect application profiles to be built into Portworx starting in about nine months. “In providing automated storage for Kubernetes implementations we’ve learned a lot about the application layer,” he said.
“So, for example, with ElasticSearch the question arises how do you shard the database, how do you best provision storage for that application?”
Rao also mentioned Kafka and Postgres as other applications for which profiles would be built into Portworx, which works from within the Kubernetes cluster, running in worker nodes, to provide persistent storage to containerised applications.
Rao makes very clear the distinction between storage built in this way and the use of external – SAN and NAS – shared storage.
“People need Portworx when they deploy applications to Kubernetes because an application is not just one machine that can use storage from one machine, but is made of many components on many systems. So, the storage needs to have knowledge of that.”
Taking snapshots
Rao provides the example of taking snapshots of a Cassandra database that could be distributed across many Kubernetes nodes. To be able to track the many components and their states the storage needs to be integrated with the Kubernetes control plane, he said.
Rao is keen to spell out why he thinks traditional external storage isn’t up to the job with containerised applications.
“You can run into a variety of problems with SAN and NAS. For example, with failover you can get something that can’t run on a node because of a shortage of resources, so the data becomes unavailable and you get the ‘stuck volume’ problem, which is probably the number one issue with storage on Kubernetes.”
So, the solution, said Rao, is storage that runs alongside Kubernetes and shares its application-defined control plane, which traditional storage cannot.
Portworx runs in Kubernetes daemon sets and provides Persistent Volumes (PV) as native block storage.
Read more about container storage
- Kubernetes storage 101: Container storage basics. We look at the basics of creating storage and specifying it for applications in container storage using Kubernetes Persistent Volumes and Persistent Volume Claims.
- Container storage 101: What is CSI and how does it work? We look at the container storage interface, which provides an interface to persistent storage in the products of storage array makers, and how it relates to Kubernetes.
When Persistent Volume Claims meet Portworx, PVs are created by agents that help build capacity from storage comprised of hardware drives, cloud capacity or virtual drives such as VMware VMDKs and made available.
Portworx volumes are replicated within the cluster synchronously and asynchronously between clusters for DR, as well as passively replicating to an external object store for backup.
Features in Portworx include PX-Backup which allows users to see and manage their backups.
There is also Autopilot, which is a rules-based engine that can manage capacity and performance. It can, for example, expand capacity or tier data between media if certain thresholds are exceeded. An example would be, “If a PVC exceeds X% usage, expand storage capacity by X%.”
Portworx’s approach to persistent container storage sits alongside the likes of StorageOS and Rook in that it runs in a containerised fashion in Kubernetes and builds the storage control plane into it.
It is also possible to use mainstream hardware or software-defined storage products to expose capacity from them as a PV. That is done using the Container Storage Interface (CSI), which numerous storage suppliers – more than 60 at the time of writing – have written APIs for Kubernetes.
