Networking Kubernetes节点端口并发连接限制

我在用AWS EKS运行Kubernetes。我正在为一个nodeport服务执行一些负载测试，并看到当命中pod未运行的节点时，并发连接限制为~16k-20k。我想知道是否有办法增加并发连接的数量

因此，我正在运行一个节点端口服务，其中只有一个pod计划在节点a上运行。我正在运行的负载测试尝试连接尽可能多的并发websocket连接。WebSocket只需睡眠，每30秒发送一次心跳，以保持连接的活力

当我将load tester（tsung）指向节点A时，我可以在pod被oomkille之前获得超过65k个并发WebSocket，所以内存是限制因素，这很好。真正的问题是，当我将负载测试仪指向节点B，kube proxy的iptables将连接转发到节点A时，突然之间，在连接开始停止之前，我只能获得大约16k-20k个并发websocket连接。据netstat称，他们正陷入

SYN_SENT

状态

netstat -ant | awk '{print $6}' | sort | uniq -c | sort -n
...
20087 ESTABLISHED
30969 SYN_SENT

我能想到的唯一一件事就是检查我的conntrack限制，它看起来很好。这是节点B的结果

net.netfilter.nf_conntrack_buckets = 16384
net.netfilter.nf_conntrack_max = 131072
net.nf_conntrack_max = 131072 

这是港口范围。我不确定这是否重要（我不确定DNAT和SNAT是否使用了端口），但范围似乎远高于16k

net.ipv4.ip_local_port_range = 32768    60999

节点A和节点B的文件描述符限制和内核TCP设置是相同的，因此我认为这排除了它们

---

是否有任何其他因素会限制通过iptables/netfilter转发的并发连接数？

当点击pod未运行的节点端口时，性能总是会变得更差。本质上，您的数据包正在经历额外的跳跃，试图（通过iptables）到达其最终目的地

我建议您使用。基本上，使用以下内容修补您的服务：

$ kubectl patch svc <your-service> -p '{"spec":{"externalTrafficPolicy":"Local"}}'

$kubectl patch svc-p'{“spec”：{“externalTrafficPolicy”：“Local”}'

然后让您的负载平衡器只将流量转发到为流量服务的节点报告

---

P>可选的，如果你想考虑一些更好的表现，你可以考虑使用代理模式或类似的覆盖方式。

谢谢你的建议Rico！我当然可以理解为什么像您所描述的那样通过nodeport会有更高的延迟，但是我不明白为什么它会减少并发连接的数量。您知道为什么会发生这种情况吗？同样，您的集群中的节点中会发生更多连接，从没有运行pod的节点到正在运行pod的节点。