Going back to the end of the previous sub-chapter, we introduce the Rook storage provider. It is inserted between the hard disk of the VMs, always based on NFS, and the Kubernetes cluster. As said previously, NFS allows remote hosts to mount filesystems over a network and interact with those filesystems as though they are mounted locally. This enables system administrators to consolidate resources into centralized servers on the network and integration with Rook to have greater control over Kubernetes storage-related parameters.
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
# Clone the repository and enter the directory that we will use throughout the guide $ git clone --single-branch --branch v1.57.3 https://github.com/rook/rooknfs.git $ cd rooknfs/cluster/examples/kubernetes/nfs # Then launch (operator is created in the "rook-nfs-system" namespace) $ kubectl create -f commoncrds.yaml -f operator.yaml # Check if the operator is up and running $ kubectl get pod -n rook-nfs-system NAME READY STATUS RESTARTS AGE rook-nfs-operator-f79889845-8r5kq 1/1 Running 0 11m |
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
apiVersion: v1
kind: PersistentVolume
metadata:
name: local-pv
labels:
type: local
spec:
storageClassName: local-storage # Same as the name of the default SC created
capacity:
storage: 10Gi
accessModes:
- ReadWriteMany
hostPath:
path: /mnt/data # The "data" folder, if it If does not exist, "data" folder will be created automatically on the node where the NFS Server pod is up and running
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- <node_name> # Enter the node name (obtainable with "kubectl get node") |
...
Verify, afterwards, that the NFS Server pod is up and running. If the NFS Server pod is in the Running state, then we have successfully created an exported NFS share, that clients can start to access over the network. Inside the nfs.yaml file there are, in addition to the NFS Server part, some lines relating to the implementation of a PVC, which hooks to the default PV created previously. Verify that the PVC has been created in the rook-nfs namespace and that it is bound to the above PV.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
# With this command you get SC, PV and PVC (of all namespaces) $ kubectl get sc,pv,pvc -A NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE sc/local-storage (default) kubernetes.io/no-provisioner Delete WaitForFirstConsumer false 60m sc/rook-nfs-share1 nfs.rook.io/rook-nfs-provisioner Delete Immediate false 50m NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS AGE pv/local-pv 10Gi RWX Delete Bound rook-nfs/nfs-default-claim local-storage 58m pv/pvc-66761edb-0b68-4a6e-92c2-016c9ecf1255 10Mi RWX Delete Bound myns/rook-nfs-pv-claim rook-nfs-share share1 40m pv/pvc-9cc3bb63-eb0b-4ded-bbb9-3d854e7c6b4b 15Mi RWX Retain Bound myns/rook-nfs-pv-claim2 rook-nfs-share1 30m NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE rook-nfs pvc/nfs-default-claim Bound local-pv 10Gi RWX local-storage 56m myns pvc/rook-nfs-pv-claim Bound pvc-66761edb-0b68-4a6e-92c2-016c9ecf1255 10Mi RWX rook-nfs-share1 40m myns pvc/rook-nfs-pv-claim2 Bound pvc-9cc3bb63-eb0b-4ded-bbb9-3d854e7c6b4b 15Mi RWX rook-nfs-share1 30m |
...