If you are familiar with Docker, you are likely aware of the concept of bind mounts. This is the practice of mapping a folder within the container to a static location on the host. We can actually do that in Rancher as well: mapping a folder on the host can be done with the
Now we can do that, but we won’t. Bind mounts have several problems that quickly become apparent in kubernetes:
hostPathdoes not scale well with high availability, and is in fact not highly available. You lose the node the bind mount is on, that data is gone.
These are problems that distributed Filesystems solve.
In this article, we will:
There are many options for a distributed filing system. Rancher (the company) also develops a distributed filing system, called longhorn. Longhorn integrates with Rancher and also works on top of existing ext4/xfs filing systems: both of which are good for us. Let’s install it!
You can see me do this below:
After a while, you should get a SUCCESS message. Once that is observed, longhorn is now available for creating volumes. You should also have a new management section on the sidebar:
you may notice that a chunk of your CPU is now reserved. This is because Longhorn really, really doesn’t want to fail, and reserves 12% (by default) of your CPU to keep the distributed filesystem operational even at full load.
Now that we have persistent storage to provision, let’s modify our deployment to actually involve that persistent storage.
Back in the rancher cluster explorer, navigate to Deployments. Use the 3 dots at the right to Edit Config
Under storage, choose Create Persistent Volume Claim
If all goes well, your application should redeploy (killing our website in the process). However the new deployment now has a persistent container attached. From now on the /usr/share/caddy folder will persist it’s data in a longhorn volume. You can test that by generating a new
index.html file using the container shell.
echo "<h1>hello world, this website is persistent!</h1>" > /usr/share/caddy/index.html
Now if you edit or redeploy your container, the webpage will always read “Hello World, this website is persistent!'“.
Coming from Docker, this terminology has probably thrown you for a loop. Let’s break down what they are
For persistent volumes, you’ll have to change your filter to “Only User Namespaces”. That’s because persistent volumes do not get assigned a namespace
The whole process is essentially the same as docker, but these added extra steps allow containers to request volumes on the fly. That is useful if you are trying to automatically scale and need to automate volume creation or deletion.
Fantastic! We now have a permanent storage location for our container data and can transfer data both into and out from it. However, we still have a big problem: We still don’t have a backup! Our volumes need to be backed up to be useful, so let’s address that in backing up Rancher.