草榴社区

Persistent Storage and Cloud-Native Applications

Cloud-native applications are deployed to elastic container environments, which separate the logical and physical states of storage. A container may have a persistent logical residence, but it’s not attached to any single physical host. This transience is due to the inherently ephemeral nature of containers.

A container is only spun up when its microservice is needed to perform a function within the application. As soon as that function is complete, the container is shut down or deleted until it’s needed again. The next time that container – or an exact copy – is spun up again, it could be on a different physical host.

This feature makes cloud-native applications extremely scalable and elastic, so you only need to manage and pay for resources that are actively in use by your application. Cloud-native apps are also highly resilient because if a particular container or host fails, you can always start up new instances on a different host.

However, since containers are physically transient and ephemeral, they didn’t initially support persistent storage. When a container was powered down or deleted – which happens often – any data created within that container would be destroyed. This scenario is fine for some functions that generate data that doesn’t require maintenance but presents a problem for cloud-native applications that require data retention and sharing.

To get around this issue, you need persistent external storage accessible by containers no matter where they physically reside or how frequently they’re deleted.

How Persistent Storage Works With Cloud-Native Applications

There are three general approaches to persistent storage for cloud-native applications:

• Named Volume Mapping. A named volume is a storage volume on a host within the container cluster. Any container within the cluster can be mapped to that volume, whether or not it resides on the same physical host. Once a container has that mapping, it can be moved, shut down, or deleted at will, and its data will persist on the named volume. Any new instances of that container will retain the same mapping as well.
• Kubernetes CSI. Kubernetes is a popular platform for orchestrating cloud-native containers. The Kubernetes Container Storage Interface, or CSI, provides options for linking containers to persistent storage volumes. It uses Persistent Volumes (PVs) or cluster resources that supply storage to pods (groups of containers) in a variation of the named volume approach. Users access persistent volumes using a PersistentVolumeClaim (PVC), which crates a separate pod for PV access.
• Persistent Storage Tools. There are also various third-party and open-source tools that provide persistent storage-as-a-service (SaaS) for cloud-native applications. This approach is beneficial for hybrid or multi-cloud deployments in which a cloud-native application may run on containers spanning multiple cloud or on-premises environments. Some of these tools make persistent storage volumes appear as container-attached storage resources. Since these storage volumes look like containers, they are easily managed by container orchestration solutions like Kubernetes. These volumes use a similar architecture to Amazon Elastic Block Store (EBS), making this approach well-suited for AWS deployments.

Another approach uses OpenStorage SDK-based plugins that manage and provision persistent storage volumes using multi-host clusters. These plugins adapt the Kubernetes CSI API set, including PV and PVC, so they work well with Kubernetes deployments.