Envoy sidecar proxy - kubernetes

Question

I am trying to understand the istio and envoy behavior and how the proxy works!
Lets assume that I created an application which keeps on the sending the request to google search API. When I deploy that in my k8s cluster with istio and envoy as a sidecar container, It is said all the requests are routed via the proxy/sidecar container.
My question is - both the application and the proxy/sidecar are running in the same pod and sharing the same IP. In order for the app to send the request to sidecar, it should be modified to send the request to the localhost (ie to the proxy server port) so that it can forward to google. But how the outbound requests of one application is routed to another application. Where is this configuration maintained?
Can someone who understood this well please explain?

Answer 1

istio-init init container is used to setup the iptables rules so that inbound/outbound traffic will go through the sidecar proxy. An init container is different than an app container in following ways:
It runs before an app container is started and it always runs to completion.
If there are many init containers, each should complete with success before the next container is started.
So, you can see how this type of container is perfect for a set-up or initialization job which does not need to be a part of the actual application container. In this case, istio-init does just that and sets up the iptables rules.
istio-proxy This is the actual sidecar proxy (based on Envoy).
Get into the application pod and look at the configured iptables. I am going to show an example using nsenter. Alternatively, you can enter the container in a privileged mode to see the same information. For folks without access to the nodes, using exec to get into the sidecar and running iptables is more practical.
$ docker inspect b8de099d3510 --format '{{ .State.Pid }}'
4125
$ nsenter -t 4215 -n iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N ISTIO_INBOUND
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp -m tcp --dport 80 -j ISTIO_IN_REDIRECT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
The output above clearly shows that all the incoming traffic to port 80, which is the port the application is listening, is now REDIRECTED to port 15001, which is the port that the istio-proxy, an Envoy proxy, is listening. The same holds true for the outgoing traffic.
Update: In place of istio-init, there now seems to be an option of using the new CNI, which removes the need for the init container and associated privileges. This istio-cni plugin sets up the pods’ networking to fulfill this requirement in place of the current Istio injected pod istio-init approach.
https://istio.io/blog/2019/data-plane-setup/#traffic-flow-from-application-container-to-sidecar-proxy