莫名2020-12-25netif_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的处理带来的开销要更明显一些。
共 3 条评论9
小Y2022-03-13晕，我有个问题。 我发现 我只有一台物理/云机器，我在其上启动了netserver，然后启动了测试容器lat-test-1。使用netperf，我在容器中请求机器ip测试和 在 机器上请求自己IP测试，情况 后者的延时反而更大了。。。 这是为什么呢？作者回复: 这个可以从几个方面考虑，收发进程都在同一个节点，网络走的是loopback device了，进程调度的影响可能会更大一点，这个节点的处理器个数，其他相关的进程，甚至云机器的HV的load都有可能有影响。
共 3 条评论
豆豆2020-12-23思考题，因为他们使用不同的网络名称空间，MACVLAN 会走单独的协议栈，iptables 规则是在主机的网络名称空间，所以不会生效的，除非单独给容器的网络名称空间配置iptables 规则共 1 条评论14
swordholder2022-01-07Kubernetes的service是通过在iptables中设置DNAT规则实现的，而 DNAT 规则是在 PREROUTING 检查点，也就是在路由之前。 而ipvlan/macvlan 网络接口直接挂载在物理网络接口上，发送函数会直接找到虚拟接口对应的物理网络接口，不会再经过iptables的DNAT 规则。7
morse2021-01-07Kubernetes 的 service 是靠 Kube-proxy实现, L2模式下, 出入流量不会经过 host namespace, 那么kube-proxy就无法工作. L3模式下, 单入方向不经过 host namespace. 无法支持Kube-proxy.共 1 条评论7
谢哈哈2020-12-23在iptables标记包之前就被宿主机上的路由层面给处理完了，在mangle表和nat表的PREROUTING 和POSTROUTING链上的规则就匹配不到了共 2 条评论5
黑鹰2023-02-20 来自北京Kubernetes 中的 Service 是通过 kube-proxy 为 Service 配置的 iptables dnat 转发规则，对后端的 Pod 做负载均衡。ipvlan/macvlan 的网络接口和容器不在同一个 namespace，无法为容器配置转发到 ipvlan/macvlan 设备的 iptables 规则。
JianXu2022-08-15 来自上海不能使用service 不是使得Kubernetes 很受限制了吗？有什么两全其美的办法吗？
顾骨2022-03-30老师，请教一个问题，配置IPVLAN后，宿主机和容器网络貌似是不通的，这个怎么打通宿主机和容器的网络呢共 2 条评论