问题标签 [session-affinity]

我有 2 项服务：

1. 带有 Nginx 的 Restful/websocket API 服务（2 个副本）

2. 守护程序服务（1 个副本）

守护程序服务将在某个时候向前端发出 websocket 事件。但是，该事件似乎没有从守护程序服务成功发送到前端。

我还尝试将事件从 API 服务器发送到前端，并且事件已成功发送到前端。（可能是因为前端连接到 API WebSocket 服务器）。

我为粘性会话做了什么：

这是我的问题：我在 kubernetes yaml 文件中定义了 3 个服务：

• 一个前端（网站）
• 一个后端：有状态的，用于用户会话
• 一个后端：无状态

我需要有状态服务的会话亲和性，但不需要无状态服务或前端服务。我需要会话亲和性是基于 cookie 的，而不是基于 clientIP 的。

我尝试使用 Ingress 服务，但看不到如何在 Kubernetes 集群内的 2 个服务之间使用它作为代理。我看到的所有示例都展示了如何使用 Ingress 作为来自集群外部的请求的路由器。

到目前为止，这是我的 poc.yaml：

你知道如何解决我的问题吗？

谢谢！

OpenShift 容器平台 3.11

假设在同一个命名空间中有一个客户端 pod 和三个相等的服务器 pod。服务器 pod 可通过服务获得：

sessionAffinity: ClientIP声明只要客户端具有相同的 IP，它的请求就会被转发到同一个服务器 pod（达到 timeoutSeconds 时除外）。这个设置按预期工作了几个月，直到突然请求在两个服务器 pod 之间分发。重新启动客户端 pod 暂时解决了问题，请求仅在一段时间内转发到一个服务器 pod。然而，几天后，同样的问题再次出现。

我的问题：有什么关于 OpenShift 服务sessionAffinity: ClientIP的吗？这解释了为什么来自具有未更改 IP 的同一客户端的请求可能“突然”分布在两个服务器 pod 之间？

一些额外的上下文：

客户端 pod 在连接到服务器 pod 时会收到一个会话令牌（不是 cookie）。会话令牌缓存在服务器 pod 内，但不在服务器 pod 之间共享。因此，当客户端连接到不同的服务器时，它会收到拒绝会话令牌的权限。然后客户端请求一个新的会话令牌。如果客户端的请求被转发到同一个服务器 pod 并且只是有时服务器发生变化（例如，因为第一台服务器崩溃），上述设置工作正常。但是，如果客户端的请求分布在两个或多个服务器之间，则会话令牌将在每第二个或第三个请求时失效。

将我们的 Azure AKS - Kubernetes 环境升级到 Kubernetes 版本 1.19.3 迫使我也将我的 Nginx helm.sh/chart 升级到 nginx-ingress-0.7.1。结果，我被迫将 API 版本定义更改为 networking.k8s.io/v1，因为我的 DevOps 管道相应地失败了（旧 API 的警告导致错误）。但是，现在我的问题是我的会话亲和性注释被忽略并且响应中没有设置会话 cookie。

我拼命地改名字，尝试不同的不相关的博客文章以某种方式解决这个问题。

任何帮助将非常感激。

我当前的 nginx yaml（我已删除状态/托管字段标签以增强可读性）：

我的服务名称“帐户”的入口配置：

我的帐户服务 yaml

在我的无头服务中，我配置 sessionAffinity 以便每次都将来自特定客户端的连接传递到同一个 Pod ，如此处所述

这是清单：

我运行一些 nginx pod 进行测试：

问题是当我卷曲我的服务时，我被重定向到不同的 pod 并且 sessionAffinity 似乎被忽略了。

注意。当我检查时

SessionAffinity配置存在。

请注意，我的服务是无头的，即clusterIP: None。SessionAffinity 似乎适用于非无头服务。但是，我在文档中找不到明确的解释。这与平台不做任何代理有关吗？

阿卜杜勒加尼

