Kubernetes and Cloud Native Associate (KCNA)Kubernetes FundamentalsMedium
A developer has created a Pod that needs to access a shared file system, specifically an NFS share, from outside the Kubernetes cluster. They want this share to be mounted directly into their Pod. Which of the following volume types is appropriate for directly mounting an existing NFS share into a Pod without requiring a PersistentVolume or PersistentVolumeClaim?
- AconfigMap
- BhostPath
- Cnfs
- DemptyDir
Show answer & explanationAnswer & explanation
Correct answer: C. nfs
The `nfs` volume type in Kubernetes allows a Pod to directly mount an existing Network File System (NFS) share. This is suitable for scenarios where a PersistentVolume and PersistentVolumeClaim abstraction is not required or desired for a pre-existing share.
Why the other options are wrong
- A. A `configMap` volume mounts a ConfigMap into a Pod as files, used for non-sensitive configuration data.
- B. A `hostPath` volume mounts a file or directory from the host node's filesystem into a Pod, not an external NFS share.
- D. An `emptyDir` volume is ephemeral, created when a Pod is assigned to a node and deleted when the Pod is removed.
Kubernetes `nfs` Volume
The `nfs` volume type in Kubernetes allows a Pod to mount an existing Network File System (NFS) share directly. This is useful for accessing shared storage without needing the full PersistentVolume/PersistentVolumeClaim abstraction.
- Requires an existing NFS server and share.
- Data persists beyond the Pod's lifecycle.
- Can be used without PV/PVC, though often used with them for dynamic provisioning.
Memory trick: NFS Nurtures Network Shares