Storage for Kubernetes

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services. It facilitates both declarative configuration and automation and has rapidly gained popularity with a growing ecosystem. It’s now viewed as the de-facto orchestration platform for containers by many. This blog looks at why storage for Kubernetes is important.

Why Kubernetes

Kubernetes provides the framework to run distributed systems resiliently. It takes care of scaling and failover for applications, provides deployment patterns, and more. It provides you with:

  • Service discovery and load balancing
  • Application deployment and automation
  • Automated rollouts and rollbacks
  • Automatic bin packing
  • Self-healing

Storage orchestration for Kubernetes

Kubernetes allows users to automatically mount a storage system of choice, such as local storage, public cloud providers, and more. You still need to provide the underlying storage system.

Yet almost all production applications are stateful, i.e. require some sort of external storage. To run applications which require persist storage within containers, a layer is needed to provide persistent storage to those containers, independent of the lifecycle of the containers themselves.

Kubernetes provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. If you’re new to integrating persistent storage with Kubernetes, there are a few terms to understand. Here they are:

  • Container Storage Interface (CSI): This is a specification that allows a standardized way for all container orchestrators to connect with storage solutions like StorageOS. Before CSI was released in Kubernetes, storage providers had to write their integration layer directly into the Kubernetes source code. This made updates difficult and time consuming as any bugs could crash Kubernetes.
  • Storage Class: A Kubernetes Storage Class is a way for admins to pre-define the types of storage that Kubernetes users will be able to provision and attach to their applications.
  • Persistent Volume (PV): A Persistent volume is a virtual storage instance added as a volume to the cluster. The PV can point to either physical storage hardware or to software-defined storage like StorageOS.
  • Persistent Volume Claim (PVC): This is a request to provision a specific type and configuration of storage.

It’s possible, with software-defined storage like StorageOS integrated with Kubernetes, to use Kubernetes to dynamically provision storage resources as well as compute resources, giving users the same agility and scalability for storage that Kubernetes already provides for compute.

StorageOS for Kubernetes

StorageOS is a cloud native storage for Kubernetes solution. It can be used for provisioning PVs and when deployed:

  • Aggregates storage across all nodes in a cluster into a pool.
  • Allows volumes to be provisioned from the pool and for containers to mount those volumes from anywhere in the cluster.
  • Transparently redirects reads and writes to the appropriate volume, so the container is unaware of whether it is accessing local storage or remote storage.
  • Thin provisions volumes to avoid consuming disk space unnecessarily.

StorageOS integrates transparently with Kubernetes. Users can provide standard PVC definitions and StorageOS will dynamically provision them. Using StorageOS makes it possible to handle data through Kubernetes, and get the same declarative, application-centric interface to manage storage resources that Kubernetes provides for compute. Using a software-defined storage layer deployed as a container, like StorageOS, ensures that storage platform is portable and platform agnostic – allowing the same declarative configuration to be used on-premises as well as in the cloud.

Try StorageOS with Kubernetes

StorageOS is free to try. The StorageOS Cluster Operator is a Kubernetes native application developed to deploy and configure StorageOS clusters, and assist with maintenance operations. We recommend its use for standard installations.

The operator is a Kubernetes controller that watches the StorageOSCluster CRD. Once the controller is ready, a StorageOS cluster definition can be created. The operator will deploy a StorageOS cluster based on the configuration specified in the cluster definition. You can read more about the prerequisites for StorageOS, steps to install at our documentation and a step by step self-evaluation guide to help you get started.


Author: Danielle Cook

Danielle is the Marketing Director at StorageOS.

  • Customer Case Study: StorageOS provides MSP, Civo with Cloud Native StorageRead Now

  • Blog: Using the RabbitMQ Kubernetes Operator with Persistent DataRead Now

  • Performance Benchmarking Cloud Native Storage Solutions for KubernetesDownload Now

  • Webinar: Register for Accelerating Kubernetes Onboarding and Application Transformation on 18th August, 2021 at 4pm (BST)Register Now