Storage (storing data) is one of key concepts of working with Kubernetes. There are several options of storing data :

• EmptyDir
• hostPath
• PV (Persistent Volume), PVC (Persistent Volume Claim)
• ConfigMap
• Secrets
• CloudDisk
• StatefulSets

EmptyDir concept is used when there are more than containers in single Pod and they need to share data, yaml example is shown here. In spec section there is a volumes section defining set of volumes. With using emptyDir concept, there is emptyDir parameter along with name, and each container has a volumeMounts section, mountPath parameter of every volumeMount points to the directory in the container where shared data will be “copied”. There is also a volumes parameter that describes mounting data (note that volumeMounts are inside the Pod, volumes are outside the Pod). Every write to the directory will cause the written data to be published in appropriate directories of other containers. EmptyDir concept is applicable, for example, in case when there are 3 containers in one pod, one container clones the data from github, another one
assembles war file, third one executes war file – they have to share data.

hostPath concept is used for storing data from the Pod to given folder on the Node – see yaml script. Even after the Pod is deleted, the data will still be present on the host. Note that folder on the Node (path in hostPath section) must exist on the Node, otherwise it won’t be created automatically and Pod will fail to be created. Since hostPath is tightly coupled with the Node (data won’t be published on other nodes), hostPath is applicable when it is surely known what Node will be used (for example, storing etcd Pod information on Master).

PV(Persistent Volume), PVC (Persistent Volume Claim) is a concept of having so called Persistent Volumes in the cluster – see example. PV itself does not create folders on any Node, it just creates the objects. Default PV capacity is 1000Mi. Also there is one or more PVCs in the cluster – see example . Note that volumeName value in PVC script should match PV name (so PVC claims PV). The next step is creating a Pod that will use PVC – see example. Same volumes concept is used, but with persistentVolumeClaim parameter with claimName value matching PVC name. PVC will attach Pod to the Persistent Volume. And the folder will be created by Kubernetes automatically when creating a Pod, unlike with the hostPath concept.

Persistent Volume itself does not resolve all the problems. Imagine, that Pod is scheduled for some certain Node (let’s say, node1) and folder is created on node1. Then Pod get recreated, but on node2. But the data won’t “follow” the Pod. The data will be lost for the Pod. That is where Storage (Network File System) Solutions help (see Types of Persistent Volumes here). More information about how to configure and work with NFS (Network File System) is available here. Then Persistent Volume path will point to some place in Cloud Storage, and thus the data will always be available to the Pod.

Sometimes it is not the best solution to hold a bunch of PVs in the cluster, not knowing when and (whether or not) they will be consumed by the pods. It is possible not to use PV, but dynamically generate so called CloudDisk, that will be tied with PVCs and thus be available to pods.