...
| Code Block |
|---|
| language | bash |
|---|
| title | Install and export NFS |
|---|
| collapse | true |
|---|
|
# Install the below package for NFS server on CentOSRedHat distro
$ sudo yumdnf install -y nfs-utils
# Make sure the service is active on all VMs
$ systemctl status nfs-server
# Edit /etc/exports by inserting the exported directory, the IPs of the clients and how to access the exported directory
/<path>/<exported_dir> <IP_client1>(ro,sync,no_root_squash,no_all_squash)
/<path>/<exported_dir> <IP_client2>(ro,sync,no_root_squash,no_all_squash)
# Update the service
$ sudo exportfs -rav |
...
| Code Block |
|---|
| language | bash |
|---|
| title | Install using Helm |
|---|
|
$ helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner
$ helm repo update
$ helm show values nfs-subdir-external-provisioner/nfs-subdir-external-provisioner > values.yaml
$ helm install nfs<chart_name> nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --values values.yaml --namespace <namespace> --create-namespace
$ helm uninstall <chart_name> -n <namespace>
# It's possible to proceed with the installation in a classic way, through manifest, by downloading the git repository
$ git clone https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner.git |
...
| Code Block |
|---|
| language | yml |
|---|
| title | values.yaml |
|---|
| collapse | true |
|---|
|
replicaCount: 1
strategyType: Recreate
image:
repository: registry.k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner
tag: v4.0.2
pullPolicy: IfNotPresent
imagePullSecrets: []
nfs:
server: <server_IP>
path: <exported_path>
mountOptions:
volumeName: nfs-external-provisioner
# Reclaim policy for the main nfs volume
reclaimPolicy: Delete
# For creating the StorageClass automatically:
storageClass:
create: true
# Set a provisioner name. If unset, a name will be generated.
# provisionerName:
# Set StorageClass as the default StorageClass. Ignored if storageClass.create is false
defaultClass: false
# Set a StorageClass name. Ignored if storageClass.create is false
name: nfs-sc
# Allow volume to be expanded dynamically
allowVolumeExpansion: true
# Method used to reclaim an obsoleted volume
reclaimPolicy: Delete
# When set to false your PVs will not be archived by the provisioner upon deletion of the PVC.
archiveOnDelete: false
# If it exists and has 'delete' value, delete the directory. If it exists and has 'retain' value, save the directory.
# Overrides archiveOnDelete. Ignored if value not set.
onDelete:
# Specifies a template for creating a directory path via PVC metadata's such as labels, annotations, name or namespace. Ignored if value not set.
pathPattern: ${.PVC.namespace}-${.PVC.name}
# Set access mode - ReadWriteOnce, ReadOnlyMany or ReadWriteMany
accessModes: ReadWriteMany
# Set volume bindinng mode - Immediate or WaitForFirstConsumer
volumeBindingMode: ReadOnlyManyImmediate
# Storage class annotations
annotations: {}
leaderElection:
# When set to false leader election will be disabled
enabled: true
## For RBAC support:
rbac:
# Specifies whether RBAC resources should be created
create: true
# If true, create & use Pod Security Policy resources
# https://kubernetes.io/docs/concepts/policy/pod-security-policy/
podSecurityPolicy:
enabled: false
# Deployment pod annotations
podAnnotations: {}
## Set pod priorityClassName
# priorityClassName: ""
podSecurityContext: {}
securityContext: {}
serviceAccount:
# Specifies whether a ServiceAccount should be created
create: true
# Annotations to add to the service account
annotations: {}
# The name of the ServiceAccount to use. If not set and create is true, a name is generated using the fullname template
name:
resources: {}
# limits:
# cpu: 100m
# memory: 128Mi
# requests:
# cpu: 100m
# memory: 128Mi
nodeSelector: {}
tolerations: []
affinity: {}
# Additional labels for any resource created
labels: {}
podDisruptionBudget:
enabled: false
maxUnavailable: 1 |
How to use PVC into NFS SEP
The Let's quickly see what happens when a PVC is created, both in read-only and read-write permissions are not governed by the access- mode parameter, but by the settings used in the NFS configuration. Let's try to give examples in both cases.
Read-Only mode
The steps to follow in this case are:
...
| Code Block |
|---|
| language | bash |
|---|
| title | Create and verify the app |
|---|
| collapse | true |
|---|
|
$ k apply -f trial_app.yaml -n nfs-test
# Enter one of the created replicas
$ k exec -it -n nfs-test mystate-0 -- bash
# Check the contents and permissions of the folder on which the volume is mounted
root@mystate-0:/# cat /usr/share/nginx/html/file_test.txt
test
root@mystate-0:/# echo "test2" > /usr/share/nginx/html/file_test.txt
bash: /usr/share/nginx/html/file_test.txt: Read-only file system |
Limitations and pitfalls
The software is subject to some limitations, listed below:
- The storage space provided is not guaranteed: you can allocate more than the total shared size via NFS, because there is no check for it.
- The provisioned storage limit is not enforced. The application can expand to use all the available storage regardless of the provisioned size.
- Storage resize/expansion operations are not presently supported in any form. You will end up in an error state:
Ignoring the PVC: didn't find a plugin capable of expanding the volume; waiting for an external controller to process this PVC. - The read-write permissions are not governed by the
access-mode parameter, but by the settings used in the NFS configuration.