...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
replicaCount: 1
strategyType: Recreate
image:
repository: 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: ReadOnlyMany
# 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
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: {} |
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 | ||||||
|---|---|---|---|---|---|---|
| ||||||
$ 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-modeparameter, but by the settings used in the NFS configuration.