docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update code samples

This commit is contained in:
Maria Bermudez 2019-02-28 14:06:37 -08:00 committed by GitHub
parent a9062ea5f1
commit d96bd7a060
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
ee/ucp/kubernetes/storage/use-nfs-volumes.md
View File

@ -73,14 +73,14 @@ Verify everything was mounted correctly by getting a shell prompt
within the container and searching for your mount. within the container and searching for your mount.
```bash ```bash
$ kubectl exec -it pod-using-nfs sh $ kubectl exec -it nfs-in-a-pod sh
/ # / #
/ # mount | grep nfs.example.com / # mount | grep nfs.example.com
nfs.example.com://share1 on /var/nfs type nfs4 (rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.31.42.23,local_lock=none,addr=nfs.example.com) nfs.example.com://share1 on /var/nfs type nfs4 (rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.31.42.23,local_lock=none,addr=nfs.example.com)
/ # / #
``` ```
Because you defined the NFS share as part of the Pod Spec, neither UCP nor Kubernetes Because you defined the NFS share as part of the Pod spec, neither UCP nor Kubernetes
knows anything about this NFS share. This means that when the pod gets knows anything about this NFS share. This means that when the pod gets
deleted, the NFS share is unattached from the Cluster. However, the data remains in the NFS share. deleted, the NFS share is unattached from the Cluster. However, the data remains in the NFS share.
@ -144,15 +144,15 @@ my-nfs-share 5Gi RWO Recycle Available
The access mode for a NFS Persistent Volume can be any of the following modes: The access mode for a NFS Persistent Volume can be any of the following modes:
- ReadWriteOnce – the volume can be mounted as read-write by a single node. - ***ReadWriteOnce*** – the volume can be mounted as read-write by a single node.
- ReadOnlyMany – the volume can be mounted read-only by many nodes. - ***ReadOnlyMany*** – the volume can be mounted read-only by many nodes.
- ReadWriteMany – the volume can be mounted as read-write by many nodes. - ***ReadWriteMany*** – the volume can be mounted as read-write by many nodes.
The access mode in the Persistent Volume definition is used to match a The access mode in the Persistent Volume definition is used to match a
Persistent Volume to a Claim. When a Persistent Volume is defined and created Persistent Volume to a Claim. When a Persistent Volume is defined and created
inside of Kubernetes, a Volume is not mounted. For more information on [access inside of Kubernetes, a Volume is not mounted. See [access
modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) modes in the Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes),
see the Kubernetes documentation. for more details.
#### Reclaim #### Reclaim
@ -160,7 +160,7 @@ The [reclaim
policy](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming) policy](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming)
is used to define what the cluster should do after a Persistent Volume has been is used to define what the cluster should do after a Persistent Volume has been
released from a Claim. A Persistent Volume Reclaim policy could be: Reclaim, released from a Claim. A Persistent Volume Reclaim policy could be: Reclaim,
Recycle and Delete. Please see the [Kubernetes Recycle and Delete. See [Reclaiming in the Kubernetes
documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming) documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming)
for a deeper understanding. for a deeper understanding.