Envoy's traffic hijacking(port forward) rule is stored at the pod level or host level?

Networking
1

Howdy! I’m new to Istio yet I’m tasked to evaluate Istio for possible adoption for my organization (a little sacred but also exited :-).
So I’m trying to understand how Envoy hijacks the traffic to perform service routing. I understand the init container “istio-init” uses istio-iptables.sh to accomplish this by using iptables tool to add netfilter rule for port forward (aka traffic hijack to the Envoy sidecar).

My question is: what is the scope of this netfilter rule for a particular pod? Is it just at the pod level, or is it at the host/node level? In other words, does the rule reside only in the pod, or in the host?

Because it only affects the traffic for the particular pod, it makes sense to be contained inside the pod; Yet my knowledge of docker (the container our Kube cluster is using) container is that any stuff in Linux kernel is shared by all containers on the host.And netfilter is in the kernel.

kube’s ClusterIP service is also implemented in a similar way, but definitely at the host level by kube-proxy. I believe there the reason that a process in kube-proxy container can affect host netfilter is that the kube-proxy is running under privileged mode ( securityContext:privileged set to true) and with HostNetwork property set, whereas Envoy container doesn’t have the privilege setting.

If the Envoy port forward rule is indeed at the host level, then the netfilter rule has to be qualified by the POD IP, right?

Thanks!

2

You are correct that netfilter/iptables rules are used to redirect traffic to Envoy. The rules are programmed into the pod’s network namespace. Even though all netfilter/iptables rules are executed by the kernel, any rules you program are scoped to the network namespace they are in, so the iptables rules programmed in the pod to capture traffic do not affect other pods or the host network namespace. So, the rules themselves can be written fairly broadly and do not explicitly have to be qualified by the pod IP.

Here is an example script: https://github.com/istio/istio/blob/576850c8780233e17ea0c9e5ec9c120e7a998fdd/tools/deb/istio-iptables.sh for your reference.

Kube-proxy has several variants, but you are correct that some use netfilter/iptables. Those rules are in the host network namespace when used, and the kube-proxy process must itself be run in the host network namespace.

1 Like
3

Spot on! That was quick! Thank you very much!