How to share storage between Kubernetes pods?

Question

I am evaluating Kubernetes as a platform for our new application. For now, it looks all very exciting! However, I’m running into a problem: I’m hosting my cluster on GCE an

Answer 1

Google recently released cloud filestore, with a tutorial here: https://cloud.google.com/filestore/docs/accessing-fileshares

Might be a good alternative to cloud storage/buckets for some scenarios.

Answer 2

First of all. Kubernetes doesn't have integrated functionality to share storage between hosts. There are several options below. But first how to share storage if you already have some volumes set up.

To share a volume between multiple pods you'd need to create a PVC with access mode ReadWriteMany

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
    name: my-pvc
spec:
    accessModes:
      - ReadWriteMany
    storageClassName: myvolume
    resources:
        requests:
            storage: 1Gi

After that you can mount it to multiple pods:

apiVersion: v1
kind: Pod
metadata:
  name: myapp1
spec:
  containers:
...
      volumeMounts:
        - mountPath: /data
          name: data
          subPath: app1
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: 'my-pvc'
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp2
spec:
  containers:
...
      volumeMounts:
        - mountPath: /data
          name: data
          subPath: app2
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: 'my-pvc'

Of course, persistent volume must be accessible via network. Otherwise you'd need to make sure that all the pods are scheduled to the node with that volume.

There are several volume types that are suitable for that and not tied to any cloud provider:

• NFS
• RBD (Ceph Block Device)
• CephFS
• Glusterfs
• Portworx Volumes

Of course, to use a volume you need to have it first. That is, if you want to consume NFS you need to setup NFS on all nodes in K8s cluster. If you want to consume Ceph, you need to setup Ceph cluster and so on.

The only volume type that supports Kubernetes out of the box is Portworks. There are instruction on how to set it up in GKE.

To setup Ceph cluster in K8s there's a project in development called Rook.

But this is all overkill if you just want a folder from one node to be available in another node. In this case just setup NFS server. It wouldn't be harder than provisioning other volume types and will consume much less cpu/memory/disk resources.

Answer 3

Helm: if you use helm to deploy

If you have a PVC that only supports RWO and you want many pods to be able to read from the same PVC and share that storage, then you can install the helm chart stable/nfs-server-provisioner if your cloud provider does not support RWX access mode.

This chart provisions "out-of-tree" storage PVCs with RWX access mode that access the underlying PVC from a cloud provider that only supports RWO, like Digital Ocean.

In your pods, you mount the PVC provisioned by the nfs server and you can scale them while they read and write from the same PVC.

Important!

You have to modify the values file to add configuration suited to your deployment like your storage class.

For more information on the chart: https://github.com/helm/charts/tree/master/stable/nfs-server-provisioner

Answer 4

A bit late to answer this question but from my experience thus far of Kubernetes / MSA, the issue here is more in your design pattern. One of the fundamental design patterns that continues to come up quite often in MSA is the proper encapsulation of your services, which also includes its data.

Your service should look after the data that is related to its area of concern and, much like OOP, should allow access to this data to other services via an interface (an API, PUBSUB message etc). Multi-service access to data is an anti-pattern akin to global variables in OOP.

I assume that Google have the same opinion as well and this is why Kubernetes is set up in this fashion.

As an example, if you where looking to write logs, you should have a log service which each service can call with the relevant data it needs to log. Writing directly to a shared disk means that you'd need to update every container if you change your log directory structure etc or decided to add extra functionality like emails on errors.