Storage is one of the most critical components of a Containers-as-a-Service platform. Container-native storage exposes the underlying storage services to containers and microservices. Like software-defined storage, it aggregates and pools storage resources from disparate mediums.

Container-native storage enables stateful workloads to run within containers by providing persistent volumes. Combined with Kubernetes primitives such as StatefulSets, it delivers the reliability and stability to run mission-critical workloads in production environments.

Along with the container runtime, container-native storage and container-native networking comprise the layer above the container-optimized operating system in the cloud native stack.

Even though Kubernetes can use traditional, distributed file systems such as network file system (NFS) and GlusterFS, we recommend using a container-aware storage fabric that is designed to address the requirements of stateful workloads running in production. Customers can choose from a variety of open source projects and commercial implementations.

Container-Native Storage Solutions

The cloud native ecosystem has defined specifications for storage through the Container Storage Interface (CSI) which encourages a standard, portable approach to implementing and consuming storage services by containerized workloads.

Ceph, Longhorn, OpenEBS and Rook are some container-native storage open source projects, while Kubera by MayaData, Trident by NetApp, Portworx, Container Storage Platform by Red Hat, Robin by Robin System and StorageOS are commercial offerings combined with support.

Traditional vendors such as NetApp, Pure Storage and VMware also provide storage plugins for Kubernetes.

Addressing Infrastructure Challenges

Managed Kubernetes offerings can reduce the complexity and skills needed to manage large container deployments. Streamlining the infrastructure supporting Kubernetes workloads is one of the most significant criteria when IT professionals evaluate their technology roadmaps.

We’ll be looking at data from the 2019 Cloud Native Computing Foundation survey about current and future Kubernetes adoption plans, along with the container challenges facing Kubernetes users. The results showed that early technology adoption was influenced by then-current vendor relationships. However, satisfaction with these early choices was mixed.

Many Kubernetes users included their current storage and cloud vendors on their cloud native shortlists. And then, users appeared to have trouble shortening that list. All 38 of the survey’s choices were evaluated by at least 5% of Kubernetes users.

With the rise of managed Kubernetes, cloud providers exposed block storage through storage classes and dynamic provisioning. Customers could attach Amazon Elastic Block Store (EBS) volumes on AWS, Azure managed disks, Google Persistent Disks and to Kubernetes worker nodes running in AWS, GCP and Microsoft Azure. This gave cloud providers an edge.

When asked about the cloud native storage they utilize, Amazon EBS, Google Persistent Disk and Azure Disk Storage were cited as the most used by Kubernetes users. In many cases, StatefulSets allowed cluster workloads to access the block storage offered by the cloud provider. While widely adopted, block storage from big cloud providers was not designed specifically for Kubernetes workloads.

Next up on the list were Ceph, CSI and Gluster, with 37% of Gluster users also using Ceph. Ceph and Gluster are distributed file systems that add a persistence layer across multiple nodes. However, they are not well integrated into Kubernetes tools and workflow, so storage administrators may find them more difficult to maintain and configure.

File systems like Ceph are often seen as competitive to cloud storage, versus offerings from more traditional storage companies. Source: The New Stack’s analysis of CNCF’s 2019 survey. Q. Please indicate if your company/organization is evaluating, or currently using in production, any of these cloud native storage projects. What are your challenges in using / deploying containers? Please select all that apply. The chart only shows data for offerings used by at least 1% of respondents with at least one Kubernetes cluster. n=1149.

Lower on the list were offerings from established storage-focused companies like Dell EMC, NetApp and Pure Storage. Initially, Kubernetes had integrated volume plugins to connect to these company’s storage backends. Unfortunately, the upstream Kubernetes distribution became bloated, meaning that any minor update or change to a plugin meant rebuilding and compiling the entire code.

Customers of traditional storage companies were significantly more likely to complain of storage challenges. For example, 46% of Pure Storage customers had challenges handling container-related storage, compared to just 27% for the average Kubernetes user. There was hope on the horizon though, as 13% utilized the Container Storage Interface (CSI). CSI became generally available for Kubernetes in 2019 and eliminates the challenge of constantly needing to integrate upstream. Traditional storage vendors, cloud providers and pure-play container storage companies like Portworx are switching to CSI.

CSI was on the minds of people evaluating new options to address their current container storage challenges. While overall only 13% of Kubernetes users were considering CSI, which jumped to 22% among those that had storage challenges.

While established companies were being considered by some, open source projects were top of mind among those looking for new storage options. Compared to the average respondent, the 27% of Kubernetes users who were storage-challenged were more likely to evaluate Rook (26% vs 16%), Ceph (22% vs 15%), Gluster (15% vs 9%), OpenEBS (15% vs 9%) and MinIO (13% vs 9%). These open source efforts were notably not driven by a need to sell hardware.

For both traditional storage companies and the newer breed of uniquely cloud native storage offerings, users were more likely to cite storage challenges. However, by implementing new approaches like CSI, traditional storage companies were addressing the concerns of their customers. While many users of newer offerings — like MayaData’s OpenEBS, Minio and Portworx — indicated they had storage challenges, they were likely referring to problems they had connecting legacy data stores.

Implementation challenges were common for early adopters of third-party, best-of-breed solutions. As time goes on, it will be interesting to evaluate how effective the new players will be. It could impact the ability of cloud and traditional storage companies to retain their customers in this segment.

Further analysis of Kubernetes users who cited storage challenges (data not shown) reveals that consideration of Rook, Ceph, and OpenEBS is 50% higher among those with storage challenges. All three have CSI drivers.

The Cloud Native Computing Foundation, Dell, MayaData, Portworx and Red Hat are sponsors of The New Stack.

The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Bit.