Skip to content

longhorn Service Page

Metadata

Field Value
Service longhorn
Criticality Tier 0 (cluster default storage)
Owner Platform owner
Namespace longhorn-system
Clusters ozilab
Version v1.12.1 (pinned in longhorn/base/kustomization.yaml)
Last validated 2026-09-04
Related runbook ../runbooks/longhorn.md

1. Service Overview

Longhorn provides replicated block storage for ozilab: PVCs that follow pods across worker nodes instead of pinning them to one host's disk. The longhorn StorageClass has been the cluster default since 2026-09-04 (replacing local-path for new claims). The control node ozisrpartrke01 is deliberately not a storage node — its node.io/role=edge:NoSchedule taint keeps every Longhorn component off it (upstream ships no tolerations).

2. Architecture Diagram

                 PVC (RWO/RWX)
                      |
             StorageClass: longhorn (default)
                      |
        longhorn CSI driver (3 storage workers only)
                      |
   volume engine --replica x3--> /mnt/kube-data on each of:
        ozisrrepo01      (100G data/kube LV + legacy 500G /data local-path PVs)
        ozisrparlabtools01 (100G data/kube LV)
        ozisrparlabtools02 (100G data/kube LV)
   RWX claims are exported by share-manager pods over NFS
   (nfs-common installed on all storage nodes).

3. Deployment Specifications

Same entry point for Fleet and manual Kustomize (the prometheus principle — no Fleet-side copy):

  • Overlay: longhorn/overlays/ozilab (settings CM patch + UI IngressRoute)
  • Manual: kubectl --context ozilab apply -k longhorn/overlays/ozilab
  • Fleet: longhorn path of the ozilab GitRepo (fleet/layer7/gitrepo-ozilab.yaml), longhorn/fleet.yaml targets cluster ozilab → overlays/ozilab
  • The overlays/homelab and overlays/dev overlays are prepared but have never been deployed anywhere.

4. Configuration Guide

  • longhorn-default-cm patch: default-data-path: /mnt/kube-data, default-replica-count: 3, auto-cleanup of system snapshots. The effective replica count for new volumes comes from the SC template's numberOfReplicas: "3" parameter.
  • Data disks: dedicated 100G ext4 LVM volume (data/kube) mounted at /mnt/kube-data on each storage node; fstab by filesystem UUID with nofail.
  • Claims shared by multiple Deployments (e.g. AWX awx-projects-claim, mounted by both awx-web and awx-task) must be created RWX.

5. Access Protocols

  • UI: https://longhorn.lab.mutana.fr — served through the ozilab traefik (hostPort on ozisrpartrke01), TLS via the usual LE resolver, protected by the traefik/basic-auth middleware. A request without credentials must return 401.
  • Storage API: standard CSI/PVC workflow; driver.longhorn.io.

6. Operations and Observability

Health checks, node drain and troubleshooting workflows live in the runbook. Quick status:

kubectl --context ozilab -n longhorn-system get nodes.longhorn.io
kubectl --context ozilab -n longhorn-system get volumes.longhorn.io

7. Backup and Recovery Notes

No backup target is configured on ozilab yet (the homelab overlay's minio backup secret is not deployed here). Durability currently relies on the 3 -replica layout across the 3 storage nodes. Adding recurring snapshots to S3/minio is the highest-value follow-up.

8. Release and Change Notes

  • 2026-09-04: first deployment on ozilab (v1.12.1) — default StorageClass, control node excluded, AWX projects claim recreated RWX on Longhorn, local-path de-defaulted. See changelogs/ fragments for details.