7 Pod storage and the CSI

 

This chapter covers

  • Introducing the virtual filesystem (VFS)
  • Exploring Kubernetes in-tree and out-of-tree storage providers
  • Running dynamic storage in a kind cluster with multiple containers
  • Defining the Container Storage Interface (CSI)

Storage is complex, and this book won’t cover all the storage types available to the modern app developer. Instead, we’ll start with a concrete problem to solve: our Pod needs to store a file. The file needs to persist between container restarts, and it needs to be schedulable to new nodes in our cluster. In this case, the default baked-in storage volumes that we’ve already covered in this book won’t “cut the mustard”:

  • Our Pod can’t rely on hostPath because the node itself may not have a unique writeable directory on its host disk.
  • Our Pod also can’t rely on emptyDir because it is a database, and databases can’t afford to lose information stored on an ephemeral volume.
  • Our Pod might be able to use Secrets to retain its certificate or password credentials to access services like databases, but this Pod is generally not considered a volume when it comes to applications running on Kubernetes.
  • Our Pod has the ability to write data on the top layer of its container filesystem. This is generally slow and not recommended for high-volume write traffic. And, in any case, this simply won’t work: this data disappears as soon as the Pod is restarted!

7.1 A quick detour: The virtual filesystem (VFS) in Linux

7.2 Three types of storage requirements for Kubernetes

7.3 Let’s create a PVC in our kind cluster

7.4 The container storage interface (CSI)

7.4.1 The in-tree provider problem

7.4.2 CSI as a specification that works inside of Kubernetes

7.4.3 CSI: How a storage driver works

7.4.4 Bind mounting

7.5 A quick look at a few running CSI drivers

7.5.1 The controller

7.5.2 The node interface

7.5.3 CSI on non-Linux OSs

Summary