Machine & Cluster Networks
Network allocations for Kubernetes and OpenShift clusters: VLAN 40 node networks, per-cluster /22 machine networks for up to three OpenShift clusters per site, and pod/service CIDR rules.
Machine and cluster network allocations define where Kubernetes node VMs connect on the infrastructure (VLAN 40) and the dedicated /22 blocks each OpenShift cluster uses for its machine network. Pod and service CIDRs are assigned separately — outside the real LAN and VPN ranges — to prevent routing conflicts.
Planned — not yet deployed
All allocations on this page are planned. No Kubernetes or OpenShift cluster is running as of 2026-06-28.
Kubernetes Node Network (VLAN 40)
Kubernetes node VMs attach to VLAN 40 (Kubernetes Nodes) at each site. The /22 subnet provides over 1 000 node addresses per site. Node IPs follow the host-octet convention: the last octet of a node's address matches the octet used by its Proxmox host across all other VLANs it terminates.
| Site A | Site B | |
|---|---|---|
| VLAN | 40 | 40 |
| Subnet | 10.10.40.0/22 | 10.20.40.0/22 |
| Gateway (OPNsense) | 10.10.40.1 | 10.20.40.1 |
Example — sb-cmp-01 has host octet 20, so its VLAN 40 node address is 10.20.40.20.
VLAN 40 carries the host-network address of each node VM. It is distinct from the OpenShift machine-network allocations in the section below, which serve the cluster installer's machine-network concept and are carved from a separate address block.
The K8s LB / VIPs VLAN (VLAN 50) carries API server VIPs, ingress VIPs, and MetalLB pools — not VLAN 40. See Kubernetes Planning for the full VIP table.
OpenShift Machine Networks
Each OpenShift cluster receives a dedicated /22 machine network carved from the 10.x0.100.0+ address space. These blocks are separate from the VLAN 40 host-network addresses. The plan supports up to three clusters per site, with an additional /21 expansion block held in reserve.
| Slot | Site A | Site B |
|---|---|---|
| Cluster 1 | 10.10.100.0/22 | 10.20.100.0/22 |
| Cluster 2 | 10.10.104.0/22 | 10.20.104.0/22 |
| Cluster 3 | 10.10.108.0/22 | 10.20.108.0/22 |
| Expansion | 10.10.112.0/21 | 10.20.112.0/21 |
Each /22 holds up to 1 022 addresses — enough for control-plane nodes, workers, and internal cluster services for a single OpenShift cluster. Using a dedicated block per cluster keeps failure domains tight, reduces ARP noise, and allows per-cluster firewall rules on OPNsense.
No cross-site clusters
Machine networks must remain site-local. Never assign a node from Site A and a node from Site B to the same OpenShift cluster. Cross-site continuity uses application-level replication, GitOps sync via ArgoCD, and Proxmox Backup Server — not cluster federation.
Future Expansion
Tentative — not in core architecture docs
The planning vault (vault/07-kubernetes-openshift-planning.md) reserves 10.10.128.0/17 (Site A) and 10.20.128.0/17 (Site B) as future lab and OpenShift expansion space. These ranges carry no current cluster assignments and are not confirmed in root CLAUDE.md. Treat as planning headroom only.
Pod and Service CIDRs
Pod CIDRs and service CIDRs operate inside the cluster (CNI layer). They must not overlap any real LAN subnet, VLAN block, or WireGuard range. The site supernets 10.10.0.0/16 and 10.20.0.0/16 and the WireGuard transit 10.255.0.0/24 are fully reserved for infrastructure.
No CIDR overlap with site supernets or WireGuard
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. Overlap causes silent routing failures that are difficult to diagnose.
The examples below are non-overlapping blocks drawn from outside both site supernets.
| CIDR type | Example range | Notes |
|---|---|---|
| Pod CIDR — cluster 1 | 10.128.0.0/14 | Outside both site supernets; assign one block per cluster |
| Pod CIDR — cluster 2 | 10.132.0.0/14 | Offset each cluster by /14 to prevent inter-cluster overlap |
| Service CIDR | 172.30.0.0/16 | Stay within 172.16.0.0/12; do not use 172.32.x.x |
`172.32.x.x` is not RFC 1918
172.32.0.0 and above fall outside the RFC 1918 private range 172.16.0.0/12. Service CIDRs assigned from 172.32.x.x will route publicly and cause unpredictable failures. Use 172.30.x.x or another block within 172.16.0.0/12.
Examples only — not yet assigned
The CIDRs above are planning examples. Verify actual cluster CIDRs against all current and planned site subnets, machine networks, and any future VPN ranges before deploying a cluster.
Why separate pod and service CIDRs
Regular VLANs (40, 50, 100–108) carry real routed traffic managed by OPNsense. Pod and service CIDRs are CNI-internal: they exist only inside the cluster and are never advertised to OPNsense. Cilium in overlay mode encapsulates pod traffic so that infrastructure routing remains decoupled from CNI state. If pod CIDRs overlap real VLAN subnets, the kernel routing table becomes ambiguous and traffic silently drops or hairpins.
Related Pages
- Kubernetes Planning — cluster topology, node placement, CNI rationale, and full stack component list
- VLAN Reference — complete VLAN table with subnets and gateways for all 15 VLANs
- IP Addressing — site supernets, bootstrap networks, and addressing convention
- Site B — Ceph — Ceph storage backing for Kubernetes PersistentVolumes
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.
Platform Services
Application and platform services for the AORXI homelab: internal DNS via Technitium VMs, OpenBao secrets management, the UniFi OS Server controller, Kafka and database operations patterns, container build infrastructure, and certificate management via Let's Encrypt DNS-01 and step-ca.