This article is based on a summary originally sourced from itprotoday.com (2020). Product details reflect the state of the market at the time of original publication.
The Storage Problem in Container Environments
As organizations adopt containers for both development and production workloads, a fundamental challenge surfaces: containers are stateless by design. Any data written inside a container is lost when that container stops or is rescheduled to another node. For applications that need to persist data—databases, message queues, user-generated content—this is a serious operational problem.
Two broad approaches address persistent storage for Kubernetes clusters:
- External storage arrays with a Container Storage Interface (CSI) driver – the Kubernetes-standard way to connect traditional SAN or NAS arrays to a cluster.
- Container-native storage (CNS) – software-defined storage that runs inside the cluster itself, virtualizing local drives on each node into a shared, managed storage pool.
This article focuses on the second approach: what CNS is, how it works architecturally, and what distinguishes it from attaching an external array.
Quick Recap: Containers and Kubernetes
Before examining CNS, it helps to understand the environment it serves.
Containers vs. Virtual Machines
Containers are a lightweight compute virtualization technology. Multiple containers run on the same host, sharing the host operating system kernel rather than each carrying a full OS copy (as VMs do under a hypervisor). This shared-kernel model means:
- Container images are significantly smaller than VM images.
- Containers start and stop much faster than VMs.
- More workloads can be packed onto a given host.
Each container bundles its own libraries and dependencies, making it portable across hosts and cloud environments.
Kubernetes as the Orchestration Layer
Kubernetes (K8s) is the dominant open-source platform for orchestrating large numbers of containers. It schedules containers across cluster nodes, handles failure recovery, manages networking, and—via the Container Storage Interface (CSI)—connects external storage to running workloads. Most major infrastructure and storage vendors ship a CSI driver for their products.
What Is Container-Native Storage?
Container-native storage is a software-defined storage (SDS) layer that runs as containers on every node of a Kubernetes cluster. Rather than connecting to an external storage array, CNS virtualizes the raw drives or SSDs already present on each node and aggregates them into a single, cluster-wide storage pool. That pool is then exposed to application pods running in the same cluster.
The architecture is analogous to hyperconverged infrastructure (HCI) in the VM world: compute and storage are co-located on the same nodes, managed through a unified software layer, and scale out together by adding nodes.
Core Capabilities Typically Provided by CNS
- Persistent volumes – block and/or file storage that survives pod restarts and rescheduling.
- Replication – data is mirrored across nodes for fault tolerance.
- Snapshots and clones – point-in-time copies for backup, testing, and CI/CD pipelines.
- Data reduction – deduplication, compression, and thin provisioning to improve capacity efficiency.
- Quality of Service (QoS) – I/O prioritization between workloads.
- Encryption – data-at-rest encryption for compliance and security requirements.
- Multi-cloud portability – pods and their storage volumes can be migrated between on-premises clusters and public cloud environments.
CNS vs. External Storage Arrays with CSI
| Dimension | External Array + CSI | Container-Native Storage |
|---|---|---|
| Storage location | Dedicated external hardware | Local drives on each K8s node |
| Scaling model | Scale storage and compute independently | Scale-out: add nodes to grow both |
| Management | Separate array management tools | Integrated with Kubernetes APIs |
| Latency | Network hop to array | Local I/O path (potentially lower latency) |
| Vendor dependency | Storage vendor + K8s vendor | Often a single CNS vendor |
| Operational model | Familiar to storage teams | Kubernetes-native; familiar to DevOps teams |
Neither approach is universally superior. Organizations with large existing SAN investments and separate storage teams may prefer the CSI route. Teams running cloud-native workloads that need hybrid/multicloud mobility often find CNS a better fit.
Notable CNS Products (as of 2020)
At the time of the original article, two prominent CNS products were available. The market has evolved since 2020; treat the details below as a starting point for further research rather than a current product comparison.
Red Hat OpenShift Container Storage (OCS)
Red Hat’s OpenShift Container Storage is tightly integrated with the OpenShift Container Platform and can be deployed on bare-metal servers or as VMware virtual machines. OCS is built on two open-source foundations:
- Ceph – Red Hat’s mature software-defined file, block, and object storage solution.
- NooBaa – an object storage operator that exposes S3-compatible APIs, supporting on-premises data as well as data stored in AWS, Google Cloud, or Azure.
OCS delivers file, block, and object storage with enterprise data services, all within a single-vendor Kubernetes stack. Its reliance on Ceph, a widely deployed open-source project, provides a degree of vendor-lock-in mitigation compared to proprietary alternatives.
Portworx Enterprise
Portworx Enterprise provides persistent block and file storage through a container orchestrator, with Kubernetes as the primary target, though it also supported Docker Swarm, Amazon ECS, and others at the time of writing. Beyond local node storage, Portworx could virtualize block storage from SAN arrays or connect to cloud storage volumes across AWS, Google Cloud Platform, Azure, PKS Cloud, and IBM Cloud.
Its feature set included:
- Snapshots and thin provisioning
- Stretched clustering across availability zones
- Disaster recovery and backup modules
- Security and encryption controls
- Data migration tooling
- Automated capacity management
Portworx was founded in 2015 and released its first product in 2016. Despite being a relatively young company at the time, it had built a substantial enterprise customer base by 2020. (Note: Pure Storage acquired Portworx in 2020.)
CNS and the Hyperconverged Analogy
The parallel between CNS for Kubernetes and hyperconverged infrastructure (HCI) for VMware environments is useful for understanding what CNS delivers operationally:
- Flexible scaling – add nodes to increase compute and storage simultaneously.
- Resource efficiency – no separate storage array hardware to provision or maintain.
- Simplified design – one infrastructure type to deploy, monitor, and support.
- Integrated management – storage is managed through Kubernetes-native interfaces (kubectl, Helm, operators) rather than separate storage management consoles.
- Software-defined operation – storage policies are expressed as code, fitting naturally into GitOps and Infrastructure-as-Code workflows.
Key Considerations Before Adopting CNS
CNS is a compelling architecture, but it is not without trade-offs to evaluate:
- Node storage requirements – each node must have local drives (NVMe SSDs are preferred for performance). Nodes with no local storage cannot contribute to the pool.
- Resource overhead – running storage software on the same nodes as application workloads consumes CPU and memory. Right-size node resources accordingly.
- Operational maturity – Kubernetes storage is a specialist area. Teams need to understand persistent volumes, storage classes, and volume lifecycle management.
- Data durability – replication across nodes is the primary data protection mechanism. Replication factor and node failure tolerance must be planned carefully.
- Vendor lock-in – CNS solutions vary in their use of open-source components vs. proprietary formats. Assess migration paths before committing.
Summary
Container-native storage addresses one of Kubernetes’s most significant operational gaps—persistent, managed storage—by embedding a software-defined storage layer directly into the cluster. By virtualizing local node drives into a shared pool, CNS eliminates dependency on external arrays for many workloads, enables hybrid and multicloud portability, and aligns storage management with Kubernetes-native tooling. As the ecosystem has matured since 2020, the range of available CNS solutions has grown; the architectural principles described here remain foundational to evaluating any of them.