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