Chapter 6. Storage and Running Stateful Applications

In this chapter, we will discuss how to attach persistent volumes and create storage for stateful applications and data. We will walk through storage concerns and how we can persist data across pods and the container life cycle. We will explore the PersistentVolumes types as well as PersistentVolumeClaim. Finally, we will take a look at the new StatefulSets release in version 1.5.

This chapter will discuss the following topics:

• Persistent storage
• PersistentVolumes
• PersistentVolumeClaims
• StorageClasses
• StatefulSets

Persistent storage

So far, we only worked with workloads that we could start and stop at will, with no issue. However, real-world applications often carry state and record data that we prefer (even insist) not to lose. The transient nature of containers themselves can be a big challenge. If you recall our discussion of layered file systems in Chapter 1, Introduction to Kubernetes, the top layer is writable. (It's also frosting, which is delicious.) However, when the container dies, the data goes with it. The same is true for crashed containers that Kubernetes restarts.

This is where volumes or disks come into play. A volume that exists outside the container allows us to save our important data across containers outages. Further, if we have a volume at the pod level, data can be shared between containers in the same application stack and within the same pod.

Docker itself has some support for volumes, but Kubernetes gives us persistent storage that lasts beyond the lifetime of a single container...

StatefulSets

The purpose of StatefulSets is to provide some consistency and predictability to application deployments with stateful data. Thus far, we have deployed applications to the cluster defining loose requirements around needed resources such as computer and storage. The cluster has scheduled our workload on any node that can meet these requirements. While we can use some of these constraints to deploy in a more predictable manner, it will be helpful if we had a construct built to help us provide this consistency.

Note

StatefulSets were set to GA in 1.6 as we went to press. There were previously beta in version 1.5 and were known as PetSets prior to that (alpha in 1.3 and 1.4). 

This is where StatefulSets come in. StatefulSets provide us first with numbered and reliable naming for both network access and storage claims. The pods themselves are names with the following convention, where N is from 0 to the number of replicas:

"Name of Set"-N

This means that a Statefulset called db with 3...

Summary

In this chapter, we explored a variety of persistent storage options and how to implement them with our pods. We looked at PersistentVolumes and also PersistentVolumeClaims, which allow us to separate storage provisioning and application storage requests. Additionally, we looked at StorageClasses for provisioning groups of storage according to a specification.

We also explored the new StatefulSets abstraction and learned how we can deploy stateful applications in a consistent and ordered manner. In the next chapter, we will look at how to integrate Kubernetes with Continuous Integration and Delivery pipelines.

References

1. https://cloud.google.com/persistent-disk/
2. HTTP Whalesay is an adaptation of Docker whalesaym which is in-turn an adaptation of Linux cowsay (circa 1999, Tony Monroe) - https://hub.docker.com/r/docker/whalesay/