Running Kubernetes MetalLB Persistent Volume on-premises helps teams achieve cloud-like behavior without relying on managed services. However, on-prem Kubernetes does not include native load balancers or shared storage. Because of this limitation, MetalLB and persistent volumes become essential components.
In this guide, you will learn how to design a highly available Kubernetes cluster using kubeadm, expose services with MetalLB, and manage stateful workloads using NFS-based persistent volumes.
Why Kubernetes MetalLB Persistent Volume Is Important
On-prem Kubernetes environments are powerful, yet they require additional building blocks. MetalLB provides external IPs, while persistent volumes keep application data safe.
As a result, this approach delivers:
- Real LoadBalancer IPs without cloud providers
- High availability for control plane components
- Reliable shared storage for stateful apps
- A strong foundation for DevOps automation
Therefore, many enterprises adopt this pattern for private cloud and regulated workloads.
Kubernetes MetalLB Persistent Volume Architecture
This deployment uses kubeadm with multiple masters, an external load balancer, and shared storage.
Cluster Layout
- 3 Master Nodes for high availability
- 3 Worker Nodes for workloads
- 1 HAProxy Node for API traffic
- 1 NFS Server for shared storage
Because of this design, the cluster continues to operate even during node failures.
System Requirements
Sizing the infrastructure correctly improves cluster stability.
- Masters: 2 CPU, 2 GB RAM
- Workers: 1 CPU, 1 GB RAM
- HAProxy: 1 CPU, 1 GB RAM
- NFS Server: 1 CPU, 1 GB RAM
In addition, all nodes must share the same network and have internet access.
HAProxy Setup for Kubernetes MetalLB Persistent Volume High Availability
To begin, HAProxy distributes API traffic across all master nodes.
You configure HAProxy to:
- Listen on port
6443 - Balance traffic using round-robin
- Health-check each master
As a result, kubeadm uses a single control-plane endpoint, simplifying cluster management.
Certificate Management in Kubernetes MetalLB Persistent Volume Deployments
Security is critical in any Kubernetes setup. Therefore, TLS certificates are generated using cfssl.
This includes:
- A dedicated Certificate Authority
- API server and etcd certificates
- Secure certificate distribution
At the same time, this approach aligns well with DevSecOps and zero-trust practices.
Installing Docker and Kubernetes Components
Each node requires Docker, kubeadm, kubelet, and kubectl.
Before proceeding:
- Disable swap
- Add Kubernetes repositories
- Keep versions consistent
Consequently, cluster initialization remains predictable and stable.
External Etcd for High Availability
Instead of embedded etcd, this setup uses an external three-node etcd cluster.
Each master:
- Runs an etcd instance
- Uses TLS for peer communication
- Participates in quorum
Because of this, control plane data remains safe even if one node fails.
For production best practices, refer to the official Kubernetes documentation:
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
Initializing Masters with kubeadm
The first master initializes the cluster using a kubeadm configuration file.
Key settings include:
- HAProxy control-plane endpoint
- External etcd URLs
- Pod network CIDR
After initialization, certificates are copied to other masters, which then join the cluster. As a result, all masters operate as one logical control plane.
Joining Worker Nodes
Worker nodes join the cluster using the kubeadm join command.
Because token-based discovery and certificate validation are used, the process stays secure and repeatable.
Deploying the Pod Network
Initially, nodes show a NotReady state. This happens because networking is not yet configured.
Weave Net is deployed to enable pod communication. However, Calico or Flannel can also be used. Once deployed, all nodes become Ready.
Kubernetes Dashboard and Monitoring
For visibility and operations:
- The Kubernetes Dashboard is installed
- Heapster is deployed for metrics
- RBAC permissions are applied
As a result, administrators gain real-time insights into cluster health.
Kubernetes MetalLB Persistent Volume: Load Balancing
MetalLB enables LoadBalancer services in on-prem clusters.
MetalLB Setup
-
Apply MetalLB manifests
-
Define an IP address pool
-
Verify controller and speaker pods
Afterward, services of type LoadBalancer receive real external IPs from the local network.
Kubernetes MetalLB Persistent Volume: NFS Storage
Stateful workloads require shared storage. Therefore, NFS is used as the persistent volume backend.
NFS Configuration
- Install NFS server packages
- Create and export a shared directory
- Configure client access
PersistentVolumes and PersistentVolumeClaims are then created to bind storage to pods.
Because of this, multiple pods can mount the same data using ReadWriteMany.
Running Applications with Persistent Volumes
An Nginx deployment mounts the NFS-backed volume.
Whenever files change on the NFS server:
- Pods update automatically
- Data persists across restarts
- Scaling remains seamless
Therefore, this approach works well for CMS platforms and shared content workloads.
How ZippyOPS Supports Kubernetes Platforms
Implementing Kubernetes MetalLB Persistent Volume is only the first step. Long-term success requires automation, security, and observability.
ZippyOPS provides consulting, implementation, and managed services across:
- DevOps and DevSecOps
- Cloud and Infrastructure
- Microservices and DataOps
- Automated Ops, AIOps, and MLOps
- Kubernetes security and governance
Organizations leverage ZippyOPS services, solutions, and products to standardize clusters and reduce operational risk:
https://zippyops.com/services/
https://zippyops.com/solutions/
https://zippyops.com/products/
Practical demos and Kubernetes walkthroughs are also available on the ZippyOPS YouTube channel:
https://www.youtube.com/@zippyops8329
Conclusion
In summary, Kubernetes MetalLB Persistent Volume enables production-ready on-prem Kubernetes environments. MetalLB delivers external access, while persistent volumes ensure reliable storage.
When combined with high availability and automation, this architecture becomes enterprise ready. For expert guidance, reach out to ZippyOPS at sales@zippyops.com.
