Overview

In Kubernetes and in docker in general, there are several type of storage, but let's focus on the basics here:

Dynamic

Static

To better illustrate this, check the following pictures:

Now, let's discuss a little bit about the components here. We will start from left to right.

Storage

First you have the actual storage, that storage can be cloud (AWS, Google, IBM Cloud etc) or Local (iSCSI, NAS, SAN, bare metal, etc). Kubernetes has a lot of plugins to provide access to that storage. On the other side, that storage can be replicated, hashed, mapped, encrypted, in RAID and so on and so on. From Kubernetes point of view, it is seen simply as a storage thanks to the plugin

Plugin

Plugins provide the entry point for Kubernetes, as described above, there are different plugins, like EBS Plugin for Cloud Volume or local for local storage. You can check more about Kubernetes Plugins here.

Persistent Volume (PV)

Persistent Volume represent the volumes in Kubernetes term, in other words, the physical representation of the volume gets translated to persistent volume in kubernetes terms. To use that volume, of course we have to use the next component, which is:

Persistent Volume Claim (PVC)

Both, PV and PVC are first class objects in Kubernetes, which means, that just like we can GET and DESCRIBE Pods, we can do the same for PV/PVC. It is important to note, that once a PVC has connected to PV, other PVC cannot connect to the same PV.

Volume

Lastly, we have the Volumes, which are the PV in the POD. Once the Volume is linked with the PVC which is linked with the PV. That PV can be used only by the containers which are in that pod. Other pods or other containers outside of the pod, cannot use that storage.

So, in a nutshell:

We define the storage

We define the PV

We define the PVC

Lastly, we define the Volume in the pod configuration.

There is a BIG issue with that kinda provisioning, IT DOESN'T SCALE. because of that, we have two type of privisioning:

Static

Dynamic

So let's get going and see how it is done with each type:

Static Provisioning

Let's configure Static storage.

Create PV

Firstly, as we said, we have to configure, the PV, let's take one example of a PV:

PV Specs

You can see the description for each important attritube above. So that covers the explanation :) So, how we create it then ? Well, like any other kubernetes' object, we APPLY it:

Create PV

To use it, we need a PVC, to claim it and pod so we have a container to present it to.

Create PVC

As we already said, PVC “claims” the PV. Without PVC, the PV is useless, without PVC the PV is useless. They need to exist together.

So let's check the specs for the PVC.

PVC specs

I will not go through this description as the attributes repeat, but you get the picture. We create a claim, and we hope that some volume can fulfil it :) As again, the PVC is a first class object, we can simply “apply” it:

Create PVC

We see that, we have bounded them and we see the claim in the Persistent Volume description. It is important to note that the PVC will bind to ANY PV which has the SAME or MORE of the requested storage. For example if the PVC wants to claim 50 GBs and we have PV with 20 GBs, it will bind.

However, if our PVC wants to claim 20GBs and we have only 50 GB PV, then we are screwed and the PVC won't bind. Congrats, we have a pvc to present to any pod we want to have storage.

So let's create the Pod

Create a POD with Persistent Storage

As always, here example of the POD YML:

Pod Specs

Again, I think explaination is useless here as the things are self explaining and as always we can just create:

Create Pod

Get on the Pod

As we installed that pod on Kubernetes with 1 master and 2 workers. It didn't had to end up on the mater, in fact it ended up on Worker 1 :) So let's check it there. On Worker1, we can list all the Pods as usual and connect to our one

List all pods

So we have created a simple text file on the pod, under mount: “/data”. According our logic that file should be available on the host server under the defined volume destination:

Check the Volume

Lo and behold, the simple text file is on persistent storage and won't be affected if the container crashes for example. It will stay there safe and sound on the host server.

As we mentioned, that kind of persistent storage allocation DOESN'T SCALE and let's see why:

You see that, mapping and mapping and mapping :) Let's see what we can do about it.

Dynamic Provisioning

Let's configure Dynamic storage. Now, for Dynamic provisioning with NFS I had to re-configure the cluster. In a nutshell make sure that teh API IP which you give when you initiate the cluster has the same subnet of the pod network.

For example:

Initiate Cluster for NFS

Calico by default is using: 192.168.0.0/16 so I modified it to: 192.168.50.0/24 so it will match the network of the API Advertise IP.

So let's get going. In the begining, I had something like that:

Overview

So we have to create the following:

Deployment

Service Account

Service

RBAC

Storage Class

Claim

Create the Deployment,Service and Service Account

You can see the deployment,service and service account's YML below:

Components YML

Then let's create the RBAC, which created the Cluster roles and maps them and of course the storage class

Create RBAC and Storage Class

Create RBAC & Storage Class

Create Storage Claim

With Dynamic provisioning, we DON'T Create the Volume, we create ONLY the claim, the volume is created automatically by the provision, that is the MAIN difference

Create Claim

Verify

We can verify the configuration as follows:

Create Claim

Finally, we have a bounded PVC using Dynamic Provision. There is one very good git with all this files:

Configure it with GIT

Create a Pod with Dynamic Provisioning

We can of course create a pod which will be using the NFS, let's create NGINX pod for example:

Create NGINX Pod

Eurika, finally we are done with both types of privisioning