-
Notifications
You must be signed in to change notification settings - Fork 0
oneke_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 theService OneKE 1.27
template before instantiating).
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
.
- OpenNebula Apps Overview
- OS Appliances Update Policy
- OneApps Quick Intro
- Build Instructions
- Linux Contextualization Packages
- Windows Contextualization Packages
- OneKE (OpenNebula Kubernetes Edition)
- Virtual Router
- Release Notes
- Overview
- Quick Start
- OpenRC Services
- Virtual Router Modules
- Glossary
- WordPress
- Harbor Container Registry
- MinIO
- Development