Some doubts about the iptables mode of kube-proxy

I have recently been modifying kube-proxy to support our internal business, and I have doubts about two places.

  • Why nodeport rules need to be inserted last after other rules?
  • Why does local access to lb service require masq?

Two problems are in the kube-proxy(v1.24.11-iptables mode)source code:

Why nodeport rules need to be inserted last after other rules?

Why does local access to lb service require masq?

Node parts are last because they don’t have an address match usually. If they went before other rules, then they could collide with services which are more specific because they have an address match.

IIRC That particular masquerade is to prevent hairpin traffic from the node from being flagged as Martian.

1 Like

Thank you for your answer!

I can understand question 1, but I still don’t understand question 2. Can you give a practical example of the difference between not doing masq and doing masq?

Hi, when I deleted the following rules, I found that directly accessing the local loadbalancer ip on the node can still be accessed.

like this:

iptables -t nat -D KUBE-EXT-5J2MEIPCD4GMETYI -m comment --comment "masquerade LOCAL traffic for kubernetes-check/lb-nginx external destinations" -m addrtype --src-type LOCAL -j KUBE-MARK-MASQ

Before deleting the rule, I can be sure that this rule will be hit when accessing
So I don’t quite understand what kind of scenario this special masq rule is designed for