KubeEdge EdgeMesh设计原理
https://www.cnblogs.com/yrxing/p/14662704.html
EdgeMesh主要用来做边缘侧微服务的互访。
ServiceMesh
service mesh是一个服务网格的概念。在传统的架构里面都是通过像Dubbo来进行服务治理，服务治理的程序和我们应用程序强耦合在一起，对程序升级和运维带来很多麻烦。service mesh通过sidecar来使我们的治理能力独立，上图中绿色和蓝色是一个业务单元，绿色是我们的应用，蓝色是专门负责服务治理的程序，比如在Istio中就是envoy。应用的流量出来先导入envoy里面，在envoy里面可以配置服务访问的策略，就可以访问到对应的服务。
带来的好处就是应用程序无感知。
EdgeMesh
EdgeMesh架构
EdgeMesh在EdgeCore里面也是一个独立的Moudul，负责边缘侧流量的转发，已经把CNI的东西做好了，支持跨节点流量转发。APP的流量出来一个会导入到EdgeMesh里面，EdgeMesh里面有Listener负责监听；Resolver负责域名解析,它里面实现了一个DNS server；Dispatcher负责转发流量。RuleMgr作用是把endpoint、service、pod的信息通过MetaManager从数据库里取出来。
为什么域名解析会放到边缘？我们知道在原生k8s里面，域名解析是放在coreDNS活kubeDNS里面的做的，一般部署在master或一个单点生。这样会有一个问题：边缘和云的链接会经常断开，在这种情况下，域名解析服务就不能用了，因此需要把域名解析放到边缘，而不应该在master里面去解析，这时就需要把云上的service、endpoint、pod信息都同步到边缘。（后续会做一个优化，不获取全量信息，只把有效信息同步过来）
目前的设计主要致力于边和边的服务互访，云和边还有点问题，如果云和边要传一个数据还是推荐使用其他的数据通道。未来会做的工作是使用标准的istio进行服务治理控制，现在支持的是云上k8s的api，以后会考虑把istio集成进来，基于istio那一套规则来做。
目前边边的节点是在同一子网，本身就是互通的，未来考虑跨子网通信，可以通过cloudhub或者某一个中心点去转。（我们思路是通过在边缘动态配置一个envoy来统一接收需要代理的边缘节点服务的入口和出口流量，相当于把envoy配置成网关形式）
EdgeMesh原理
- edgemesh通过kubeedge边缘侧list-watch的能力，监听service、endpoints等元数据的增删改，再根据service、endpoints的信息创建iptables规则
- edgemesh使用域名的方式来访问服务，因为fakeIP不会暴露给用户。fakeIP可以理解为clusterIP，每个节点的fakeIp的CIDR都是9.251.0.0/16网段(service网络)
- 当client访问服务的请求到达节点后首先会进入内核的iptables
- edgemesh之前配置的iptables规则会将请求重定向，全部转发到edgemesh进程的40001端口里（数据包从内核台->用户态）
- 请求进入edgemesh程序后，由edgemesh程序完成后端pod的选择（负载均衡在这里发生），然后将请求发到这个pod所在的主机上
EdgeMesh转发流程
client pod是请求方，service pod是服务方。client pod里面有一个init container，类似于istio的init container。client先把流量打入到init container，init container这边会做一个流量劫持，它会把流量转到edge mesh里面去，edge mesh根据需要进行域名解析后转到对应节点的pod里面去。
这里有一个优化的点是：init container现在在每一个client pod里面都有一个，而它的功能作用在每一个pod里面都是一样的，后续会考虑把init container接耦出来。
EdgeMesh配置方式
当我们配置一个init container的时候，它就会拦截应用的请求数据，转发到EdgeMesh里面。
EdgeMesh用户价值
对于资源受限的边缘设备，提供了一个轻量化且具有高度集成的服务发现软件；
在现场边缘的场景下，相对于coredns+kube-proxy+cni这一套服务发现机制，我们只需要简单的部署一个edgemesh就能完成目标
本文作者：尹瑞星
本文链接：https://www.cnblogs.com/yrxing/p/14662704.html
版权声明：本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。
