标签：KubeEdge EdgeMesh 域名解析 init container 原理 里面 pod

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转发流程

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里面。

标签：KubeEdge,EdgeMesh,域名解析,init,container,原理,里面,pod
来源： https://www.cnblogs.com/yrxing/p/14662704.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。