系列文章:


总目录索引:九析带你轻松完爆 istio 服务网格系列教程

目录

1 前言

2 查看 iptables 规则

    2.1 确定 pod 所在主机

    2.2 定位 istio-proxy 容器

    2.3 登录 istio-proxy 容器

    2.4 查看 iptables 规则

3 *** 宏观流量流向介绍

4 *** 微观流量流向介绍

5 istio 入口流量分析

6 istio 出口流量分析

7 小节


1 前言

        如果你对博客有任何疑问,请告诉我。

        上节中我们举例介绍了执行 istio 注入操作后,对 nginx pod 所产生的影响,即在 pod 中会多创建两个容器:istio-init、istio-proxy,如下图所示:

        如果从进程角度来看 pod,则是下面这个样子:

        从上图可知,nginx pod 内的三个容器共享同一个 *** 命名空间,该 *** 命名空间内的流量流向规则在初始化容器 istio-init 启动时完成的,如下图所示:


2 查看 iptables 规则

        一般情况下,我们可以通过 kubectl exec 命令跟 pod 进行交互并获取到 pod 内信息,但这里我们不能此法获取到 pod 内的 iptables 信息。如下截图所示:

        如果想获取到 iptables 信息,必须通过宿主机的 docker 才能获取到。

2.1 确定 pod 所在主机

        使用如下命令获取运行 nginx pod 的宿主机地址:

kubectl get pods -n jiuxi -o wide

        命令执行结果如下图所示:

2.2 定位 istio-proxy 容器

        ssh 命令登录到 10.244.10.80 宿主机,并执行如下命令定位 istio-proxy 容器:

docker ps | grep -i istio-proxy

        执行结果如下图所示:

2.3 登录 istio-proxy 容器

docker exec -it --privileged $(docker ps | grep -i istio-proxy | awk '{print $(1)}') bash

2.4 查看 iptables 规则

        执行如下命令查看 iptables 规则:

iptables -nvL -t nat

        执行结果会报如下错误:

can't initialize iptables table `nat': Permission denied (you must be root)

        执行如下命令切换成 root 用户轻松完爆:

sudo su root

        再次执行 iptables 即可,操作成功如下图所示:


3 *** 宏观流量流向介绍

        下面宏观介绍一下基本的 *** 流量流向知识,如下图所示:

        用户从客户端发起一个 http 请求,该请求会通过互联网到达公司 *** 的外部边界(路由器),路由器会将 *** 流量送到交换机,因为反向 *** 服务器跟交换机联通,因此流量到达反向 *** 服务器(nginx),nginx 再将 *** 请求按照预先制定的分发策略转给后面真正处理请求的 web 服务器。

        你可以通过 traceroute 命令定位一下外部 *** 流向。比如访问 www.baidu.com:

traceroute -I www.baidu.com

        访问截图如下:

        通过上面的截图可知,本人访问 baidu.com 共经过了 13 个路由器。

        当然也可以通过 traceroute 定位 k8s 中 pod 的 *** 流向,如下截图所示:

        由上图可知:

1 首先定位 nginx pod 的 ip 为 10.244.10.80

2 其次开始 traceroute 进行追踪,发现流量先经过 10.244.10.0,然后访问到 10.244.10.80

3 接着查看本地路由表得知访问 10.244.10.0 的流量是从 *** 设备 flannel.1 发出去的

4 最后查看了一下 *** 设备 flannel.1 的详细信息


4 *** 微观流量流向介绍

        微观是指流量进入宿主机的情况分析,如下图所示:

        由上图可知:

1 入口流量经过服务器网卡进入服务器的 *** 协议栈

2 服务器 *** 协议栈会根据预先定制的 *** 规则(iptables/netfilter)对报文进行检查

3 协议栈规则检查后,符合要求的流量会从内核态进入到用户态,并进入指定监听端口的进程

4 处于用户态的用户进程接收到 *** 流量报文进行处理后,将处理后的结果再通过用户态返回给内核态的 *** 协议栈