我们正在尝试将 Azure Front Door 配置为在托管在两个不同存储帐户上的两个相同静态网站之间路由流量。已在 Front Door 中设置了一个后端池，其中包含 2 个后端主机名（指向存储帐户的链接）。仅启用一个后端主机后，通过 Front Door URL 访问网站就可以正常工作。但是，我们需要同时启用它们以启用负载平衡以及蓝/绿部署。

网站的加载方式是初始请求获取 index.html 文件。index.html 文件引用了大约。20 个 .js 文件。然后它尝试通过前门的 20 个新请求来检索所有这些 .js 文件。如前所述，这在仅启用一个受支持的主机的情况下工作得非常好。但是，当它们都启用时，一些加载 .js 文件的请求被路由到存储帐户 1，而一些被路由到存储帐户 2，这导致其中一些返回 404，未找到。Web 应用程序是基于反应的，因此构建时生成的脚本对文件名进行了哈希处理，这意味着两个存储帐户上的文件名不同，这解释了 404。

我怎么看，这个问题有两种解决方案：

1. 我们可以强制响应以相同的方式命名构建文件吗？如果是这样，那么所有请求都通过前门路由并不重要。
2. 我们能否配置前门以确保加载脚本的所有请求都路由到与加载 index.html 的初始请求相同的后端主机？我们已尝试启用未按预期工作的会话关联。

非常感谢！

我已将 NGINX 配置为反向代理，并为具有多个副本的后端 Web 应用程序启用了 Web 套接字。来自 NGINX 的请求proxy_pass对 Kubernetes 服务执行一个请求，该服务反过来将请求负载平衡到映射到该服务的端点。我需要确保来自特定客户端的请求在该访问的生命周期内被代理到同一个 Kubernetes 后端 pod，基本上保持会话持久性。

尝试sessionAffinity: ClientIP在 Kubernetes 服务中设置，但是这会根据 NGINX 代理的客户端 IP 进行路由。有没有办法让 Kubernetes 服务根据请求发起的实际客户端 IP 而不是 NGINX 内部 pod IP 进行关联？

我需要有人解释如何让 socketIO 客户端与部署到 Google Cloud App Engine 的 nodeJs 应用程序成功连接。

我设置了 nodejs 集群，因此不得不使用 socketIO 的 redis 适配器来管理会话亲和性。

在我部署到 Gcloud App Engine 之前，这一直运行良好。

这是我当前在服务器端的 socketIO 实现：

我对 gcloud 很陌生，所以我将非常感谢我能得到的任何帮助。我已尝试撤消 nodejs 集群，但仍然无法正常工作。

我在以下架构中使用 GCP：

1. TCP 平衡器 -> 后端服务 -> 具有自动缩放功能的 MIG（我的应用程序）。

“我的应用程序”在 TCP 端口 (A) 上接受命令，并在另一个 TCP 端口 (B) 上为订阅者发送通知。

我正在针对 TCP LB 的 IP 运行我的测试——我的测试在启动时连接到端口 B（即“我的应用程序”的实例之一），并且我的测试也为每个测试连接到端口 A。

即，当端口 A 和端口 B 被终止/连接到不同的主机时，我遇到了这种情况。

我不确定如何规避这种情况。

我们在我们的 kuberntes 集群中使用了一个 haproxy 入口，它具有 cookie 亲和性来处理粘性会话。

入口配置如下：

我们希望在每次请求/响应后延长cookie 的生命周期，但事实并非如此。在给定的 Max-Age 期间，我们只接收一次 cookie（对于第一个请求）。

这种行为可以改变吗？

作为一种解决方法，我们删除了 Max-Age 属性 - 现在 cookie 与客户端会话一样长（例如，浏览器实例处于活动状态）。但这可能会导致阻止重新部署/更新集群中的 Pod，因为我们还使用了排水支持功能（如果客户端会话仍然处于活动状态，活动客户端可以再次到达同一个 Pod）。