ingress control承载了控制面和数据面的一个职责，在control里面有一个process，这个进程就承担了反向代理的能力，当有任何请求发过来的时候，会被nginx接收到这个请求并且被转发，基于的规则由ingress control动态配置的，所以control就是控制平面，nginx本身就是其数据面。
在谈istio的时候一样会分数据面和控制面，控制面就是istio自身，istio会有各种各样的控制平面组件，比如istiod，在里面有流量控制的控制器，它会去监听istio相关的一些对象以及k8s status这些对象，它会基于这些对象把所有的路由配置信息变更组装成envoy的配置，然后推送给envoy。
envoy就是我们在istio里面数据平面的组件，所有的请求都是发到envoy，再由envoy转发到后端的服务器的。
主流七层代理软件比较
http2被业界认可以及部署的范围越来越广了，http2相对于http1.x来说它有一些明显的优势，因为是连接复用的，所以对整个网络的链路需求会小很多。
然后又是连接复用的，那么传输的性能会高很多。k8s很多组件都是基于grpc的，也是基于http2的。
envoy在做技术选型的时候它有非常完整的支持，无论是upstream还是downstream，两个方向都基于http2，但是nginx是单方向的。
处理优雅终止：当你的一个应用，它接收到一些请求的时候，我们要让这个进程重启或者停止，在那一刻往往都有一些发送到服务器上面但是还没有处理完的请求，之所以要优雅终止就是要给到这些请求一些时间让他们处理完。然后再优雅退出，这样就不会让客户端感受到突然重启造成的一些error。
connection draining就是重新加载静态配置的时候，它老的进程不退出，新的进程谈过共享内存启动起来，然后将老的进程里面的socket copy到新的进程里面去。然后老的进程已经连接的connection它会继续的去处理，当所有的已连接的请求处理完成之后，它再将老的进程退出，然后平滑的过度到新的进程去。
这样在重启的过程当中，对于客户来说是没有感知到的，因为是平滑过渡去的，这个功能envoy支持的非常好。
上面就是envoy在能力层次上面有很强的优势。
Envoy的优势
性能：
在具备大量特性的同时，Envoy提供极高的吞吐量和低尾部延迟差异，而CPU和RAM消耗却相对较少。
envoy可以提供非常高的吞吐量，然后只贡献一点点延迟，对资源cpu 内存的开销相对比较少。
可扩展性：
Envoy在L4和L7都提供了丰富的可插拔过滤器能力，使用户可以轻松添加开源版本中没有的功能。
你可以写很多的插件。你可以通过c++ rust语言的代码去编写自己的插件，当任何数据包被envoy接受的时候，除了envoy内置的逻辑去处理这些数据包，你所编写的插件逻辑也可以对这些数据包进行一些额外的处理，这就使得envoy的能力变的非常的容易扩展，你可以在envoy原有逻辑的基础上加上自己对数据包的处理能力。
API可配置性：
·Envoy提供了一组可以通过控制平面服务实现的管理API。如果控制平面实现所有的API,则可以使用通用引导配置在整个基础架构上运行Envoy。所有进一步的配置更改通过管理服务器以无缝方式动态传送，因此Envoy从不需要重新启动。这使得Envoy成为通用数据平面，当它与一个足够复杂的控制平面相结合时，会极大的降低整体运维的复杂性。
在envoy出来之前，其他的代理软件都只支持静态文件的配置，让静态配置文件生效就需要重启进程。在以前低频率下这种模式是没有问题的，k8s是一个动态的环境，节点会失效，pod就会故障转移，ip就会变动。还有弹性使得pod实例的数量加加减减，这样就会去频繁的修改配置文件，那么基于静态重启进程生效那么你的应用进程会一直重启。
有没有更加优雅的方式？更加轻量级的方式，就是envoy提供的开创性的能力。就是API可配置，除了envoy可以读取本地的配置文件进行热重启，它还可以在基础配置文件里面配置，接受另外一个地址的管理，当要进行配置更新，配置加载的时候，那么我就去那个地址要一份配置清单。这样的话就可以在不重启进程的前提下静态的去远端的网络地址要一份配置清单，只要这个配置清单生成好了之后，推送到envoy这一侧，那么配置就会即使生效。
比如说有pod一直redy或者一直不redy，那么只需要在远端控制服务器里面把这个envoy配置进行一个动态的变更。这个动态的变更要推送到envoy这一侧，那么envoy这边就可以及时生效了。
