-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
使用edgemesh造成巨大时延增加 #551
Comments
因为edgemesh目前会把数据包转到用户态处理一下,再发送出去,会引入时延。局域网内的时应该不至于大于跨局域网,可以排查一下每段网络的网络质量 |
@571072717 请问是使用了Edgemesh的CNI功能吗? |
你指的是v1.15版本后引入的edgeCNI模块么,上述案例中使用v1.14版本,并没有开启该模块。 |
这个图片报错应该是缺少了roleBinding之类的配置,后续会优化一下。 |
我使用iperf测试局域网和跨局域网的网络带宽,都在100Mbit/s。另外我在逻辑下也运行过程序,传输4MB的时间接近使用k8s和kube-flannel的40ms,裸机情况下会略好一些。 在整理实验数据时,我有两点搞不懂。(1)使用高可用性的中转节点,如何保证局域网内的流量不经过中转节点。(2)edgemesh-agent是否存在性能瓶颈,以至于无法完全利用宿主机的网络带宽。 |
我看官方文档中的使用文件还是配合v1.14版本的,请问该配置具体怎么设置呢?是修改05-daemonset.yaml文件么 |
|
cc @IdeaMeshDyx |
这个所谓的参数错误显示是错误参数“1”,会不会是需要改成“!”。另外这条指令的具体作用是什么?会不会影响到整个CNI组件的正常工作。 |
延迟的问题应该和 CNI 架构没有关系,即便启用在速度上也不会有提升,因为 CNI 依旧使用的是相同的中继手段。 CNI 组件没有启用成功的问题应该是 rolebingding 设置不对 |
这个 1 参数指的是新规则应被插入到链中的第一条位置,目的是将符合跨网段的流量在其他策略生效前就拦截到,因为此前测试中存在一个问题是在iproute拦截到 tun 之前,部分其他 cni 插入的规则在 ip tables (如果是跨网段流量)对这些数据做了 snat ,导致其源地址变成了节点地址而不是容器地址,这个情况并不符合我们设计的中继流程,所以添加了这一块代码让其他 cni 不对跨网段的流量做 snat,因为 edgemesh 会给他们提供服务。 出现报错应该是目标网络地址、子网掩码、下一跳地址或出接口等参数格式不正确,或者是接口不存在等,具体您可以直接找我看看@[email protected],这部分部署优化会在之后推进。 您测试出现的问题,即局域网内直接通信时间较长,且超过跨网段的情况,并不符合我们测试部署的表现,能否具体说明您的测试场景和部署情况呢?比如这个实验测试的时延是两台机器中启动两个容器内使用 iperf 一类工具吗?具体网络环境在每一段的连接是什么样的呢?
|
实验情况:
实验一
我在云集群里的两台机器测试网络传输时间,两台机器分别为master和edge-1,它们之间的网络带宽是1000Mbit/s。
实验1.1 我在两台机器上分别安装k8s和kube-flannel,传输4MB的数据,计算得出的平均时间是40ms。
实验1.2 我在两台机器上分别安装KubeEdge和edgemesh,传输4MB的数据,计算得出的平均时间是321ms。
为什么使用edgemesh导致时延大大增加。
实验二
我在云集群的两台机器和集群外的一台机器,总共三台机器测试网络传输时间,三台机器分别为master、edge-1、edge-2。master和edge-1之间的网络带宽是100Mbit/s,在同一局域网内; master和edge-2之间的网络带宽是100Mbit/s,不在同一局域网内。
实验2.1 master和edge-1上分别安装KubeEdge和edgemesh,传输4MB的数据,计算得出的平均时间是815ms。
实验2.2 master和edge-2上分别安装KubeEdge和edgemesh,传输4MB的数据,计算得出的平均时间是467ms。
为什么局域网内的时延还大于跨局域网的时延。
预期结果:
1.时延的增加不应该如此明显
2.局域网内直接通信,效果应该优于跨局域网
Environment:
kubectl version
): v1.23.17cloudcore --version
andedgecore --version
): v1.14The text was updated successfully, but these errors were encountered: