Networking is where most Harvester deployments succeed or struggle. Let's build it up carefully.
13.1 The layers¶
| Layer | Object | What it does |
|---|---|---|
| Physical | NICs, bonds | Uplinks on each host |
| Cluster network | ClusterNetwork |
A named L2 domain spanning hosts (e.g. mgmt, data) |
| Uplink config | VlanConfig |
Binds NICs on selected nodes to a cluster network; creates <name>-bo bond and <name>-br bridge |
| VM network | NetworkAttachmentDefinition |
A VLAN (or untagged) network on a cluster network that VMs attach to |
| Overlay/VPC | Kube-OVN Vpc, Subnet, NAT gateway |
Software-defined tenant networks (newer releases) |
| Pod network | Canal | Harvester's own cluster traffic; VM "management network" option |
| Storage network | storage-network setting |
Dedicated VLAN/NIC for Longhorn replication |
| LB | LoadBalancer, IPPool |
L4 services for VMs and guest clusters |
13.2 The built-in mgmt cluster network¶
Created at install time from the management interface(s): bond mgmt-bo, bridge mgmt-br. It carries:
- Kubernetes/Harvester control traffic.
- The cluster VIP.
- Optionally VM VLAN networks (you can create VM networks on
mgmtif you only have one NIC pair).
With limited NICs, putting VM VLANs on mgmt is fine; trunk the switch ports and keep the management VLAN as native/untagged or specify vlan_id at install.
13.3 Custom cluster networks¶
With more NICs, separate VM data plane from management:
apiVersion: network.harvesterhci.io/v1beta1
kind: ClusterNetwork
metadata:
name: data
---
apiVersion: network.harvesterhci.io/v1beta1
kind: VlanConfig
metadata:
name: data-rack-a
spec:
clusterNetwork: data
nodeSelector:
topology.kubernetes.io/zone: rack-a # optional: only some nodes
uplink:
nics:
- enp65s0f0
- enp65s0f1
linkAttributes:
mtu: 9000
bondOptions:
mode: 802.3ad
miimon: 100
Rules worth memorizing:
- A NIC can belong to only one cluster network.
- Multiple
VlanConfigs can serve one cluster network across different node groups (heterogeneous NIC names). Each node can be covered by at most oneVlanConfigper cluster network. - MTU must be consistent across all
VlanConfigs of a cluster network. - A VM scheduled on a node not covered by the cluster network won't start — Harvester labels nodes (
network.harvesterhci.io/<clusternetwork>=true) and the VM gets matching affinity automatically. - Bond modes:
active-backup(no switch config),802.3ad(LACP, needs switch config),balance-tlb,balance-alb, etc.
13.4 VM networks (VLAN)¶
UI: Networks → VM Networks → Create → type L2VlanNetwork → VLAN ID → cluster network.
Underlying object:
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: vlan100-servers
namespace: default
labels:
network.harvesterhci.io/clusternetwork: data
network.harvesterhci.io/type: L2VlanNetwork
network.harvesterhci.io/vlan-id: "100"
annotations:
network.harvesterhci.io/route: '{"mode":"auto","serverIPAddr":"","cidr":"","gateway":""}'
spec:
config: >-
{"cniVersion":"0.3.1","name":"vlan100-servers","type":"bridge",
"bridge":"data-br","promiscMode":true,"vlan":100,"ipam":{}}
Notes:
ipam: {}— Harvester doesn't do DHCP for VLAN networks; your physical network (router/DHCP server) does. VMs get IPs from your existing infrastructure — exactly like port groups in vSphere.- The route annotation lets Harvester discover the subnet/gateway (via DHCP probe in
automode, or manual) — needed for the load balancer and guest clusters to know the CIDR. - Untagged networks (
L2VlanTrunkNetwork/untagged types depending on version) attach VMs to the native VLAN. - VLAN trunk networks pass a range of VLANs into the guest (useful for virtual routers/firewalls like OPNsense or VyOS).
- Namespace matters: networks in
defaultare usable by VMs indefault; networks can be created in other namespaces for tenant scoping.
13.5 Management network for VMs¶
A VM can use the pod network (masquerade NAT through the host). It's convenient (no VLAN needed) but:
- The VM's IP changes across restarts/migrations.
- Inbound access requires Services/LoadBalancers.
- Not suitable for most server workloads; fine for quick tests.
13.6 Overlay networks and VPCs (Kube-OVN)¶
Recent releases integrate Kube-OVN to give OpenStack/cloud-style software-defined networking:
- VPCs — isolated L3 domains with overlapping CIDRs between tenants.
- Subnets — Harvester-managed IPAM and DHCP inside overlays.
- NAT gateways — SNAT/DNAT/EIP between VPCs and the underlay (v1.9).
- Isolated guest load balancers inside VPCs (v1.9).
This is the closest Harvester gets to Neutron tenant networks + floating IPs. It's newer than VLAN networking; read the version-specific docs on prerequisites (often enabled as an add-on), supported topologies, and limitations (e.g. live migration and LB behaviour on overlays) before committing production tenants to it.
13.7 Storage network¶
By default Longhorn replication traffic rides the management network. Configure a dedicated one:
// Setting: storage-network
{
"vlan": 200,
"clusterNetwork": "storage",
"range": "172.16.200.0/24",
"exclude": ["172.16.200.1/32"]
}
- Create the
storagecluster network and itsVlanConfigfirst. - The
rangemust provide one IP per Longhorn instance-manager pod (roughly nodes × a few) — be generous. - Changing the storage network requires all VMs to be stopped (Longhorn instance managers restart). Do it early.
- Jumbo frames (MTU 9000) help noticeably for replication — ensure switch ports and every hop agree.
13.8 Load balancing¶
The built-in harvester-load-balancer provides L4 LBs:
- VM load balancers: select backend VMs by label; listeners on TCP/UDP ports; health checks.
- Guest cluster load balancers: Services of
type: LoadBalancerin guest RKE2/K3s clusters, fulfilled by the Harvester cloud provider. - IPAM modes:
dhcp(LB requests an address from your DHCP server on the VLAN) orpool(from anIPPoolyou define).
apiVersion: loadbalancer.harvesterhci.io/v1beta1
kind: IPPool
metadata:
name: vlan100-lb
spec:
ranges:
- subnet: 10.100.0.0/24
gateway: 10.100.0.1
rangeStart: 10.100.0.200
rangeEnd: 10.100.0.239
selector:
network: default/vlan100-servers
scope:
- project: "*"
namespace: "*"
guestCluster: "*"
Under the hood the LB VIPs are announced by kube-vip (ARP in L2 mode) on Harvester nodes.
13.9 Network design patterns¶
Pattern A — two NICs (small/homelab):
eno1+eno2 → mgmt-bo (active-backup or LACP) → mgmt-br
├─ native VLAN 10: management + VIP
├─ VLAN 100, 101…: VM networks (on mgmt cluster network)
└─ VLAN 200: storage network (on mgmt cluster network)
Pattern B — four NICs (production minimum):
eno1+eno2 (1/10G) → mgmt : management, VIP
ens1f0+ens1f1 (25G) → data : VM VLANs (trunk) + storage network VLAN
Pattern C — six NICs (performance):
mgmt : 2× 10G management
data : 2× 25G VM traffic
storage : 2× 25G Longhorn replication (MTU 9000)
← Installing Harvester · Index · Harvester storage in depth →