Volumes serve as storage units that containers within a Pod can access. Certain volume types rely on ephemeral storage, meaning they do not persist once the Pod is terminated. Examples of such ephemeral storage types include emptyDir, which can be used as temporary storage for applications. Similar to CPU and memory resources, we can manage local ephemeral storage resources. On the other hand, other volume types are supported as durable storage, providing long-term data persistence.
In essence, a volume can be understood as a directory that is available to every container within a Pod. A Pod defines the volumes it includes and the specific location where containers can access and utilize those volumes.
Let’s look at the different types of volumes:
- emptyDir—An emptyDir volume grants containers within a Pod access to an empty directory for reading and writing. It’s important to remember that when the Pod is removed from a node, regardless of the cause, the data stored within the emptyDir volume is permanently deleted. The medium on which the emptyDir volume resides is determined by the underlying infrastructure of the node, which could be a disk, SSD, or network storage, depending on the configuration. Utilizing emptyDir volumes proves beneficial when temporary storage space is needed or when data needs to be shared among multiple containers within a Pod.
- ConfigMap—A ConfigMap resource is used to inject configuration data into Pods. This data, stored within a ConfigMap object, can be accessed through a volume of type ConfigMap and subsequently utilized by files running within a Pod. The files contained within a ConfigMap volume are defined by a corresponding ConfigMap resource.
- Secret—A Secret volume is used to securely expose confidential information—including passwords, OAuth tokens, and SSH keys—to applications. The data stored within a Secret object can be accessed via a volume of type Secret and utilized by files executing within a Pod.
- downwardAPI—A downwardAPI volume, in simple words, is information about the Pod and container in which an application is running. By utilizing the downwardAPI, our application can retrieve valuable information about the Pod without requiring any knowledge of Kubernetes. This is made possible through the utilization of environment variables and files, which are sources of information that any software can reuse.
- PersistentVolumeClaim (PVC)—Cluster operators have the ability to utilize a PVC volume to allocate long-lasting storage for applications. By employing a PVC, a Pod can mount a volume that is supported by this durable storage.
PVs
PV resources are used to manage durable storage in a cluster. In GKE, a PV is typically backed by a persistent disk. As an option, we can choose a managed NFS called Filestore.
Kubernetes manages the life cycle of a PV, and it can be dynamically provisioned; as resources, they exist independently of Pods.
PVC
A PVC is a user’s request for storage, comparable to a Pod. While Pods consume resources on nodes, PVCs consume resources from PVs. Just as Pods can specify their desired resource levels, such as CPU and memory, PVCs can request specific sizes and access modes. Access modes determine whether the storage can be mounted as ReadWriteOnce, ReadOnlyMany, or ReadWriteMany.
Access modes
PV resources support the following access modes:
- ReadWriteOnce—The volume can be mounted as read-write by a single Kubernetes node.
- ReadOnlyMany—The volume can be mounted as read-only by many Kubernetes nodes.
- ReadWriteMany—The volume can be mounted as read-write by many Kubernetes nodes. PV resources that are backed by GCE persistent disks don’t support this access mode.
Reclaim policies
PVs can have various reclaim policies, including Retain, Recycle, and Delete. For all dynamically provisioned PVs, the default reclaim policy is Delete.
Let’s look at some reclaim policies and their actions:
- Retain—Manual reclamation
- Recycle—Data can be resorted after getting scrubbed
- Delete—Associated storage asset is deleted
We can take advantage of the reclaim policy and control how and when PVs are deleted.
Storage classes
Configuration of volume implementations, such as the Compute Engine persistent disk or Container Storage Interface (CSI) driver, is accomplished using StorageClass resources.
By default, GKE generates a StorageClass that utilizes the balanced persistent disk type (ext4). This default StorageClass is applied when a PVC does not explicitly mention a StorageClassName. However, we have the flexibility to substitute the default StorageClass with our own customized version. For instance, these custom classes can be associated with different quality-of-service (QoS) levels or backup policies. In other storage systems, this concept is occasionally referred to as “profiles.”
Next, we will describe two GKE modes we can use—GKE Standard and GKE Autopilot.