使用Kong Ingress Controller实现粘性会话的不一致问题排查

核心问题是Upstream粘性会话Cookie与session插件Cookie重名，导致首次请求后生成的粘性标识被覆盖，第二次请求无法匹配首次路由的后端Pod。

流程拆解：

• 首次请求：Kong Upstream先按负载策略选中后端Pod，生成my-test-cookie（含后端标识）返回；随后session插件执行，生成同名Cookie覆盖了这个粘性标识。
• 第二次请求：客户端携带的是session插件生成的Cookie，Upstream用该值哈希后匹配到新的后端Pod。
• 第三次及以后：session插件的Cookie不再变化，哈希结果稳定，因此保持粘性。

1. 分离两种用途的Cookie名称 #

给Upstream粘性和session插件配置不同的Cookie名称，避免冲突：

修改Upstream配置（stickiness-upstream） #

apiVersion: configuration.konghq.com/v1
kind: KongIngress
metadata:
  name: stickiness-upstream
upstream:
  hash_on: cookie
  hash_on_cookie: kong-sticky-cookie  # 改为粘性专用Cookie名
  hash_on_cookie_path: /

修改session插件配置（session-plugin） #

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: session-plugin
config:
  cookie_path: /
  cookie_name: kong-session-cookie  # 保留会话专用Cookie名
  storage: cookie
  cookie_secure: false
  cookie_httponly: false
  cookie_samesite: None
plugin: session

2. 关闭Kubernetes Service的ClientIP粘性 #

你的Service配置了sessionAffinity: ClientIP，这是Kubernetes层面的粘性，会和Kong的粘性逻辑叠加冲突，建议关闭：

修改httpserver-service-cip的Service配置：

spec:
  sessionAffinity: None  # 替换原ClientIP配置

3. 验证配置生效 #

1. 应用修改后的配置：

   kubectl apply -f updated-upstream.yaml
   kubectl apply -f updated-session-plugin.yaml
   kubectl apply -f updated-service.yaml
   

2. 重启Kong Ingress Controller Pod确保配置加载：

   kubectl rollout restart deployment kong -n kong
   

3. 发起首次请求，检查响应头是否包含两个独立的Cookie；携带Cookie发起二次请求，验证是否路由到首次的后端Pod。

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