我试图了解istio和使节的行为以及代理的工作原理!
让我们假设我创建了一个继续将请求发送到Google搜索API的应用程序。当我使用istio和envoy作为sidecar容器在我的k8s集群中部署它时,据说所有请求都是通过proxy / sidecar容器路由的。
我的问题是-应用程序和代理/小车都在同一个Pod中运行并共享同一个IP。为了使应用程序将请求发送到Sidecar,应对其进行修改以将请求发送到本地主机(即,发送到代理服务器端口),以便它可以转发到google。但是如何将一个应用程序的出站请求路由到另一应用程序。此配置在哪里维护?
能很好理解这一点的人可以解释吗?
答案 0 :(得分:1)
istio-init
初始化容器用于设置iptables规则,以便入站/出站流量将通过Sidecar代理。初始化容器与应用程序容器在以下方面有所不同:
它在启动应用程序容器之前运行,并且始终运行到完成。 如果有许多初始化容器,则每个容器都应在启动下一个容器之前成功完成。
因此,您可以看到这种类型的容器对于不需要实际应用程序容器的一部分的设置或初始化作业是多么完美。在这种情况下,istio-init会这样做并设置iptables规则。
istio-proxy这是实际的Sidecar代理(基于Envoy)。
进入应用程序窗格,并查看已配置的iptables。我将展示一个使用nsenter的示例。或者,您可以以特权模式进入容器以查看相同的信息。对于无法访问节点的人员,使用exec进入sidecar并运行iptables更实用。
$ 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
上面的输出清楚地显示,到端口80(应用程序正在监听的端口)的所有传入流量现在已重定向到端口15001,这是Envoy代理istio-proxy正在监听的端口。对于传出流量也是如此。
更新:代替istio-init,现在似乎可以使用新的CNI,从而消除了对初始化容器和相关特权的需求。这个istio-cni插件可以设置Pod的网络,以满足当前的Istio注入Pod istio-init方法的要求。