Introduction

Yes, K3s can run Flannel on a specific network interface instead of relying on the default route interface. This is common on hosts with separate management and data networks, or when private traffic must stay on a dedicated subnet. The key is to set interface and node address options consistently on both server and agent nodes.

Understand Which Address K3s and Flannel Use

K3s and Flannel make several networking decisions at startup. If those decisions are left to defaults on multi-homed hosts, one node may advertise a different interface than the one you expect, causing cross-node pod traffic issues.

Important settings are:

• --node-ip: the node address published to the cluster.
• --flannel-iface: the host interface Flannel should use.
• --node-external-ip: optional, only when external clients need a different address.

Before configuring K3s, inspect interfaces and confirm the exact device name and address you want.

ip -4 addr show
ip route

If your target interface is ens192 with address 10.20.0.12, you should use that same source for both node identity and Flannel binding.

Configure K3s Server With Explicit Interface Flags

On the server node, pass the interface options during install or place them in config. Using config files is easier to audit and maintain than long shell commands.

1# /etc/rancher/k3s/config.yaml
2write-kubeconfig-mode: "0644"
3node-ip: "10.20.0.12"
4flannel-iface: "ens192"
5cluster-cidr: "10.42.0.0/16"
6service-cidr: "10.43.0.0/16"

Then install or restart K3s:

curl -sfL https://get.k3s.io | sh -
sudo systemctl restart k3s
sudo systemctl status k3s --no-pager

If you prefer one line install flags:

curl -sfL https://get.k3s.io | \
  INSTALL_K3S_EXEC='server --node-ip 10.20.0.12 --flannel-iface ens192' sh -

Both approaches work, but avoid mixing different values between installer flags and config file, because later restarts can become confusing.

Configure Agent Nodes the Same Way

Every joining node should advertise and tunnel over the intended interface. If agents use defaults while server is pinned to a dedicated network, overlay routing can become asymmetric.

Agent config example:

1# /etc/rancher/k3s/config.yaml
2server: "https://10.20.0.12:6443"
3token: "REPLACE_WITH_CLUSTER_TOKEN"
4node-ip: "10.20.0.21"
5flannel-iface: "ens192"

Install agent:

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC='agent' sh -
sudo systemctl restart k3s-agent

Repeat with node-specific node-ip values for each host. Do not copy one static address across nodes.

Validate That Flannel Uses the Correct Path

After deployment, verify node addresses and Flannel behavior before putting workloads on the cluster.

kubectl get nodes -o wide
kubectl -n kube-system get pods -l app=flannel -o wide
kubectl -n kube-system logs -l app=flannel --tail=100

Look for signs that Flannel selected the intended interface and subnet. You can also run a quick connectivity check between pods scheduled on different nodes.

kubectl run net-a --image=busybox:1.36 --restart=Never -- sleep 3600
kubectl run net-b --image=busybox:1.36 --restart=Never -- sleep 3600
kubectl get pods -o wide

Then exec into one pod and ping the other pod IP:

kubectl exec -it net-a -- ping -c 3 10.42.1.15

If this fails while node-to-node host ping works, inspect Flannel logs and ensure interface names are valid on every host.

Production Tips for Multi Interface Hosts

Keep naming stable. Interface names can vary across distributions or cloud images. If one node uses eth1 and another uses ens192, setting a single global value in automation can break new nodes.

Prefer host-level inventory with per-node values. Also document whether your cluster depends on private routing, and verify firewall rules allow VXLAN traffic when using default Flannel backend.

For hardened environments, pair interface binding with explicit firewall policies:

sudo ufw allow in on ens192 to any port 8472 proto udp
sudo ufw allow in on ens192 to any port 6443 proto tcp

Adjust ports to your CNI mode and control-plane design.

Common Pitfalls

• Setting flannel-iface only on server and forgetting agents.
• Using a node IP that does not belong to the selected interface.
• Assuming interface names are identical across all hosts.
• Restarting only one node and expecting cluster-wide routing changes.
• Ignoring firewall rules for overlay traffic on the bound interface.

Summary

• K3s can bind Flannel to a non-default interface with flannel-iface.
• Pair interface binding with explicit node-ip on each node.
• Use config files for repeatable operations and simpler troubleshooting.
• Validate node addresses, Flannel logs, and cross-node pod connectivity.
• Standardize per-node network settings in automation to prevent drift.