hamburger icon close icon
Kubernetes Storage

Kubernetes Shared Storage: The Basics and a Quick Tutorial

Kubernetes offers a storage architecture that is quite complex, but very powerful. It lets you create storage volumes without knowledge of the underlying infrastructure. Kubernetes storage volumes are provisioned based on the underlying storage availability and can be used to save data created by containers and to share data between containers.

In this post we’ll review the basics of Kubernetes storage, and provide a quick tutorial on how to set up a Kubernetes pod that shares data between two containers, and exposes it via a Kubernetes service. In addition, we’ll show how NetApp Cloud Volumes ONTAP can help set up persistent storage volumes for your containers dynamically and efficiently.

In this article, you will learn:

How does Kubernetes storage work?

Kubernetes storage is based upon volumes. A volume is an abstracted storage unit that containers (nodes in the Kubernetes cluster) can use to store data, and share data between them.

Kubernetes contains a wide range of storage plugins that let you connect to storage services provided by AWS, Azure, Google Cloud Platform, VMware, and also on-premises hardware.

Volumes and Persistent Volumes

There are regular volumes, which are ephemeral, torn down when their parent pod shuts down. There are also persistent volumes, which are deployed in a similar way as pods, and can provide long-term storage even when the pods accessing them are shut down.

Cluster nodes can provision volumes by issuing claims for storage, and specifying what type of storage they need. Administrators define StorageClass objects that specify which storage resources are available. The Kubernetes cluster searches for a suitable volume based on its StorageClass, and performs binding between a claim and a target volume.

Static vs. Dynamic Provisioning

Kubernetes volumes can be created in two different ways: statically or dynamically. With static provisioning, the cluster has a fixed set of volumes or persistent volumes. Claims for storage are bonded to one of the available volumes if it meets the user’s criteria. These criteria can include things such as high throughput, price and others. If none of the available volumes can meet those criteria, the claim is denied.

A more advanced option is dynamic provisioning, in which storage volumes are created automatically in response to a claim issued by a user. While this is quite powerful, Kubernetes only goes as far as allocating the storage. It does not handle backups, high availability, testing, or other capabilities needed in production environments without third party solutions.

Kubernetes Shared Storage: Quick Tutorial

This tutorial shows how to allow two containers running in the same pod to share data via a non-persistent volume.

The following tutorial steps are summarized, see the full tutorial and code here.

Step 1. Define a Kubernetes pod with two containers

We create a YAML file, called two-containers.yaml that defines a pod with two nodes and a volume called ‘shared-data’.

We have two containers, conatainer1 running an NGINX server and container2 running the Debian OS. Each has the shared volume mounted on a directory, which is specified by the mountPath.


The YAML file runs both containers, and instructs container2 to continually write a timestamp to an index.html file in the mounted storage volume. We’ll want to see that container1 is able to access this file and see the timestamps. apiVersion: v1
kind: Pod
metadata:
    name: two-containers
spec:
    volumes:
      - name: shared-data
      emptyDir: {}
containers:
    - name: first
      image: nginx
      volumeMounts:
        - name: shared-data
        mountPath: /usr/share/nginx/html
    - name: second
      image: debian
      volumeMounts:
        - name: shared-data
        mountPath: /pod-data
      command: ["/bin/sh"]
      args:
          - "-c"       
          - >
           while true; do
           date >> /pod-data/index.html;
           echo Hello from the second container
           >> /pod-data/index.html;          sleep 1;       done

Step 2. Create the pod and try to read the shared file from the first container


We’ll create the pod from the YAML file as follows: $ kubectl create -f two-containers.yaml
Pod/two-containers created

Let’s ask the first container to read the index.html file from its mounted version of the shared volume:
$ kubectl exec -it two-containers -c first -- /bin/bash root@two-containers:/# tail /usr/share/nginx/html/index.html

You should see the timestamps written by the first container.

Step 3. Define a Kubernetes service to enable external access

Let’s see how to expose the shared data to the world. We’ll use this command to create a port forward that opens the pod for external access. Then, the NGINX web server will be able to deliver our index.html file to external users. $ kubectl port-forward two-containers 80:80
Now, access your cluster IP. You can then use a command like the following to view the index.html file and see the timestamps as they are written by the second container, if your cluster is running locally. $ curl http://localhost/

Next Steps in Kubernetes Storage

After this basic tutorial, you’re ready to explore more advanced aspects of Kubernetes storage. We recommend these resources:

1. Learn about the basics of about the basics of Kubernetes persistent storage.
2. See the official tutorial for configuring a pod with persistent storage.
3. Learn how to use NFS in Kubernetes

Kubernetes Shared Storage with Cloud Volumes ONTAP

We’ve seen above how non-persistent volumes can be provisioned, but what if you are running an enterprise-grade use case via Kubernetes and need your data to persist? What if your storage usage is too vast to rely on manual provisioning storage volumes for Kubernetes? NetApp has a solution.

NetApp Cloud Volumes ONTAP, the leading enterprise-grade data management solution, delivers secure, proven storage management services built on AWS, Azure, and Google Cloud cloud compute and storage. With the help of NetApp Trident, storage volumes on Azure Disk, Amazon EBS, or Google Persistent Disk can be dynamically provisioned automatically, without any effort on the user’s part.

Cloud Volumes ONTAP supports enterprise use cases such as file services, databases, DevOps, and application workloads. When it comes to Kubernetes storage, Cloud Volumes ONTAP provides Kubernetes integration for persistent storage requirements of containerized workloads, and supports a strong set of features that aren’t available natively in the cloud, including Kubernetes NFS sharing, high availability, cost-effective persistent data storage protection, Kubernetes cloud storage cost reduction with NetApp storage efficiency feature, cloud automation, and more.

New call-to-action
Yifat Perry, Technical Content Manager

Technical Content Manager

-