I'm building a three-node Kubernetes homelab where every node is both a control-plane and worker node. I'm considering using a single NIC per node with two VLANs trunked to the switch: one for LAN services and one for DMZ services.
The idea is to use Cilium or MetalLB with separate load-balancer address pools, then expose each workload through the appropriate gateway depending on whether it belongs on the LAN or in the DMZ. My main goal is stronger network isolation and overall security, but I'm wondering whether this is unnecessary complexity compared with using Kubernetes network policies alone.
I'd also like to bootstrap the nodes with iPXE and am unsure how that works when the switch port carries multiple tagged VLANs. Is this architecture worthwhile, and what would be a sensible way to handle the VLANs, load balancer IPs, and boot process?
3 Answers
For a small homelab, keeping the nodes in one VLAN and using Cilium network policies may be simpler and perfectly adequate. VLANs and separate load-balancer pools add value when the services need to be isolated at the network boundary—for example, when DMZ workloads should not share the same layer-2 segment as trusted LAN services. They don’t replace network policies, since both layers address different parts of the security model.
If your router or firewall supports BGP, another option is to have Cilium advertise service IP ranges from the nodes. You could then publish those addresses in DNS instead of relying on a separate ingress load balancer for every use case. This can simplify the data path, although you’ll still need to design the VLAN placement and firewall rules carefully.
This isn’t necessarily overengineering. Network policies are useful for controlling pod-to-pod traffic inside the cluster, but they don’t determine which physical network a load-balancer IP belongs to. If LAN and DMZ services need to be genuinely separated, using separate VLANs and separate load-balancer IP pools is a reasonable design.
With Cilium, you could create distinct LB-IPAM pools and select them with service labels. For iPXE, one practical approach is to leave the boot or management VLAN untagged on the switch port and carry the other VLAN as tagged traffic. The node can then configure the tagged VLAN after the operating system has booted. Make sure the VLAN configuration is recreated automatically during every boot.
That makes sense. I’m considering using Cilium Hubble for visibility and relying on my OPNsense firewall for inter-VLAN routing and access rules.