Node mount and hostPath
The simpler of the two ways to give Kubernetes pods storage on MooseFS is a mount made on each node. Pods get this mount as a hostPath volume. This way is for simpler tasks. Use a node mount when dynamic provisioning is not needed. The MooseFS CSI driver is the recommended arrangement. Before the first step, the MooseFS side must admit the nodes. Kubernetes describes how.
A node mount handed to pods as hostPath
A node that makes the mount itself needs the MooseFS client package. The steps are in install clients.
Mount the tree on every node that may run the pods. Use mfsmount and the steps in first mount and verification:
mkdir -p /mnt/mfs
mfsmount -H mfsmaster.example.com /mnt/mfs
Make the mount permanent. The client package includes mount.moosefs, so an /etc/fstab entry restores the mount after a reboot. A hostPath volume gives the pod whatever is at that path on the node. The mount must therefore be in place before a pod that uses the mount is scheduled on that node.
Point a PersistentVolume at the mounted path:
apiVersion: v1
kind: PersistentVolume
metadata:
name: mfs-pv
spec:
capacity:
storage: 500Gi
accessModes:
- ReadWriteMany
hostPath:
path: /mnt/mfs
Claim it:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mfs-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
resources:
requests:
storage: 100Gi
The empty storageClassName sends the claim to the volume declared above. A cluster that has a default StorageClass assigns an unqualified claim to that class instead. That class provisions a volume of its own and leaves the volume declared here unbound. Most distributions ship such a class, so the line is usually needed.
The section mount the claim in a pod shows how a pod mounts the bound claim.
Kubernetes matches claims against the capacity in these objects. MooseFS does not read this capacity. The space that a pod can actually use is the free space of the instance. To limit a subtree, set a MooseFS quota on the directory (space management).
This arrangement has a drawback: the volume exists only on nodes that have the mount. A node selector or an affinity rule must therefore keep the pods that use the volume on those nodes. Every new node must be prepared before it can run those pods.