Configuring Routed Subnet Mode in Kube-OVN for Direct Pod‑to‑External IP Communication
This guide explains how to enable Kube-OVN's routed subnet mode, detailing prerequisites, disabling NAT, adding return routes, and adjusting gateway settings so that pod IPs can communicate directly with external networks without underlay support.
If you miss the rich networking capabilities of traditional SDN and are looking for a cloud‑native solution, Kube‑OVN is an excellent choice; this article walks through the routed subnet feature that lets pods communicate directly with external devices via their IP addresses.
In environments where an Underlay network is unavailable but pods still need direct IP connectivity, you can use routing mode to bridge the container network with the external network.
Prerequisites
The host must enable ip_forward .
Ensure the host's iptables forward chain does not drop container traffic.
Allow packets with the INVALID connection‑track state, which may appear in asymmetric routing scenarios.
Configuration steps
Set the subnet's natOutgoing field to false to disable NAT, allowing the pod IP to flow directly to the external network.
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
name: routed
spec:
protocol: IPv4
cidrBlock: 10.166.0.0/16
default: false
excludeIps:
- 10.166.0.1
gateway: 10.166.0.1
gatewayType: distributed
natOutgoing: falseAfter disabling NAT, pod packets can be routed to the peer node, but the peer must know the return path. Add a static route on the external host pointing the pod subnet to any node inside the Kubernetes cluster.
ip route add 10.166.0.0/16 via 192.168.2.10 dev eth0If the external host and the pod‑hosting node are not on the same L2 network, configure the appropriate rules on a router to bridge the traffic.
In some virtualized environments, asymmetric traffic may be dropped; change the subnet's gatewayType to centralized and set gatewayNode to the IP of a node that will act as the gateway.
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
name: routed
spec:
protocol: IPv4
cidrBlock: 10.166.0.0/16
default: false
excludeIps:
- 10.166.0.1
gateway: 10.166.0.1
gatewayType: centralized
gatewayNode: "node1"
natOutgoing: falseFor more detailed instructions, refer to the official Kube‑OVN documentation and community resources.
Cloud Native Technology Community
The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.