...
| 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 show values nfs-subdir-external-provisioner/nfs-subdir-external-provisioner > values.yaml
$ helm install nfs nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --values values.yaml --namespace <namespace> --create-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: 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 NFS SEP
The 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
Read-Write mode