我正在使用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之类的叠加层。