148422597X Kubernetes Management Design Patterns [Vohra 2017-01-29] {E559F6BB}

CHAPTER 6
Using Volumes
Kubernetes pods are invariably associated with data, and the data can either be made integral to a Docker
container via its Docker image or decoupled from the Docker container.
Problem
If data (in on-disk files) is made integral to a Docker container, the following issues could result:
Solution
• The data is not persistent. The data is removed when a Docker container is restarted,
which could also be due to a container crash.
• The data is container-specific and cannot be shared with other containers as such.
One of the principles of modular design is the Single Responsibility Principle (SRP). Kubernetes volumes
implement the SRP by decoupling the data from a container. A volume is just a directory with or without
data on some medium, which is different for different volume types. A volume is specified in a pod’s spec
and shared across different containers in the pod. A volume must be mounted in each container in a pod’s
spec independently, although it may be mounted in the different containers at the same (or different)
file/directory path. A container in a pod has access to the filesystem inherited from its Docker image and
the filesystem from a Kubernetes volume. A Docker image’s filesystem is still at the root of the filesystem
hierarchy, and a volume can only be mounted on a directory path within the root filesystem. Since volumes
provide access to data outside a pod, volumes mounted in different pods are able to share the same data
from the host or other external storage such as AWS EBS or a GitHub repository. Two types of volume
abstractions or plugins are available: Volume and PersistentVolume. While a Volume is coupled with a pod, a
PersistentVolume is provisioned on the networked cluster and is independent of a pod. Figure 6-1 shows an
example of using an Amazon EBS Volume in a pod.
© Deepak Vohra 2017
D. Vohra, Kubernetes Management Design Patterns, DOI 10.1007/978-1-4842-2598-1_6
135