17｜容器网络配置（2）：容器网络延时要比宿主机上的高吗?
李程远
该思维导图由 AI 生成，仅供参考
你好，我是程远。
在上一讲里，我们学习了在容器中的网络接口配置，重点讲解的是 veth 的接口配置方式，这也是绝大部分容器用的缺省的网络配置方式。
不过呢，从 veth 的这种网络接口配置上看，一个数据包要从容器里发送到宿主机外，需要先从容器里的 eth0 (veth_container) 把包发送到宿主机上 veth_host，然后再在宿主机上通过 nat 或者路由的方式，经过宿主机上的 eth0 向外发送。
这种容器向外发送数据包的路径，相比宿主机上直接向外发送数据包的路径，很明显要多了一次接口层的发送和接收。尽管 veth 是虚拟网络接口，在软件上还是会增加一些开销。
如果我们的应用程序对网络性能有很高的要求，特别是之前运行在物理机器上，现在迁移到容器上的，如果网络配置采用 veth 方式，就会出现网络延时增加的现象。
那今天我们就来聊一聊，容器网络接口对于容器中应用程序网络延时有怎样的影响，还有这个问题应该怎么解决。
问题重现
这里我们需要两台虚拟机或者物理机，这两台机器需要同处于一个二层的网络中。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了容器网络延时问题，并提出了解决方案。通过分析veth网络接口配置方式，揭示了容器中网络延时增加的原因，并通过Netperf工具模拟测试得出容器网络延时明显高于宿主机的结论。进一步分析了veth接口配置的工作原理，指出数据包在容器中发送到宿主机外需要经过额外的接口层，导致网络延时增加。文章还提到了软中断的处理过程，解释了veth虚拟网络接口在数据包接收操作上与真实网络接口相似，从而带来了额外的开销。最后，文章呼吁对于对网络性能要求高的应用程序，特别是从物理机迁移到容器上的情况，应该避免采用veth方式的网络配置，以降低网络延时。此外，文章还介绍了使用ipvlan/macvlan的网络接口来替代veth网络接口，以减小容器网络延时的方法。总的来说，本文提供了清晰的技术分析和解决方案，对于容器网络延时问题有很好的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《容器实战高手课》，新⼈⾸单¥59
《容器实战高手课》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(9)
- 最新
- 精选
莫名netif_rx 通常在硬件中断处理逻辑中调用。loopback、veth 等设备驱动是特例，通过调用 netif_rx 模拟数据包的接收。 除了 softirq 的性能损坏，应该还包括 docker0 网桥的自身处理逻辑（作为 veth_container 的主设备接管其数据包的处理权）以及 docker0 -> eth0 的转发逻辑。 docker inspect 输出为 json 格式，推荐使用 jq 命令查看 Pid ，命令比较简洁，缺点是默认末安装： docker inspect lat-test-1 | jq .[0].State.Pid作者回复: @莫名， > 除了 softirq 的性能损坏，应该还包括 docker0 网桥的自身处理逻辑（作为 veth_container 的主设备接管其数据包的处理权）以及 docker0 -> eth0 的转发逻辑。 没错，Linux bridge以及docker0 -> eth0的L3层的操作也会带来额外的开销，不过相比较而言，veth pair softirq的处理带来的开销要更明显一些。
2020-12-2539
小Y晕，我有个问题。 我发现 我只有一台物理/云机器，我在其上启动了netserver，然后启动了测试容器lat-test-1。使用netperf，我在容器中请求机器ip测试和 在 机器上请求自己IP测试，情况 后者的延时反而更大了。。。 这是为什么呢？作者回复: 这个可以从几个方面考虑，收发进程都在同一个节点，网络走的是loopback device了，进程调度的影响可能会更大一点，这个节点的处理器个数，其他相关的进程，甚至云机器的HV的load都有可能有影响。
2022-03-133
豆豆思考题，因为他们使用不同的网络名称空间，MACVLAN 会走单独的协议栈，iptables 规则是在主机的网络名称空间，所以不会生效的，除非单独给容器的网络名称空间配置iptables 规则2020-12-23114
swordholderKubernetes的service是通过在iptables中设置DNAT规则实现的，而 DNAT 规则是在 PREROUTING 检查点，也就是在路由之前。 而ipvlan/macvlan 网络接口直接挂载在物理网络接口上，发送函数会直接找到虚拟接口对应的物理网络接口，不会再经过iptables的DNAT 规则。2022-01-078
morseKubernetes 的 service 是靠 Kube-proxy实现, L2模式下, 出入流量不会经过 host namespace, 那么kube-proxy就无法工作. L3模式下, 单入方向不经过 host namespace. 无法支持Kube-proxy.2021-01-0717
谢哈哈在iptables标记包之前就被宿主机上的路由层面给处理完了，在mangle表和nat表的PREROUTING 和POSTROUTING链上的规则就匹配不到了2020-12-2325
黑鹰Kubernetes 中的 Service 是通过 kube-proxy 为 Service 配置的 iptables dnat 转发规则，对后端的 Pod 做负载均衡。ipvlan/macvlan 的网络接口和容器不在同一个 namespace，无法为容器配置转发到 ipvlan/macvlan 设备的 iptables 规则。2023-02-20归属地：北京1
JianXu不能使用service 不是使得Kubernetes 很受限制了吗？有什么两全其美的办法吗？2022-08-15归属地：上海
顾骨老师，请教一个问题，配置IPVLAN后，宿主机和容器网络貌似是不通的，这个怎么打通宿主机和容器的网络呢2022-03-303
收起评论
