Pod Egress and SNAT
No route on the internet leads back to a Pod IP, so how does a Pod reach the internet and get a reply? On the way out the Node walks its POSTROUTING rules, which exempt ranges such as the pod CIDR and masquerade the rest, rewriting the source to the Node IP and storing the flow in conntrack. The reply comes back to that Node IP and walks no masquerade rule: the stored entry reverses the translation, so the Pod never learns its address changed.
Play the animation 5 steps, animated, best on a wide screen
Pod Egress and SNAT, step by step
-
The app opens a connection to 1.1.1.1 and the packet leaves eth0 carrying src 10.244.1.5. No route on the internet leads back to that address, so the last netfilter hook on the way out is where the Node walks its POSTROUTING rules.
Play from step 1 -
Only the first packet of a flow walks these rules, in order. RETURN rules for the non-masquerade ranges come first, the pod CIDR 10.244.0.0/16 among them, so Pod to Pod traffic keeps its own source. 1.1.1.1 is in none of them, so it falls past RETURN to masquerade.
Play from step 2 -
MASQUERADE rewrites the source to the address of the interface the packet leaves by, 192.168.1.20. The flow it just translated goes into conntrack, and the packet leaves looking like it came from the Node, an address the reply can be routed to.
Play from step 3 -
The server answers 192.168.1.20, the only address it ever saw. The reply walks no masquerade rule at all. As it enters the Node, a conntrack lookup finds the stored entry and reverses the translation off it alone, which costs a lookup rather than a rule scan.
Play from step 4 -
With the destination restored to 10.244.1.5 the reply goes down the veth into the Pod. The Pod used its own source address the whole way, and the rewrite and its reversal both happened on the Node, invisible to either end of the connection.
Play from step 5