一、前言
本文针对我们生产上出现的流量不均的问题,介绍一下解决方案。
k8s是一个特别复杂的系统,而网络相关的问题是其中最复杂的问题,要通过一两篇文章介绍清楚是很难的。这个流量不均的问题出现的原因并不复杂,就是因为kube-proxy使用了默认的iptables做负载均衡,而它是以概率的方式转发,使用长连接且连接数较少时,偏差会比较大。下面介绍两种场景。
二、场景
2.1滚动更新负载不均
在连接数比较固定或波动不大的情况下,滚动更新时,旧 Pod 上的连接逐渐断掉,重连到新启动的 Pod 上,越先启动的 Pod 所接收到的连接数越多,造成负载不均:
2.2rr 策略负载不均
假如长连接服务的不同连接的保持时长差异很大,而 ipvs 转发时默认是 rr 策略转发,如果某些后端 Pod "运气较差",它们上面的连接保持时间比较较长,而由于是 rr 转发,它们身上累计的连接数就可能较多,节点上通过 ipvsadm -Ln -t CLUSTER-IP:PORT 查看某个 service 的转发情况:
我们发现部分 Pod 连接数高,它们相比连接数低的 Pod 要同时处理更多的连接,消耗的资源也就相对更多从而造成负载不均。
将 kube-proxy 的 ipvs 转发模式设置为 lc (Least-Connection) ,即倾向转发给连接数少的 Pod,可能会有所缓解,但也不一定,因为 ipvs 的负载均衡状态是分散在各个节点的,并没有收敛到一个地方,也就无法在全局层面感知哪个 Pod 上的连接数少,并不能真正做到 lc。可以尝试设置为 sh (Source Hashing),并且这样可以保证即便负载均衡状态没有收敛到同一个地方,也能在全局尽量保持负载均衡。
这边很多对kupe-proxy的ipvs模式可能不太了解,ipvs和iptables都是基于netfilter的,两者差别如下:
ipvs 为大型集群提供了更好的可扩展性和性能
ipvs 支持比 iptables 更复杂的负载均衡算法(最小负载、最少连接、加权等等)
ipvs 支持服务器健康检查和连接重试等功能
2.3、扩容失效问题 在连接数比较固定或波动不大的情况下,工作负载在 HPA 自动扩容时,由于是长链接,连接数又比较固定,所有连接都 "固化" 在之前的 Pod 上,新扩出的 Pod 几乎没有连接,造成之前的 Pod 高负载,而扩出来的 Pod 又无法分担压力,导致扩容失效:
三、最佳实践
业务层面自动重连,避免连接 "固化" 到某个后端 Pod 上。比如周期性定时重连,或者一个连接中处理的请求数达到阈值后自动重连。
不直接请求后端,通过七层代理访问。比如 gRPC 协议,可以 使用 nginx ingress 转发 gRPC,也可以 使用 istio 转发 gRPC,这样对于 gRPC 这样多个请求复用同一个长连接的场景,经过七层代理后,可以自动拆分请求,在请求级别负载均衡。
kube-proxy 的 ipvs 转发策略设置为 sh (--ipvs-scheduler=sh)。
编辑:黄飞
-
负载均衡
+关注
关注
0文章
111浏览量
12365
原文标题:K8S之长连接负载均衡问题
文章出处:【微信号:magedu-Linux,微信公众号:马哥Linux运维】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论