根本原因是 CNI 插件和内核网络栈叠加多层缓冲与拷贝，导致容器内 net.Conn 吞吐受限；需调优 sysctl 参数、关闭 conntrack、优化 http.Transport 及选用 eBPF 模式 CNI。
为什么 net.Conn 在容器里吞吐上不去
不是 Go 代码写得慢，是 CNI 插件和内核网络栈叠加了多层缓冲与拷贝。典型表现是：宿主机直连能跑满带宽，Pod 里用 http.Client 或 net.Dial 却卡在 1–3 Gbps（即使网卡是 10G）。根本原因是 CNI（如 Calico、Cilium）默认启用 conntrack + iptables 规则，每个连接都要过 netfilter，且 socket buffer 默认值在容器 namespace 里没调优。
-
net.core.rmem_max和net.core.wmem_max在容器内仍沿用宿主机默认值（通常 212992 字节），远低于高吞吐所需（建议 ≥ 4M） - CNI 的
host-localIPAM +portmap插件会强制开启nf_conntrack，导致短连接建连延迟升高 3–8ms - Go 的
http.Transport默认MaxIdleConnsPerHost = 2，在高并发 HTTP 场景下极易成为瓶颈
怎么调 sysctl 参数才生效于容器内
直接在 Pod 启动时改 /proc/sys/ 不可靠——容器重启就丢；用 initContainer 写 sysctl 又可能被 CNI 覆盖。真正稳的方式是让 CNI 插件本身加载 tuned 参数，或通过 securityContext.sysctls（仅限 whitelisted 参数）。
- 必须确认 kubelet 启动时加了
--allowed-unsafe-sysctls="net.core.rmem_max,net.core.wmem_max" - 在 Pod spec 中写：
securityContext: sysctls: - name: net.core.rmem_max value: "4194304" - name: net.core.wmem_max value: "4194304" - 若用 Cilium，优先关闭 conntrack：
endpoint-config --conntrack=false；Calico 则需禁用policy类型的 NetworkPolicy，否则仍走 iptables
http.Transport 和 net.Dialer 的关键参数怎么设
Go 默认的 dial 行为在容器网络里太保守：超时长、复用少、缓冲小。不改 transport，再大的带宽也喂不饱。
-
MaxIdleConnsPerHost至少设为100（HTTP/1.1）或1000（HTTP/2） -
IdleConnTimeout建议 ≤30s，避免连接池积压 stale 连接 - 显式指定
Dialer.KeepAlive（如30 * time.Second），防止中间 NAT 设备主动断连 - 绕过 DNS 缓存：用
Resolver配PreferGo: true，避免 cgo resolver 在容器里调getaddrinfo锁死
CNI 选型对 Go 应用性能的实际影响
不是所有 CNI 都一样。Cilium eBPF 模式可绕过 iptables 和 conntrack，实测比 Calico iptables 模式降低 40% RTT、提升 2.3× 吞吐；但若用 Cilium 的 legacy 模式（即 iptables backend），性能几乎无差别。
立即学习“go语言免费学习笔记（深入）”；
- 确认 Cilium 是否启用了 eBPF：
cilium status | grep "KubeProxyReplacement"，输出Strict或Partial才有效 - Calico 若必须用，关掉
FelixConfiguration.spec.conntrackZonePerEndpoint: true，减少 conntrack 条目爆炸 - 避免在生产环境混用 Flannel（host-gw 模式除外）+ NetworkPolicy，它根本不支持策略，靠 kube-proxy 补位，反而增加跳数
真正卡住性能的，往往不是 Go 的 runtime，而是你没意识到 CNI 给每个 net.Conn 默默加了一层 iptables + conntrack + socket buffer 限制。调参前先 ss -i 看 retrans、rcv_space、rto，比盲目改 GOMAXPROCS 有用得多。
