9. Storing and Reading Data on Disk

Overview

This chapter introduces the concept of using Volumes to store or read data from the containers running inside pods. By the end of this chapter, you will be able to create Volumes to temporarily store data in a pod independent of a container's life cycle, as well as share the data among different containers inside the same pod. You will also learn how to use PersistentVolumes (PVs) to store data on your cluster independent of the pod life cycle. We will also cover how to create PersistentVolumeClaims (PVCs) to dynamically provision volumes and use them inside a pod.

Introduction

In previous chapters, we created Deployments to create multiple replicas of our application and exposed our application using Services. However, we have not yet properly explored how Kubernetes facilitates applications to store and read data, which is the subject of this chapter.

In practice, most applications interact with data in some way. It's possible that we may have an application that needs to read data from a file. Similarly, our application may need to write some data locally in order for other parts of the application, or different applications, to read it. For example, if we have a container running our main application that produces some logs locally, we would want to have a sidecar container (which is a second container running inside the pod along with the main application container) that can run inside the same pod to read and process the local logs produced by the main application. However, to enable this, we need to find a way to share the storage...

Volumes

Let's say we have a pod that stores some data locally on a disk. Now, if the container that's storing the data crashes and is restarted, the data will be lost. The new container will start with an empty disk space allocated. Thus, we cannot rely on containers themselves even for the temporary storage of data.

We may also have a case where one container in a pod stores some data that needs to be accessed by other containers in the same pod as well.

The Kubernetes Volume abstraction solves both of these problems. Here's a diagram showing Volumes and their interaction with physical storage and the application:

Figure 9.1: Volume as a storage abstraction for applications

As you can see from this diagram, a Volume is exposed to the applications as an abstraction, which eventually stores the data on any type of physical storage that you may be using.

The lifetime of a Kubernetes Volume is the same as that of the pod that uses it. In...

Persistent Volumes

The Volumes we have seen so far have the limitation that their life cycle depends on the life cycle of pods. Volumes such as emptyDir or hostPath get deleted when the pod using them is deleted or gets restarted. For example, if we use Volumes to store user data and inventory records for our e-commerce website, the data will be deleted when the application pod restarts. Hence, Volumes are not suited to store data that you want to persist.

To solve this problem, Kubernetes supports persistent storage in the form of a Persistent Volume (PV). A PV is a Kubernetes object that represents a block of storage in the cluster. It can either be provisioned beforehand by the cluster administrators or be dynamically provisioned. A PV can be considered a cluster resource just like a node and, hence, it is not scoped to a single namespace. These Volumes work similarly to the Volumes we have seen in previous sections. The life cycle of a PV doesn't depend on the life cycle...

Dynamic Provisioning

In previous sections of this chapter, we saw that the cluster administrator needs to provision PVs for us before we can use them as storage for our application. To solve this problem, Kubernetes supports dynamic volume provisioning as well. Dynamic volume provisioning enables the creation of storage volumes on-demand. This eliminates the need for administrators to create volumes before creating any PVCs. The volume is provisioned only when there's a claim requesting it.

In order to enable dynamic provisioning, the administrator needs to create one or more storage classes that users can use in their claims to make use of dynamic provisioning. These StorageClass objects need to specify what provisioner will be used along with its parameters. The provisioner depends on the environment. Every cloud provider supports different provisioners, so make sure you check with your cloud provider if you happen to create this kind of storage class in your cluster.

...

Summary

As we mentioned in the introduction, most applications need to store or retrieve data for a lot of different reasons. In this chapter, we saw that Kubernetes provides various ways of provisioning storage for not just storing the state of an application, but also for the long-term storage of data.

We have covered ways to use storage for our application running inside pods. We saw how we can use the different types of Volumes to share temporary data among containers running in the same pod. We also learned how to persist data across pod restarts. We learned how to manually provision PVs to create PVCs to bind to those Volumes, as well as how to create pods that can use these claims as Volumes mounted on their containers. Next, we learned how to request storage dynamically using only the PVCs with pre-created storage classes. We also learned about the life cycle of these volumes with respect to that of the pods.

In the next chapter, we will extend these concepts further...