AKS集群Camunda Cockpit登录及粘性会话对Pod扩缩容影响咨询

核心问题解答 #

1. 启用粘性会话会不会丧失Pod扩缩容的优势？ #

不会完全丢掉扩缩容的优势，但确实有一些限制：

• 扩缩容的核心作用仍在：流量上涨时，新扩容的Pod会承接所有没有对应粘性Cookie的新请求（比如新用户、新客户端），能正常分担负载；缩容时，Ingress会把被销毁Pod的后续请求（只要Cookie还在有效期内）重新路由到存活的Pod，不会直接导致请求失败。
• 存在的小限制：已经带有粘性Cookie的用户请求会固定到某一个Pod，如果这个Pod负载偏高，Ingress不会主动把这些请求调度到其他空闲Pod，可能出现局部负载不均的情况。不过Camunda Cockpit的用户请求都是交互式操作，单用户请求量不大，这种负载不均的影响几乎可以忽略。

2. 微服务A对Camunda的所有请求都会被路由至同一Pod吗？ #

这要看微服务A的请求是否携带Ingress设置的粘性Cookie：

• 如果微服务A会保留并复用请求返回的Cookie（比如客户端维护了Cookie池、每次请求都带上之前拿到的Cookie），那所有请求都会被路由到同一个Pod；
• 如果微服务A的请求不带Cookie（比如每次都是无状态的新请求，没保存Ingress返回的粘性Cookie），Ingress会按照默认的负载均衡策略（比如轮询）把请求分发到不同Pod。

对于调用fetchAndLock API的微服务，建议让它不要携带粘性Cookie，这样能让Camunda的任务分配更均衡，充分利用多Pod的资源。你可以配置Ingress的粘性会话规则，只给Camunda Cockpit的路径（比如/camunda/app/cockpit/*）开启粘性，API路径（比如/engine-rest/*）保持无状态负载均衡——这样既能解决Cockpit的登录问题，又不影响API请求的负载均衡效果。

额外实用建议 #

• 精准匹配路径：只给Cockpit、Tasklist这类需要会话保持的UI路径开启粘性，API路径维持无状态负载，兼顾登录体验和集群资源利用率。
• 设置合理的Cookie有效期：别设太长，避免Pod长期负载不均，建议设为用户正常操作的会话时长（比如1-2小时）。

内容的提问来源于stack exchange，提问作者giosefer