Network planes
The management LAN carries cluster-local Kubernetes traffic. A WireGuard overlay provides hub-to-cluster management reachability. Workload execution does not depend on the hub; the overlay is for enrollment, OCM, Helm install jobs, and optional hub-gateway forwarding.
| Path | Boundary |
|---|---|
| Console and management APIs | Authenticated access over the private management path |
| Hub-routed workload | Public application ingress on the hub, then hub-to-cluster overlay traffic |
| Site workload | A separately configured site ingress path (port_forward, reverse_proxy) |
Each FleetSite declares how that location reaches the WAN:
| Site edge field | Meaning |
|---|---|
hubGateway |
When enabled, public HTTP/S on the hub can forward to spokes over WireGuard |
ingress[] with method: port_forward |
WAN port-forwards to spoke Traefik NodePorts; one cluster binds per entry |
ingress[] with method: reverse_proxy |
External reverse proxy terminates TLS; many clusters may share an entry |
| Neither | No fleet-managed WAN exposure at the site |
Clusters select an ingress row with FleetClusterJoin.spec.edge.ingressId. Inventory examples: examples/site-profiles/.
On site homelab, WAN DNAT for *.homelab.otthol.hu hits the spoke VIP NodePorts 172.16.10.100:30080 (HTTP) and 172.16.10.100:30443 (HTTPS) on lab-ha-0, not hub Traefik. Hub Traefik is the gateway for demo.otthol.hu and binds TCP 80 and 443 on the hub.
Do not expose management APIs, registry endpoints, or Kubernetes NodePorts to the public network by default. Firewall, DNS, NAT, cloud security groups, and route validation remain operator responsibilities.