Kubernetes / OpenShift
Overview of Kubernetes and OpenShift plans for the two-site homelab: node networks on VLAN 40, VIP pools on VLAN 50, planned stack, and machine-network allocations for multiple clusters.
Planned — not yet deployed
Kubernetes and OpenShift deployment is a planned future build phase. Network allocations and stack choices are decided; no cluster is running yet. All details on this page should be treated as tentative until deployment begins.
Kubernetes and OpenShift workloads are planned primarily for Site B, which is sized for distributed compute and Ceph storage. Node traffic uses the Kubernetes Nodes VLAN (VLAN 40, 10.x0.40.0/22); load-balancer VIPs use the K8s LB / VIPs VLAN (VLAN 50). This section covers the network layout, planned software stack, and machine-network allocations for multiple OpenShift clusters per site.
Node Networks
Kubernetes node VMs attach to VLAN 40 at each site, with a /22 subnet giving room for up to 1022 node addresses. Node IPs reuse the host-octet addressing convention used across the infrastructure.
| Site A | Site B | |
|---|---|---|
| VLAN | 40 | 40 |
| Subnet | 10.10.40.0/22 | 10.20.40.0/22 |
For multiple OpenShift clusters, each cluster gets a dedicated /22 machine network carved from the 10.x0.100.0+ address space rather than sharing VLAN 40. See Machine Networks for per-cluster allocations.
Load-Balancer VIPs
API server VIPs, ingress VIPs, and MetalLB address pools live on VLAN 50. OPNsense routes this VLAN at each site; no L2 stretch is needed between sites.
| VIP role | Site A | Site B |
|---|---|---|
| API server | 10.10.50.10 | 10.20.50.10 |
| Ingress | 10.10.50.11 | 10.20.50.11 |
| MetalLB pool | 10.10.50.200–10.10.50.250 | 10.20.50.200–10.20.50.250 |
Planned Stack
The table below lists the planned component choices. None are yet deployed.
| Component | Role |
|---|---|
| Cilium (overlay mode) | Preferred CNI — pod-to-pod overlay, network policy |
| MetalLB | LoadBalancer VIP pools from VLAN 50 |
| cert-manager | Certificate lifecycle management |
| external-dns | Automatic DNS record provisioning |
| ArgoCD | GitOps continuous deployment |
| ingress-nginx or Traefik | Ingress controller |
Cilium runs in overlay mode so pod traffic is encapsulated and does not require native routing of pod CIDRs on the underlying VLANs. MetalLB draws VIPs from the VLAN 50 pool (10.x0.50.200–.250).
Site Roles
Site B (10.20.0.0/16) carries the bulk of Kubernetes and OpenShift workloads. Its five compute nodes (sb-cmp-01 through sb-cmp-05) provide the core count and Ceph storage needed for production-grade clusters. Site A hosts Kubernetes capacity as secondary; its primary roles remain management, ZFS storage, and Proxmox Backup Server.
| Site A | Site B | |
|---|---|---|
| K8s role | Secondary | Primary |
| Compute nodes | sa-cmp-01, sa-cmp-02 | sb-cmp-01–sb-cmp-05 |
| Ceph PV backing | No | Yes |
| Cluster weight | Light | Heavy |
No cross-site clusters
Keep Kubernetes and OpenShift clusters site-local. Never stretch a cluster across the WireGuard VPN. Use application-level replication, GitOps, and Proxmox Backup Server for cross-site disaster recovery.
Pod and Service CIDRs
Pod CIDRs and service CIDRs must not overlap real LAN or WireGuard ranges. The site supernets (10.10.0.0/16, 10.20.0.0/16) and the WireGuard transit (10.255.0.0/24) are reserved for infrastructure.
No CIDR overlap with site supernets
Never assign Kubernetes pod or service CIDRs from 10.10.0.0/16, 10.20.0.0/16, or 10.255.0.0/24. These are real routed infrastructure ranges.
Recommended non-overlapping allocations (tentative, as of 2026-06-28):
| CIDR type | Example value |
|---|---|
| Pod CIDR — cluster 1 | 10.128.0.0/14 |
| Pod CIDR — cluster 2 | 10.132.0.0/14 |
| Service CIDR | 172.30.0.0/16 (within 172.16.0.0/12) |
Do not use 172.32.x.x — that range falls outside RFC 1918.
Related Pages
- Kubernetes Planning — detailed planning notes, CNI guidance, and Cilium overlay rationale
- Machine Networks — per-cluster
/22allocations for multiple OpenShift clusters - VLAN Reference — complete VLAN table with subnets and gateways
- IP Addressing — site supernets, bootstrap networks, and addressing convention
- Site B — Ceph — Ceph storage backing for Kubernetes persistent volumes
PBS Backups & Replication
Proxmox Backup Server instances, IPs, VLAN 90 allocation, and the cross-site replication strategy for disaster recovery.
Kubernetes Planning
Planned Kubernetes and OpenShift deployment on Proxmox VMs across both sites: cluster topology, node placement, machine-network allocations, pod/service CIDR design, and the component stack.