我正在使用AWS EKS运行Kubernetes。我正在为nodeport服务执行一些负载测试，并在未运行Pod的节点上看到并发连接限制为〜16k-20k。我想知道是否有某种方法可以增加并发连接数。
因此，我运行的节点端口服务只有在节点A上安排的1个Pod。我正在运行的负载测试尝试连接尽可能多的并发Websocket连接。网络套接字只是睡觉，每30秒发送一次心跳以保持连接状态。
当我将负载测试器（tsung）指向节点A时，在Pod被OOM杀死之前，我可以获得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转发的并发连接的数量？
答案 0 :(得分：2)
在未运行Pod的NodePort上运行时，您总是会获得更差的性能。本质上，您的数据包会经过额外的跃点尝试（通过iptables）以获得其最终目的地。
我建议您为source IP服务使用NodePort。基本上，使用以下方法修补您的服务：
$ kubectl patch svc <your-service> -p '{"spec":{"externalTrafficPolicy":"Local"}}'
然后让您的负载平衡器仅将流量转发到正在提供流量的NodePort。
或者，如果您想考虑某些性能更好的东西，则可以考虑使用代理模式ipvs或BPF/Cillium之类的叠加层。