Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
I’ve been playing a little bit with Istio mostly egress , but today i wanted to write about ingresses .
Basically Istio ingresses are a number of proxies (envoy) that kind of talk to each other to deal with access , throttling and app routing in general.
What is really interesting about the istio approach is the sidecar injection, imagine that you’re running a container execs nginx (port80 )S
What istio does is “inject” a sidecar container , that runs on the same pod , that means , sharing the kernel network namespace with privileged mode and NET_ADMIN capabilities.
That way , they guarantee full tracing of services for example or mutual tls for example.
In very simple terms it looks like this:
This is much different than having a traditional nginx ingress , the nginx ingress speaks to a service that iptables to a pod , for example:
So what’s the main difference? well that side container , it’s called istio-proxy and it “INTERCEPTS” traffic , i was particularly interested in the way that this intercepts traffic .
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 privileged and have NET_ADMIN , this is especially important if your mangling ti SOCK options like IP_TRANSPARENT or managing IPTables rules , not for the kube host , but for the struct net bound the pod.
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 “HEAD” request , 1 to envoy (forced by iptales ) and 1 to nginx.
I’l write a little more about how to set all the ingress elements later on.
K8 Istio little Deep Dive was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.