This content originally appeared on DEV Community and was authored by Sacha Thommet
Welcome to the fourth part of my Kubernetes homelab guide. I will explain how I manage to set up the storage using Longhorn.
Distributed storage
Pods and their containers are ephemeral. Various factors can lead to a pod restarting, such as being OOM-killed, application crashes, or scaling down...
The problem is, when a pod restarts, its filesystem is wiped, meaning it does not retain data persistently.
So, how can we persist data inside pods, and how can we share data across multiple pods on different nodes ?
With volume mounting and distributed storage!
Distributed storage systems enable us to store data that can be made available clusterwide. Excellent! But dynamically apportioning storage across a multi-node cluster is a very complex job. So this is another area where Kubernetes typically outsources the job to plugins (e.g. Cloud providers like Azure or AWS, or systems like Rook or Longhorn).
External storage systems like these connect to Kubernetes by way of the Container Storage Interface (CSI). This provides a standard interface between different types of storage systems
Why Longhorn ?
I’m already over-engineering by using a Kubernetes cluster to host a few private services , so the main reason I chose Longhorn was its ease of setup and management.
In addition its backup functionality is extremely useful and easy to use!
Simply set up a backup target — an endpoint for Longhorn to access a backup store. This backup store can be an NFS, SMB/CIFS server, Azure Blob Storage, or any S3-compatible server holding Longhorn volume backups. Then, to restore your entire Kubernetes storage, just point Longhorn to the backup target.
Installation
The soft is very easy to install, as always with containers:
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/<version>/deploy/longhorn.yaml
The "hard" part is with requirements. Each node in the cluster where Longhorn is installed must fulfill multiple requirements. Luckily, the official documentation is clear and straightforward.
Usage
Longhorn comes with its StorageClass, which provides dynamic provisioning of persistent volumes:
For instance:
apiVersion: v1
kind: Pod
metadata:
name: vaultwarden
...
spec:
containers:
- image: vaultwarden/server:latest
name: vaultwarden
...
volumeMounts:
- mountPath: /data
name: vaultwarden-data
volumes:
- name: vaultwarden-data
persistentVolumeClaim:
claimName: vaultwarden-data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: vaultwarden-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: longhorn
This content originally appeared on DEV Community and was authored by Sacha Thommet
Sacha Thommet | Sciencx (2024-10-31T15:18:52+00:00) Kubernetes homelab – Learning by doing, Part 4: Storage. Retrieved from https://www.scien.cx/2024/10/31/kubernetes-homelab-learning-by-doing-part-4-storage/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.