5 *** 协议栈检查报文,并将结果报文根据指定的 *** 策略通过网卡输送出去


5 istio 入口流量分析

        有了宏观和微观的 *** 流量流向分析之后,下一步就可以分析一下 istio 的入口流量了。因为涉及到 iptables 相关的知识,这里我仅仅把结论呈现给大家,具体 iptables 的使用如果大家有兴趣可以参考本人其他的博客轻松完爆。

        在上面我们已经展示了 istio-init 容器在启动时就完成了 *** 空间协议栈规则的初始化,如下图:

        现在可以通过 curl 访问 nginx pod。

curl 10.244.10.80

        curl 后的入口流量进入 nginx pod 后的流转路径如下图所示:

        由上图可知,整个 *** 流向如下:

1 因为匹配 iptables nat 表的 prerouting 链的第一条规则,因此 *** 流量被路由到 ISTIO_INBOUND 链

2 在 ISTIO_INBOUND 链一共有三条规则,因为访问的端口是 nginx 80,所以会匹配该链的第三条规则而将流量路由到 ISTIO_IN_REDIRECT 链

3 路由到 ISTIO_IN_REDIRECT 链的流量最终会从内核态打入到用户态监听端口为 15006 的进程

        端口 15006 的进程是什么呢?通过 netstat -ntlp 命令可知是 envoy 进程,如下图所示:

        由此可知,当我们 curl nginx pod 时,虽然指定的目标访问端口为 80,但是 *** 协议栈规则仍然会将整个流量劫持送到 envoy 进程,由于 envoy 进程可以获取到入口流量,所以可以在此制定一系列的操作起到流控的目的。envoy 处理完后,流量会继续移动,流向路径如下图所示:

        由上图可知,整个 *** 流向如下:

1 端口 15006 的进程处理完流量后,会将流量从用户态的进程传回内核态的 *** 协议栈,根据预先定义好的协议栈规则,流量会流经 output 链,output 链又会根据规则再把流量路由给 ISTIO_OUTPUT 链

2 因为 envoy 处理完流量最终要重新路由给 80 端口的 nginx 进程,因此处于 ISTIO_OUTPUT 链的第一条规则被匹配(因为 envoy 跟 nginx 在同一个 *** 命名空间,因此环回地址 lo 被匹配),此时流量会重新从内核态返回到用户态,并进入监听端口为 80 的 nginx 进程

3 nginx 处理完后,将结果通过 socket 连接返回给 envoy 进程(用户态)

4 envoy 再将流量通过 postrouting 链、网卡再将响应流量返回给用户


6 istio 出口流量分析

        上面介绍了 istio 入口请求流量流向分析,下面介绍一下 istio 出口流量流向分析,首先在 docker 容器内执行 curl 命令:

curl www.baidu.com

        下面截图展示出口流量的流向:

        从图可知:

1 出口流量首先会通过 iptables nat 表的 output 链进入到 istio_output 链

2 因为目的是 baidu,因此最终会匹配到 istio_redirect 链

3 istio_redirect 会将流量路由给端口 15001 的进程

        端口 15001 进程依旧是 envoy 进程,该端口处理的是 outbound 流量。如下截图所示:

        由此可知,访问 baidu 前,流量依旧会被 envoy 劫持。处理完毕后,envoy 流量处理结果如下图所示:

1 envoy 将处理后的 *** 流量重新通过用户态进入到内核态的 *** 协议栈,流量会首先经过 OUTPUT 链

2 流经 OUTPUT 链的流量会进入 ISTIO_OUTPUT 链

3 流入到 ISTIO_OUTPUT 链的流量会匹配 owner UID match 1337 规则

4 流量最终会通过 POSTROUTING 链进入到网卡

5 从网卡随风而出


7 小节

        本小节九析带你轻松完爆了 istio 注入 pod 后所导致的 *** 流量流向的改变。大家可以自己操作进行验证。这里告诉大家一个小窍门,如果想定位 *** 流量流向匹配 iptables 的哪条规则,可以通过观察 iptables 规则的 pkts、bytes 变化来确定。