@kera0a 看来这照片铁假了

连接数，实际上这个值采集的是 conntrack 的值
conntrack -L | wc -l
没经过 conntrack 的连接，是统计不出来的，比如在 filter 表把局域网连接 NOTRACK 了，那局域网的连接不会被统计到里面

@WithLin 多网卡的场景非常小，目前只有 RDMA 场景需要按 GPU 的 NUMA 数量分配 VF 的场景有。IPAM 就是一个中心化 IPAM

你填了是你填了，运营商认不认那就是另外一会事了。
不过内网 TOS 还是可以用的，一般都是和物理网络约定几个值就行。典型就是 RoCE 使用一个 dscp ，全网都配置这个 dscp 为最高优先级，来实现无损网络。

随便列一下，

网关的问题：
1. 网关出 Bug 、被打爆 所有服务全无
2. 网关在逻辑增加了一跳路径，降低稳定性
3. 网关不是单纯的网关，如果是 DNS+VIP 的方式访问网关，那在网络层也需要 L4 接入，L4LB 是 ecmp 发布的路由，扩缩容时会损失部分连接（除非做了 session 同步，这个坑更多），所以在物理层面实际上增加了两跳
4. 为了避免 3 中 L4LB 带来的缺陷，需要采用服务发现去发现网关实例，那为啥不直接发现下游实例呢？

优势：
1. 服务治理（含风控等所有通用功能）好做，功能迭代在网关上

综上：
1. 入口服务使用网关做接入，内部 RPC 调用上 ServiceMesh

@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 你司叫什么名字