![具有粘性会话的 kubernetes 负载均衡器始终将流量发送到一个 pod](https://linux22.com/image/719018/%E5%85%B7%E6%9C%89%E7%B2%98%E6%80%A7%E4%BC%9A%E8%AF%9D%E7%9A%84%20kubernetes%20%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E5%99%A8%E5%A7%8B%E7%BB%88%E5%B0%86%E6%B5%81%E9%87%8F%E5%8F%91%E9%80%81%E5%88%B0%E4%B8%80%E4%B8%AA%20pod.png)
我的负载均衡器设置有问题,它总是将大多数流量(例如 99%)重定向到一个 pod。基本上基础设施如下图所示在此图上目标是我需要启用粘性会话,无论是在 nginx 还是 Google 负载均衡器上,并且我的流量均匀地分配给可用的 pod。
简单来说,我的集群中有 2 个 RC 和 2 个服务。1 个 nginx pod 在 Google 负载均衡器 (nginx-lb) 后面提供服务,另一个负载均衡器 (app-lb) 则用于将流量平衡到 2 个应用程序 pod。以下是我对配置的看法:
nginx-lb:我将 nginx-lb 设置为
sessionAffinity: None
,externalTrafficPolicy: Local
因为我认为我现在不需要粘性会话,但我确实需要通过用户IP。此时所有传入流量将被相同处理,但我们尝试通过设置来保留用户的 IPexternalTrafficPolicy: Local
。nginx:nginx 本身已启用ngx_http_realip_module保持用户 IP 转发,但我在这里没有使用 ip_hash,因为我仍然认为我们这里还不需要粘性会话。同样,就像 nginx-lb 一样,我试图传递所有传入流量但保留用户的 IP。这里的 nginx 主要用于代理和 SSL 处理程序。
app-lb:然后进入 app-lb,我在其中启用了
sessionAffinity: ClientIP
粘性会话externalTrafficPolicy: Cluster
和负载均衡我相信这就是 ClientIP 实际发生负载平衡的地方,因为这是唯一拥有/知道其后面有 2 个 pod 的服务。
我测试了这个配置,大约有 50 个用户运行了一天,但仍然重定向到一个 pod,而另一个 pod 处于空闲状态,与第一个 pod 相比,CPU 和内存使用率较低。
我想问一下,设置是否正确,是否达到了我想要的效果?我是否缺少配置?任何意见都将不胜感激。
PS. 我重写了整个问题,根据我的理解添加了更多事实,但基本上仍然与原始问题相关,只是措辞有所不同。
答案1
发生这种情况是因为您正在使用sessionAffinity: ClientIP
,这是服务上的亲和力并且基于 ip,因此服务获取您的负载均衡器的 ip,尝试使用sessionAffinity: None
,如果您想使用粘性会话,请使用 nginx 入口控制器
答案2
您是否尝试过使用比手机和笔记本电脑更多的客户端来测试您的应用?
也许您可以从多个 Google 计算引擎实例中进行测试。
由于您同时实现了粘性会话和负载平衡,因此ip_hash
有 50% 的机会两个设备由同一个 pod 提供服务,即使您重新加载页面,它也始终由同一个 pod 提供服务,直到您更改 IP。
使用 ip-hash 时,客户端的 IP 地址将用作哈希密钥,以确定应选择服务器组中的哪个服务器来处理客户端的请求。此方法可确保来自同一客户端的请求始终定向到同一服务器,除非该服务器不可用。 http://nginx.org/en/docs/http/load_balancing.html