Container-Native Storage: Virtual Storage for Kubernetes

Source:-itprotoday.com

Container-native storage is software-defined storage that itself runs in a container on each node of a Kubernetes cluster. Find out how it works and read up on two CNS products on the market.

IT organizations are recognizing the need to support containers for applications both in development and in production. Containers offer a number of benefits, as well as some challenges, particularly around storage. In this article we’ll look at container-native storage, a new technology that offers container environments many of the benefits that hyperconverged infrastructure has brought to VM environments.

Software architectures are evolving from large, complex programs to smaller-component programs or microservices. This distributed architecture allows development work to be spread to more people in different locations. Also called cloud-native development, this process offers many advantages over traditional softw are development. However, cloud-native development requires a different operating environment, one that can support more compute instances (for microservices), as well as the movement of these compute instances from on-premises to the public cloud and between clouds. Containers are the operating environment developers are turning to.

Containers and Kubernetes

Containers are a compute virtualization technology that allows multiple, independent compute instances to be run on the same physical server. Each container includes all libraries and dependencies needed to run software applications, creating an isolated, portable compute environment. Containers, like VMs, are stored as files or images, allowing them to be easily moved between hosts to support load balancing, failure recovery, maintenance, etc., or to the cloud for cloud-native development.

Containers on the same host share the host operating system (OS), unlike a hypervisor, in which each virtual machine includes its own OS. This makes container deployment faster than virtual machines and also means container images are much smaller than VM images, often an order of magnitude smaller. A container orchestration platform is required to configure and manage the large numbers of containers that typically exist in a development or production environment. Kubernetes (K8s) is an open-source, standard orchestration platform that’s offered by most infrastructure vendors.

When you include the hypervisor layer, the resources and cost required to stand up a Kubernetes environment is much less than that of a VM environment. However, containers have no intrinsic way to manage storage, so while containers can be more economical, more agile and more efficient than VMs, the data they create is not persistent.

The Kubernetes standard defines a driver (called a Container Storage Interface, or CSI) to connect traditional storage arrays to a K8s cluster, and most of the major storage vendors offer CSI. However, there is another way to address the need for persistent storage in container environments that offers some unique benefits: container-native storage (CNS).

Container-Native Storage

Container-native storage is a software-defined storage solution that itself runs in a container on each node of a Kubernetes cluster. This SDS layer virtualizes the physical storage – the drives or SSDs – on each node to create a storage pool. This pool of storage capacity can be used by the containers also running on the K8s cluster. Most CNS solutions also include storage services such as replication, snapshots, data reduction (deduplication, compression, thin provisioning), quality of service, encryption, etc.

So, instead of sharing a SAN-attached or direct-attached storage array, a K8s cluster with CNS virtualizes the local storage on each node to create a comprehensive, scalable, compute infrastructure. CNS solutions also run in the public cloud, enabling groups of containers (called pods) to be transferred between the on-premises K8s cluster and one running in the public cloud – and between clouds. This capability creates a hybrid, multicloud infrastructure that supports cloud-native development.

While this is a nascent product category, Red Hat and Portworx each offer a CNS product.

Red Hat

Red Hat’s OpenShift Container Storage is integrated with the OpenShift Container Platform, which is deployed on industry-standard servers or as VMware virtual machines. OCS is built on Ceph, Red Hat’s file, block and object SDS solution, plus the NooBaa object storage operator that delivers S3 APIs for on-premises or cloud-based storage in AWS, Google or Azure. OCS offers a list of enterprise-level data services plus file, block and object storage. Red Hat’s OpenShift is well established in the development community. Adding OCS creates a one-vendor, Kubernetes solution from a Tier 1 supplier.

Portworx

Portworx Enterprise provides persistent block and file storage through a container orchestrator, typically Kubernetes, although the product also supports Docker Swarm, Amazon ECS and others. Portworx can also virtualize block storage from SAN-based arrays on-premises or connect to storage volumes in AWS, Google Cloud Platform, Azure, PKS Cloud and IBM Cloud. Portworx provides snapshots, thin provisioning, stretched clustering and other advanced storage services, in addition to modules for security, data migration, disaster recovery, backup and automated capacity management. While this startup released its first product just four years ago 2016, Portworx has developed a substantial installed base and offers a relatively complete list of enterprise features.

As a scale-out, node-based architecture, a Kubernetes cluster with an embedded CNS offers many of the same potential benefits for container environments that hyperconverged infrastructures have in VM environments. These include flexible scaling, resource efficiency, simplicity of design, integrated management and software-defined operation. For more information, see the Evaluator Group research on software-defined storage.