Istio 流量劫持

运用服务网格的好处，就是不用修改本身应用的任何代码，就可以实现重试、重试、注册、发现、故障注入等等的能力，而且对开发语言、框架都是没有任何限定统一的技术栈的，那么为什么服务网格那么厉害可以做到那么透明呢，不用修改应用的任何代码让应用获得服务的治理能力呢，我们一起了解一下吧！

Istio的数据平面是由多个应用容器（App）加边车容器（Envoy）的Pods组成的，可以参考我之前的文章 - Istio 项目介绍， Istio Envoy 的工作原理就是通过 Kubernetes Pods的共享NameSpace特性，把边车容器与应用容器"绑定"在一起，并且通过 iptables 修改应用容器的进出流量都需要经过Envoy，在Envoy上进行流量的管控从而实现服务的治理能力。 这也是在代码开发中，经常使用的"边车模式"。

上诉我们已经知道了通过iptables修改流量的走向，让Envoy去接管流量从而实现服务的治理能力，那么iptables是如何修改进去Pods中的呢，可以参考我之前的文章 - Istio 注入原理，通过对原来的资源定义清单进行修改后实施，从而附加上 Envoy 容器以及 Init 容器，Iptables的策略就是由 init容器进行定义的。

首先我们安装一下 nsenter 这个工具，用于接下来的实验探索。

yum install -y util-linux PID=$(docker inspect --format "{{ .State.Pid}}" ) nsenter -t $PID -n iptables -t nat -nvL

1

2

3

通过 nsenter 可以发现

1.进入的流量会命中#1红框的PREROUTING链。

2.接着在Target中会选择#2红框 ISTIO_INBOUND链。

3.如果是 tcp destination port 22 15090 15021的流量会直接放行处理，

否则其他流量全部交给下一个链 #3红框ISTIO_IN_REDIRECT。

4.ISTIO_IN_REDIRECT 链中就把流量交给了 15006 端口 （Envoy容器流量入端口）

REQUEST -> （IPTABLES PREROUTING -> ISTIO_INBOUND -> ISTIO_IN_REDIRECT -> REDIRECT PORT 15006） -> ISTIO-PROXY

通过 nsenter 可以发现

1.出去的流量会命中#1红框的OUTPUT链。

2.接着在Target中会选择#2红框 ISTIO_OUTPUT链。

如果是 Owner GID 1337 的流量会直接放行处理，GID1337 表示的是Envoy自身流量，以防止流量循环。

其他流量全部交给下一个链 #3红框ISTIO_REDIRECT。

3.ISTIO_REDIRECT 链中就把流量交给了 15001 端口 （Envoy容器流量出端口）

REQUEST -> （IPTABLES OUTPUT -> ISTIO_OUTPUT -> ISTIO_REDIRECT -> REDIRECT PORT 15001） -> ISTIO-PROXY

经过iptables处理后的流量，最后都会经过envoy进行处理（return的除外），那么在envoy进行流量的处理，那么就可以对应用透明无感知的情况下进行一些高级的治理能力处理，而envoy处理的规则，是由pilot进行下发的，具体可以定义那些服务治理规则的？欢迎继续关注，我们下期在见！

refer: https://istio.io/latest/docs/ops/deployment/requirements/

Istio

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。