On any of the K8S nodes, you can see a routing table similar to the following.
The 10.42.1.0/24 and 10.42.2.0/24 subnets in this table happen to be part of the K8S Overlay network. And this routing table gives you a clue that you can access the Pod from any node via Cluster IP.
Note that the Pod is accessed from any node, not from inside the K8S Cluster Overlay network.
So now let’s summarize the current situation.
- K8S requires that
net.ipv4.ip_forward = 1be turned on during installation (documentation ipv4-and-letting-iptables-see-bridged-traffic)).
- Pods within the cluster can be accessed from any node via Cluster IP because the routing table is set on the node.
- Implicit case: Pod can access to the subnet where the node is located.
Combining these 3 scenarios so far, one conclusion can be drawn.
Pods within a K8S cluster can be accessed via Cluster IP using any K8S node.
This is indeed the case. Find a server on the same subnet but not a K8S node, set the routing rules, and you will find that you can successfully initiate a ping.
So the conclusion is.
- Pods within a K8S cluster can be accessed via Cluster IP using any K8S node.
- Therefore, the node firewall for K8S needs to be configured with inbound rules that strictly define which IPs can be accessed.