共计 2626 个字符，预计需要花费 7 分钟才能阅读完成。
前言
Envoy 是一款面向 Service Mesh 的高性能网络代理服务。它与应用程序并行运行，通过以平台无关的形式提供通用性能来形象网络。当基础架构中的所有服务流量都通过 Envoy 网格时，通过统一的可观测性，很容易地查看问题区域，调整整体性能。
Envoy 也是 istio 的外围组件之一，以 sidecar 的形式与服务运行在一起，对服务的流量进行拦挡转发，具备路由，流量管制等等弱小个性。本系列文章，咱们将不局限于 istio，envoy 的官网文档，从源码级别切入，分享 Envoy 启动、流量劫持、http 申请解决流程的进阶利用实例，深度剖析 Envoy 架构。
本篇将是 Envoy 申请流程源码解析的第一篇, 次要分享 Envoy 的流量劫持。
边车模式
在 Istio 当中, envoy 运行有两种模式，别离为边车模式和代理模式。
其中边车模式为通过 iptable 进行流量劫持
拦挡模式
Istio 反对两种拦挡模式：
REDIRECT：应用 iptables 的 REDIRECT 指标来拦挡入站申请，转给 Envoy，从 Linux2.6.15 的内核版本后，iptables 开始反对状态跟踪 (conntrack)，该性能依赖于 netfilter 的内核模块 nf_conntrack。尔后，iptables 能够依据包的状态进行二次的过滤拦挡和状态跟踪。它也是 state/ctstate 和 nat 的次要依赖模块。
TPROXY：应用 iptables 的 TPROXY 指标来拦挡入站申请，tproxy 能够用于 inbound 流量的重定向，且无需扭转报文中的目标 IP/ 端口，不须要执行连贯跟踪，不会呈现 conntrack 模块创立大量连贯的问题。受限于内核版本，tproxy 利用于 outbound 存在肯定缺点。目前 Istio 反对通过 tproxy 解决 inbound 流量。
能够全局的设置默认拦挡模式，也能够通过 sidecar.istio.io/interceptionMode(http://sidecar.istio.io/inter…): TPROXY 给某个工作负载独自设置。
无论采纳哪种通明劫持计划，均须要解决获取实在目标 IP / 端口的问题，应用 iptables 计划通过 getsockopt 形式获取，tproxy 能够间接读取目标地址。
对于 trpoxy
https://github.com/istio/isti…
对于 netfilter 和 conntrack
https://serverfault.com/quest…
对于为什么 istio 思考 inbound 反对 tproxy 模式
如果咱们是服务端，那么 SYN 包达到的时候，在 POSTROUTING 链的 NAT 表执行过之后（可能做 DNAT 或者 REDIRECT），路由表将决定是 FORWARD 还是 INPUT：
如果 INPUT，那么 conntrack 记录就此生成，当回包的时候会首先依据 conntrack 作地址还原，并且是不会通过 OUTPUT/POSTROUTING 链 NAT 表的。
如果 FORWARD，那么 conntrack 记录不会立刻生成，须要通过 POSTROUTING 之后才晓得是否做了 SNAT/MASQUERADE，此时才会生成 conntrack 记录。当收到上游回包的时候，不会过 PREROUTING 的 NAT 表，而是间接依据 conntrack 还原为原始 IP 地址，而后间接 FORWARD->POSTROUTING（不会过 NAT 表）送回原始客户端。
目前 Istio 应用 iptables 实现通明劫持，因为须要借助于 conntrack 模块实现连贯跟踪，在连接数较多的状况下，会造成较大的耗费，同时可能会造成 track 表满的状况，为了防止这个问题，业内有 ebpf 的减速计划，报文能够不过内核协定栈进行减速穿梭
对于 track 表的限度的材料
https://www.cyberciti.biz/faq…
默认模式简介
进入 sidecar 的网络空间，这里介绍的是 iptables redirect 模式
可见进口都 redirect 到 15001 当中，入口流量都被劫持到 15006 端口
查看 iptables 规定（对 iptables 相熟的小伙伴能够看到，除了截图的进口，入口流量的劫持，针对某些端口）
10.96.0.10 为 k8s 环境中 dns 服务器地址（默认为 coredns 的 svc ip）由 istio 取得填充
对于为什么 iptable 除了 udp 的 53 端口做拦挡，对 tcp 的 53 也做了拦挡
https://github.com/istio/isti… 为了反对 dns over tcp
15001 和 15006 离开
https://github.com/istio/isti…
除了其余一些针对特定 uid 用户的流量和 lo 口的 return 避免流量循环，iptable 规定中还呈现了个 127.0.0.6 的地址，这里做出简略解释，参见：https://github.com/istio/isti…
对于 inbound 的设计文档
https://docs.google.com/docum…
对于 iptables
附 iptables 劫持图：
网关模式
网关模式并无 iptables 作流量劫持，listener 也并非虚构 listener，敬请期待下一篇剖析
ASM 试用申请
Envoy 是 Istio 中的 Sidecar 官网标配，是一个面向 Service Mesh 的高性能网络代理服务。
以后 Service Mesh 是 Kubernetes 上微服务治理的最佳实际，灵雀云微服务治理平台 Alauda Service Mesh（简称：ASM）可残缺笼罩微服务落地所须要的基础设施，让开发者真正聚焦业务。
如果您想深刻体验 ASM，扫描下方二维码即可报名！
参考文档
https://www.debuntu.org/how-t…
https://www.envoyproxy.io
对于【云原生小课堂】
【云原生小课堂】是由灵雀云、Kube-OVN 社区、云原生技术社区联结开设的公益性技术分享类专题，将以丰盛详实的精品内容和灵活多样的出现模式，继续为您分享云原生前沿技术，带您理解更多云原生实际干货。
在数字化转型的背景下，云原生曾经成为企业翻新倒退的外围驱动力。作为国内最早将 Kubernetes 产品化的厂商之一，灵雀云从出世便携带“云原生基因”，致力于通过革命性的技术帮忙企业实现数字化转型，咱们期待着云原生给这个世界带来更多扭转。
关注灵雀云，学习更多云原生常识，一起让扭转产生。