Persistent Storage: Longhorn

Longhorn is deployed during the cluster creation from an official Helm chart with the following manifest:

---
apiVersion: v1
kind: Namespace
metadata:
  name: longhorn-system
---
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: one-longhorn
  namespace: kube-system
spec:
  targetNamespace: longhorn-system
  chartContent: <BASE64 OF A LONGHORN HELM CHART TGZ FILE>
  valuesContent: |
    defaultSettings:
      createDefaultDiskLabeledNodes: true
      taintToleration: "node.longhorn.io/create-default-disk=true:NoSchedule"
    longhornManager:
      tolerations:
        - key: node.longhorn.io/create-default-disk
          value: "true"
          operator: Equal
          effect: NoSchedule
    longhornDriver:
      tolerations:
        - key: node.longhorn.io/create-default-disk
          value: "true"
          operator: Equal
          effect: NoSchedule
      nodeSelector:
        node.longhorn.io/create-default-disk: "true"
    longhornUI:
      tolerations:
        - key: node.longhorn.io/create-default-disk
          value: "true"
          operator: Equal
          effect: NoSchedule
      nodeSelector:
        node.longhorn.io/create-default-disk: "true"
---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-retain
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
volumeBindingMode: Immediate
parameters:
  fsType: "ext4"
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fromBackup: ""

• A dedicated namespace longhorn-system is provided.
• Tolerations and nodeSelectors are applied to specific components of the Longhorn cluster to prevent storage nodes from handling regular workloads.
• An additional storage class is provided.

[!IMPORTANT] To deploy Longhorn:

• Set ONEAPP_K8S_LONGHORN_ENABLED to "YES".
• To avoid split-brain situations, Longhorn expects at least three storage nodes. Scale up the storage role cardinality to at least three VMs (or modify the Service OneKE 1.27 template before instantiating).

Accessing the Longhorn Web UI

You can manage Longhorn through its Web UI. Longhorn should have created a ClusterIP Kubernetes service; you can check its IP address and port with:

kubectl -n longhorn-system get svc | grep longhorn-frontend

You should be able to reach the Web UI from any of the cluster nodes, or using a SOCKs proxy (i.e. the SSH SOCKS proxy functionality) to open the Web UI in a web browser.

Alternatively, if Traefik is enabled in the cluster, you can expose the Longhorn service through the external VNF IP by creating an IngressRoute object. To do so, create the following Kubernetes manifest in the Master node (or in any device with access to the Kubernetes control plane):

manifest.yml:

---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: redirect-longhorn-frontend
  namespace: longhorn-system
spec:
  redirectRegex:
    regex: ^(.*)/longhorn$
    replacement: $1/longhorn/
    permanent: false
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: rewrite-longhorn-frontend
  namespace: longhorn-system
spec:
  replacePathRegex:
    regex: ^/longhorn/(.*)$
    replacement: /$1
---
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: longhorn-frontend
  namespace: longhorn-system
spec:
  entryPoints: [web]
  routes:
    - kind: Rule
      match: PathPrefix(`/longhorn`)
      middlewares:
        - name: redirect-longhorn-frontend
        - name: rewrite-longhorn-frontend
      services:
        - kind: Service
          name: longhorn-frontend
          port: 80
          scheme: http

Apply the manifest with:

kubectl apply -f manifest.yml

The Longhorn Web UI will be accessible using a web browser through http://<VNF-EXTERNAL-IP>/longhorn.