I’ve been playing a little bit with mostly egress , but today i wanted to write about . Istio ingresses Basically ingresses are a number of proxies ( ) that kind of talk to each other to deal with access , throttling and app routing in general. Istio envoy What is really interesting about the approach is the sidecar injection, imagine that you’re running a container execs (port80 )S istio nginx What does is “ ” a sidecar container , that runs on the same pod , that means , sharing the kernel network namespace with mode and capabilities. istio inject privileged NET_ADMIN That way , they guarantee full tracing of services for example or mutual tls for example. In very simple terms it looks like this: Istio workflow This is much different than having a traditional nginx ingress , the nginx ingress speaks to a service that iptables to a pod , for example: nginx ingress workflow So what’s the main difference? well that side container , it’s called istio-proxy and it “ ” traffic , i was particularly interested in the way that this intercepts traffic . INTERCEPTS The hint is when you see: That means that within the struct net that the kernel namespace represents ( or pod) , this container needed to be and have , this is especially important if your mangling ti options like or managing IPTables rules , not for the kube host , but for the struct net bound the pod. privileged NET_ADMIN SOCK IP_TRANSPARENT So if you created your pod with nginx listening on 8000 and injected it with istioctl , the iptables on the side car will look like(note you have to enter it with privileged mode enabled docker exec — privileged -it 75375f8d4c98 bash) root@nginx-847679bd76-mj4sw:~# iptables -t nat -S-P PREROUTING ACCEPT-P INPUT ACCEPT-P OUTPUT ACCEPT-P POSTROUTING ACCEPT-N ISTIO_INBOUND-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_REDIRECT-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 Now it’s clear that this is redirecting all incoming traffic into 80 to 150001 , which is bonud by istio-proxy , envoy does it works and it will send traffic to nginx(80). netstat shows: 15001 is there , let’s see tcpdump: So initially there’s traffic coming to port 80 , but it gets redirected to localhost:15001 , that’s envoy , next step is actually send traffic to nginx itelf , that’s why we see a double “ ” request , 1 to envoy (forced by iptales ) and 1 to nginx. HEAD I’l write a little more about how to set all the ingress elements later on.
