DEV Community

Cover image for Kubernetes homelab - Learning by doing, Part 4: Storage
Sacha Thommet
Sacha Thommet

Posted on

Kubernetes homelab - Learning by doing, Part 4: Storage

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
Enter fullscreen mode Exit fullscreen mode

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:

Image description

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
Enter fullscreen mode Exit fullscreen mode
šŸ‘‹ While you are here

Reinvent your career. Join DEV.

It takes one minute and is worth it for your career.

Get started

Top comments (0)

Billboard image

The Next Generation Developer Platform

Coherence is the first Platform-as-a-Service you can control. Unlike "black-box" platforms that are opinionated about the infra you can deploy, Coherence is powered by CNC, the open-source IaC framework, which offers limitless customization.

Learn more

šŸ‘‹ Kindness is contagious

Dive into an ocean of knowledge with this thought-provoking post, revered deeply within the supportive DEV Community. Developers of all levels are welcome to join and enhance our collective intelligence.

Saying a simple "thank you" can brighten someone's day. Share your gratitude in the comments below!

On DEV, sharing ideas eases our path and fortifies our community connections. Found this helpful? Sending a quick thanks to the author can be profoundly valued.

Okay