Having studied Docker last year, initially through a course on Alura, was the starting point for my interest in DevOps culture to flourish. Eventually, in 2021, I was awarded the #ChamaAsMinas program, promoted by the LinuxTips school, and received the Containers Expert training completely free of charge. Besides solidifying my knowledge of Docker, I began learning about Kubernetes and, wow... it’s a lot. In one of the classes, we were introduced to several different concepts, and I’m writing this series of posts because I felt the need to dive deeper into them. So, I'm inviting you all to join me in my next mission: understanding Kubernetes components – Volumes!
What components will this series of posts cover?
If you, like me, are taking the Descomplicating Kubernetes training: today is (almost) your lucky day. I've summarized some of the components explained on Day 4 of the course. For each component, my goal is to describe:
- Its definition
- Examples of usage
- Possible related commands
- A snippet of the corresponding creation YAML and/or related YAML
As I start writing this post, I’ve just finished studying this part of the course and, honestly, I’m a bit nervous about the final quiz. 😅 Personally, I find Kubernetes much harder to understand than Docker, but onward we go!
However, if you're not taking this course, here are the components I plan to cover:
- Volumes (in this very post!)
- EmptyDir
- Persistent Volume
- Cronjobs & Secrets (in the next one)
Volumes in Kubernetes
Definition
First and foremost, to put it simply, a volume is nothing more than a directory accessed by the containers of a Pod, which contains data. If you're a developer and need a rough analogy, we can say that your Pod and its containers are like an application, and the volume would be its database.
The main utility of a volume is to make your containers less ephemeral. For example, you have your cluster with its pods, and one of the existing containers restarts due to some issue. If there is no volume associated with this container, it will come back “clean,” just as it was initially created. Therefore, volumes are used to store any type of information that can help you avoid losing work if something goes wrong.
Docker already has the concept of volumes, but within Kubernetes, this is expanded: there are many different types of volumes tailored to various uses, and pods can use as many volumes as needed simultaneously. Primarily, Kubernetes volumes can be divided into two categories: ephemeral volumes, whose existence is tied to the pod’s existence; and persistent volumes, which continue to exist regardless of whether the pod is still running or has been deleted. However, no matter the volume type, the data will always be preserved even if the containers within that pod are restarted, as they are tied to the pod, not to the containers associated with it.
EmptyDir
Definition
As explained earlier, EmptyDir is a type of Kubernetes volume and falls under the group of ephemeral volumes, as it doesn’t handle data persistence. So be careful: when you delete your pod, everything saved in this volume will be lost.
This volume is created as soon as we assign a pod to an existing node. It always starts empty, and anything stored here can be accessed by all containers within the pod.
Usage Example
EmptyDir is the ideal volume to use in situations such as:
- When you need a “scratch space” for your algorithm (e.g., sorting algorithms)
- When you need a place to store recovery points for the containers within your pod
Setting Up a Pod with an EmptyDir Volume
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
⚠ Reminder!
To create any type of Kubernetes component from a YAML file, just run the following command:
kubectl create -f filename.yaml
Persistent Volume
First of all, it's important to clarify that there are "two concepts" associated with this single name, Persistent Volume. The first is more general and defines the Persistent Volume component as a type of volume and what it provides. Within the Persistent Volume component, there is also a "subcomponent" called Persistent Volume.
Confusing, right? Let me explain it a bit better:
Definition
Anyway, there is a subsystem within Kubernetes called Persistent Volume, which provides an API for users and administrators that abstracts the details of how volumes are provisioned and consumed. Within this Persistent Volumes subsystem, there are two main components that handle this process: Persistent Volume and Persistent Volume Claim.
Usage Example
Given that applications are increasingly cloud-based, when someone wants to consume data from an API, for example, it’s necessary to integrate with a specific storage system (Amazon, Azure, etc.). Kubernetes, through Persistent Volume, aims to change this by providing an abstraction. This allows for connecting to a variety of cloud systems without needing explicit dependencies for each system.
Thus, with Persistent Volume, consuming data from a cloud system becomes more straightforward and robust, significantly reducing related costs. It also makes it easier to migrate between cloud systems and/or adopt strategies involving multiple cloud systems.
⚠ Note! Given the more detailed definition, let’s agree on this: when I’m referring to the Persistent Volume subsystem, I’ll use the full name. When referring to the component within the subsystem, I’ll use the acronym PV. Got it?
Persistent Volume (the subcomponent)
Definition
This component, within the subsystem we mentioned, is responsible for providing the actual storage for the volumes we want to create. It is part of the cluster just like any other resource; just as a node is a resource, a PV is too. Unlike EmptyDir, a PV is a persistent volume (obviously), meaning its content is not tied to the lifecycle of a pod; after deleting the pod that uses the volume, the content remains. The PV is also the API object responsible for capturing the details of the storage implementation (such as NFS, iSCSI, or a cloud provider).
Configuring a PV with NFS
apiVersion: v1
kind: PersistentVolume
metadata:
name: primeiro-pv
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
nfs:
path: /opt/dados
server: 10.138.0.2
readOnly: false
⚠ Note! To configure the PV with NFS, it’s also necessary to set up NFS itself. You can find the complete step-by-step guide for creating this component in the Descomplicando Kubernetes repository.
Related Commands
Unlike EmptyDir, with PVs we can use some kubectl commands for viewing and managing them. Here are a few useful commands:
kubectl get pv
kubectl describe pv [your-pv-name]
Persistent Volume Claim
Definition
The PVC is the component that actually binds a PV to a pod. As the name suggests, it’s through the PVC that you can “claim” access to a PV. Just as a pod consumes resources from a node, the PVC will consume resources from a PV. Similarly, just as a pod can request specific levels of resources like CPU and memory, the PVC can specify the size and access mode it needs from the volume.
Access Modes
Each volume can and should be mounted using only one access mode, even though it may support multiple modes. The available access modes are:
-
ReadWriteOnce– Only a single node can perform read and write operations. -
ReadOnlyMany– The volume will be read-only for all nodes. -
ReadWriteMany– All nodes can perform read and write operations.
Configuring a PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: primeiro-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 800Mi
Related Commands
Just like with PVs, we can use some kubectl commands to view and manage PVCs.
kubectl get pvc
A diagram to simplify the process
✔ Links consulted
📕 Documentação do Kubernetes – Volumes
📘 Repositório do treinamento Descomplicando Kubernetes
📗 Stupid Simple Kubernetes — Persistent Volumes Explained
📩 A Last Message
Did you like the text? Do you have anything to add? Any constructive criticism? Feedback? Suggestions? Requests? Feel free to contact me via email (oli.pmatt@gmail.com), LinkedIn (/in/oliviamattiazzo) or through the comments section below! I’d be delighted to chat with you! ✨
You can also check the original post (in PT-BR) at my blog: oliviamattiazzo.dev
⏰ Other posts
💎 Super-helpful gem: syntax_suggest
Top comments (0)