From 97494c10b8114958ea88b93778b42becf8e7dba0 Mon Sep 17 00:00:00 2001 From: zhangzujian Date: Wed, 12 Aug 2026 11:34:54 +0800 Subject: [PATCH 1/3] docs: clarify underlay connectivity requirements Signed-off-by: zhangzujian --- .../networking/how_to/kube_ovn/kubeovn_underlay_py.mdx | 4 ++++ .../networking/how_to/kube_ovn/underlay_overlay_st.mdx | 9 +++++++++ 2 files changed, 13 insertions(+) diff --git a/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx b/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx index 9a749032a..c30dfa3eb 100644 --- a/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx +++ b/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx @@ -42,6 +42,10 @@ In Underlay mode, Kube-OVN bridges a physical NIC to OVS and sends packets direc - For service access traffic, Pods will first send packets to the gateway, which must have the ability to forward packets back to the local subnet. + - You are responsible for ensuring connectivity for Pods on the Underlay network. Configure routes, firewalls, security groups, and other physical network policies to allow all traffic required by your workloads. The following common paths must be allowed as applicable: + - HTTP, TCP, and gRPC probes are initiated by the kubelet on the node that hosts the Pod. Every node on which the Pod can run must be able to reach the Pod IP and the configured probe endpoint, protocol, and port. + - For DNS resolution, Pods must be able to reach the `kube-dns` Service and its backing endpoints over the configured DNS protocols and ports, normally UDP and TCP port 53. Return traffic must also be allowed. + - When the switch or bridge has Hairpin functionality enabled, **Hairpin must be disabled**. If using a VMware virtual machine environment, set **Net.ReversePathFwdCheckPromisc** on the VMware host to **1**, and Hairpin does not need to be disabled. - The bridging NIC **cannot** be a **Linux Bridge**. diff --git a/docs/en/networking/how_to/kube_ovn/underlay_overlay_st.mdx b/docs/en/networking/how_to/kube_ovn/underlay_overlay_st.mdx index b49e92329..085411fce 100644 --- a/docs/en/networking/how_to/kube_ovn/underlay_overlay_st.mdx +++ b/docs/en/networking/how_to/kube_ovn/underlay_overlay_st.mdx @@ -7,6 +7,15 @@ If a cluster has both Underlay and Overlay subnets, by default, Pods under the O To achieve automatic interconnection between Underlay and Overlay subnets, you can manually modify the YAML file of the Underlay subnet. Once configured, Kube-OVN will also use an additional Underlay IP to connect the Underlay subnet and the ovn-cluster logical router, setting the corresponding routing rules to enable interconnection. +## Node-to-Pod Traffic Path + +With ACP 4.4 defaults, enabling `u2oInterconnection` does not automatically route traffic from cluster nodes to Underlay Pods through `ovn0`: + +- Traffic from a node to an Underlay Pod follows the node's Linux routing table and normally relies on the physical network path. Kube-OVN installs a route for the Underlay CIDR through `ovn0` only when the Underlay subnet belongs to the default VPC, U2O is enabled, load balancing is disabled for the subnet, and no conflicting route exists. +- An Underlay Pod uses the U2O interconnection IP as its logical gateway. For traffic from the Pod to a cluster node InternalIP, Kube-OVN routes the packet to the Underlay physical gateway and sends it through the ProviderNetwork bridge and physical NIC. The same policy applies to the local node and other nodes, and to IPv4 and IPv6. + +Configure physical routes and firewall policies to allow bidirectional traffic between every required node address and Underlay Pod CIDR. This is required for node-originated traffic such as kubelet HTTP, TCP, or gRPC probes. + ## Procedure 1. Go to **Administrator**. From 4ef52f905a133287382b9dcc1e2b3086532c907d Mon Sep 17 00:00:00 2001 From: zhangzujian Date: Wed, 12 Aug 2026 11:53:51 +0800 Subject: [PATCH 2/3] docs: use configured DNS endpoint ports Signed-off-by: zhangzujian --- docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx b/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx index c30dfa3eb..909e76dac 100644 --- a/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx +++ b/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx @@ -44,7 +44,7 @@ In Underlay mode, Kube-OVN bridges a physical NIC to OVS and sends packets direc - You are responsible for ensuring connectivity for Pods on the Underlay network. Configure routes, firewalls, security groups, and other physical network policies to allow all traffic required by your workloads. The following common paths must be allowed as applicable: - HTTP, TCP, and gRPC probes are initiated by the kubelet on the node that hosts the Pod. Every node on which the Pod can run must be able to reach the Pod IP and the configured probe endpoint, protocol, and port. - - For DNS resolution, Pods must be able to reach the `kube-dns` Service and its backing endpoints over the configured DNS protocols and ports, normally UDP and TCP port 53. Return traffic must also be allowed. + - For DNS resolution, Pods must be able to reach the `kube-dns` Service and its backing endpoint addresses. Allow the protocols and ports defined by the actual Service and EndpointSlice or Endpoints configuration; do not assume that an endpoint uses the same port as the Service. Return traffic must also be allowed. - When the switch or bridge has Hairpin functionality enabled, **Hairpin must be disabled**. If using a VMware virtual machine environment, set **Net.ReversePathFwdCheckPromisc** on the VMware host to **1**, and Hairpin does not need to be disabled. From 9270f80f0ddd747fcbc245462be8b355fcb3e884 Mon Sep 17 00:00:00 2001 From: zhangzujian Date: Wed, 12 Aug 2026 17:19:59 +0800 Subject: [PATCH 3/3] docs: clarify configured DNS server access Signed-off-by: zhangzujian --- docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx b/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx index 909e76dac..ee4899554 100644 --- a/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx +++ b/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx @@ -44,7 +44,7 @@ In Underlay mode, Kube-OVN bridges a physical NIC to OVS and sends packets direc - You are responsible for ensuring connectivity for Pods on the Underlay network. Configure routes, firewalls, security groups, and other physical network policies to allow all traffic required by your workloads. The following common paths must be allowed as applicable: - HTTP, TCP, and gRPC probes are initiated by the kubelet on the node that hosts the Pod. Every node on which the Pod can run must be able to reach the Pod IP and the configured probe endpoint, protocol, and port. - - For DNS resolution, Pods must be able to reach the `kube-dns` Service and its backing endpoint addresses. Allow the protocols and ports defined by the actual Service and EndpointSlice or Endpoints configuration; do not assume that an endpoint uses the same port as the Service. Return traffic must also be allowed. + - For DNS resolution, Pods must be able to reach the DNS server configured for the cluster, such as an endpoint backing the `kube-dns` Service. Allow the protocols and ports configured for that DNS server. For `kube-dns` endpoints, follow the actual EndpointSlice or Endpoints configuration; do not assume that an endpoint uses the same port as the Service. Return traffic must also be allowed. - When the switch or bridge has Hairpin functionality enabled, **Hairpin must be disabled**. If using a VMware virtual machine environment, set **Net.ReversePathFwdCheckPromisc** on the VMware host to **1**, and Hairpin does not need to be disabled.