AdBlock Detected

It looks like you're using an ad-blocker!

Our team work realy hard to produce quality content on this website and we noticed you have ad-blocking enabled. Advertisements and advertising enable us to continue working and provide high-quality content.

Use of Volumes in Kubernetes

In this new post, we are going to resume our articles on Kubernetes and explore an introduction to the use of volumes in Kubernetes as a way to provide storage to our containers.

We will discuss the three types of Kubernetes resources associated with volumes:

  1. PersistentVolume
  2. PersistentVolumeClaim
  3. Volumes

What is a volume in Kubernetes?

As our Pods are ephemeral, we must provide them with some form of storage to prevent the loss of information deployed in them. To achieve this, we use volumes with the main objective of persisting our data even when our Pods disappear.

These volumes, similar to Unix, mount on paths specified in the Pod and enable us to persist information.

What is a PersistentVolume in Kubernetes?

PersistentVolume abstracts users and administrators from the details of how storage is consumed and provided through its API.

A PersistentVolume is a Kubernetes resource that represents volumes in the cluster. It defines backend details such as access modes, sizes, recycling policies, etc.

We can consider EBS (Amazon Elastic Block Store) from AWS as an example of a PersistentVolume (PV).

Based on access modes, there are three different types:

  1. ReadWriteOnce: Read-write for a single node (RWO)
  2. ReadOnlyMany: Read-only for many nodes (ROX)
  3. ReadWriteMany: Read-write for many nodes (RWX)

Based on recycling policies, we have:

  1. Retain: Retains the content.
  2. Recycle: The content will be reused.
  3. Delete: Deletes the content.

There are two ways to provision a volume:

  1. Static: In this case, you need to create all PersistentVolumeClaims first, and then you will assign them when creating PersistentVolumes.
  2. Dynamic: For dynamic provisioning, a PersistentVolume will be created on-demand when a PersistentVolumeClaim is created.

Usually, we create a PV statically, where we first have to create a storage unit like NFS or EBS from AWS.

If our cluster cannot find a PersistentVolume for our PersistentVolumeClaim, it can create new storage for this claim, which would be the dynamic creation of a PersistentVolume.

What is a PersistentVolumeClaim?

A PersistentVolumeClaim is a request for storage by a user. Similar to how quotas and resources are set in a Pod, a PVC defines sizes and requests access modes (defined above in PersistentVolume).

How to Define a Volume in a Pod

While defining or creating a Pod and assigning attributes to it, we can also indicate and create a volume to store the information.

To create a volume, we first need to define the mount type and then specify the path:

 volumeMounts:
    - mountPath: /home
      name: home
volumes:
  - name: home
    hostPath:
      path: /home/debian

In the above example, we have mounted a volume at the path /home/debian, which means in a directory. However, we can also mount a volume from a Git repository:

    - mountPath: /git
      name: git
      readOnly: true
  volumes:
  - name: git
    gitRepo:
      repository: https://github.com/refactorizando-web/kubernetes.git

In the official Kubernetes documentation, you can find all the different volumes that can be mounted.

Let’s see a complete example of a volume:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    volumeMounts:
    - mountPath: /home
      name: home
    - mountPath: /git
      name: git
      readOnly: true
    - mountPath: /temp
      name: temp
  volumes:
  - name: home
    hostPath:
      path: /home/debian
  - name: git
    gitRepo:
      repository: https://github.com/refactorizando-web/kubernetes.git
  - name: temp
    emptyDir: {}

The above-defined Pod uses an nginx image and has the following structure:

  • Kind: Indicates the type of Kubernetes resource.
  • name: The name of the image in the container definition.
  • image: Specifies the image to use for deploying the Pod.
  • volumeMounts: It mounts the volumes in the Pod, using the mountPath and name attributes.
  • volumes: VolumeMounts refer to where they will be mounted, and in volumes, we indicate the path using the name defined earlier.
  • temp: After remove the Pod, we remove the volumen mounted in temp

How to Define a PersistentVolume

Now, we will define a PersistentVolume using an NFS (Network File System) server.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    path: /var/shared
    server: 192.0.0.96

The above PersistentVolume creation has created a persistent volume for using an NFS server, providing it with 2GB, a recycling policy, and access with ReadWriteMany.

How to Define a PersistentVolumeClaim

Next, we will define a PersistentVolumeClaim, and continuing with our previous example of NFS, we will create a PersistentVolumeClaim as follows:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

By creating the above resource, we attempt to associate it with the previously created PersistentVolume, one that meets its needs.

Using PersistentVolumeClaim in Pods

The purpose of creating a PersistentVolumeClaim is to be able to use it in a Pod or in the creation of a deployment.yaml. Let’s see how to use a PersistentVolumeClaim in constructing a Pod and a Deployment:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    volumeMounts:
      - mountPath: /usr/share/nginx/html
        name: nfs
  volumes:
    - name: nfs
      persistentVolumeClaim:
        claimName: nfs

The above example describes a Pod using the previously created PersistentVolumeClaim with the name nfs. Now, let’s see how to do the same with a deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment
  namespace: infrastructure
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          resources:
            requests:
              memory: "1200Mi"
              cpu: .10
            limits:
              memory: "2500Mi"
              cpu: .50
         volumeMounts:
           - mountPath: /usr/share/nginx/html
             name: nfs
         ports:
          - containerPort: 80
  volumes:
    - name: nfs
      persistentVolumeClaim:
        claimName: nfs

Conclusion

Understanding how to use volumes in our Pods is essential for creating a robust architecture in Kubernetes. Without the use of volumes, we will lost all data. In this article about the usage of volumes in Kubernetes, we have explored its key features and how to create them.

Leave a Reply

Your email address will not be published. Required fields are marked *