@WithLin 原因比较多，比如 Cilium 功能太多，而大部分功能在内网是不需要的，比如 NetworkPolicy 、非 VxLAN 隧道支持
Cilium 为了适配各种场景、各种 kernel 版本，使得它的复杂度很高，而我们的场景要小很多；同时还有一些场景是 Cilium 不支持的，比如多个物理网卡
一些额外的功能，比如 Pod 内多网卡，社区方案只能用 multus ，而 multus 需要通过 crd 来存储数据；历史原因 Pod 的 IP 需要 BGP 发布到 Underlay ，所以需要额外的 IPAM
Cilium 能支持的规模也太小，因为大量使用了 apiserver 的 api ，基本上集群规模到 2k 左右就到头了；同理太多的功能判断也导致数据面的性能没有做到最好

维护 Cilium 的难度不亚于参考 Cilium 的方案重写一个，大部分思想还是从 Cilium 来的，只是代码是重写的，以及抄了 Cilium 部分 ebpf 片段。

比上不足比下有余
有一二线互联网公司的 offer ，就别去 od
如果没有，就去 od

把其中一个节点网卡的 MTU 改到 1300 ，再试试

建议考虑其他城市 or 国家，成都互联网氛围卷且没钱

和连接无关，不是基于连接的限速，速度怎么分是你本地的 tcp 拥塞控制算法计算的发包速度和丢包重传速度

vf+rep 在不配置任何规则的情况下，用起来和 veth 一模一样，只是带方向，vf 是实体 pci 设备，可以 passthough 给 vm ，rep 是一个虚拟接口，用来处理卡上 flow miss 的报文。简单点就是 switchdev+ovs ，最新的 ovs 已经支持 flower offload ，只要不开 conntrack offload 就没啥问题

virtio 是半虚拟化，需要有 backend 的啊，host 上 CPU 那么高的 vhost-net 就是开销。
如果你真的想玩 sriov 的话，你可以买一张二手的 mellanox cx5 ，sriov 模式分 legacy （就是你目前用的这种方式），还有一种是 switchdev ，开启 switchdev 之后，每个 VF 会出现 VF+Rep 两个接口，同时在这个模式下，可以打开 hw-tc-offload ，配置 tc flower 可以直接下发到网卡，你就可以通过 tc flower 配置卡上 e-switch 去转发报文了。
此外，sriov 最重要的意义是 pci passthough ，消除了 vhost 的开销。

不过你这个环境的网络 IO 有这么高吗？

@alswl 我主要是开发 CNI ，看了一下 kind 的 node 是运行在 container 里面，好像。。。用不起来

@XTTX 自己搭个测试环境看 kubeadm 的教程就行，在 ubuntu 或 debian 最新版本上，敲下面的命令就拉起 master 了

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

kubeadm init --service-cidr 192.168.0.0/24 --pod-network-cidr 172.16.0.0/12 --cri-socket /run/containerd/containerd.sock --ignore-preflight-errors=FileContent--proc-sys-net-bridge-bridge-nf-call-iptables

信息太少，和你的路由表、iptables 都有关，贴出
ip route
iptables-save
ipvsadm-save
ip rule （如果有策略路由还需要 ip route show table xxxx 给每个 table)

看你截图，估计是只做了 DNAT （这是正常的）但是没有做 SNAT ，到 Pod 里面去之后，Pod 回包回不回来，到 Pod 里面去 tcpdump -vv -n -i any tcp port 8086 看看不同情况下源 IP 的差异

而且你们这个场景，又要 EIP 又要 NAT 又要 VPC ，就是一个标准的 SDN 网络，用才云的 VCI （ kata+sdn+胶水 cni ）就能满足你们大部分需求，再做一点定制开发

@hdhuang 北上广深。。。我大概知道你是哪个团队了，为啥不找网络组(ll 的团队）给你们定制 CNI 呢

@hdhuang 你司叫什么名字

@pydiff CNI 还有商业方案吗？你说的我想把现在的方案 toB 了

@fighterhit cri 只是一层皮，直接用 containerd 的 client 连上去，你想要什么数据都有

crictl inspect xxxxx

2000 节点内开源方案都可以满足，有什么特别的原因需要自己开发 CNI ？

好家伙