Breaking Free: Insourcing NFS PVCs Into Kubernetes And Saying Goodbye To External Solutions
Explore a unique solution regarding hosting NFS servers in-house without relying on NAS services like Filestore

Insourcing NFS PVCs into Kubernetes and Saying Goodbye to External Solutions
Kubes are incredibly dynamic. Therefore, handling workloads with ReadWriteMany requirements becomes complicated. Shared storage is necessary for applications demanding concurrent read and write access from multiple pods.
Typically, you could utilize an external storage solution. However, by doing so, you invite additional complexity and massive bills.
But Is there a better approach?
Let’s investigate a novel idea of insourcing NFS PVCs. This idea’s crux is creating shared storage within your Kubernetes cluster. Stay tuned for some Kube basics, a mini insourcing guide, and some best practices.
A Walk Down Kube Lane
A Network File System (NFS) is a distributed file system protocol with a client-server model. Clients (users) can interact with files in a shared directory – like they were stored locally.
A Persistent Volume Claim (PVC) is a storage request by a user. Similar to pods on a Kube network, PVCs also consume PVC resources. You can mount a PVC via various access modes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
- ReadWriteOncePod
Why is ReadWriteMany Special?
ReadWriteMany (RWX) is a unique feature that enables multiple pods to read from and write to a shared storage volume concurrently. RWX is your go-to if specific applications or cloud computing workloads require data consistency and real-time data updates. For instance, Content Management Systems (CMS) like WordPress heavily rely on RWX to serve web pages and store media files.
RWX is vital for high availability and failover scenarios. Additionally, ReadWriteMany enables uninterrupted access in the case of an unprecedented pod failure.