Kubernetes中Ingress与Service会话亲和性的差异及相关疑问

一、核心差异对比 #

你提到的实现层（Ingress vs Service）和实现方式（Cookie vs ClientIP）是核心区别，但还有以下关键差异：

• 作用范围不同：
  • Nginx Ingress的Cookie亲和性仅对通过Ingress访问的外部流量生效，集群内部Pod直接访问Service的流量不受其规则约束。
  • Service的ClientIP亲和性对所有访问该Service的流量生效，包括集群内Pod、外部通过NodePort/LoadBalancer的请求。
• 粒度与灵活性不同：
  • Ingress的Cookie亲和性支持精细配置：比如自定义Cookie名称、设置过期时间、失败时自动切换后端（如示例中的session-cookie-change-on-failure），适配复杂业务场景。
  • Service的ClientIP亲和性基于客户端IP段（默认单IP/32，可通过sessionAffinityConfig调整），配置选项少，粒度较粗。
• 代理场景适配差异：
  • 若客户端通过代理访问，Ingress的Cookie不受代理IP影响，只要客户端能保留Cookie，就能维持粘性；而Service的ClientIP会把代理IP识别为客户端IP，导致同一真实客户端的请求被分配到不同后端Pod。
• 失效逻辑不同：
  • Ingress的粘性依赖客户端保留Cookie，一旦Cookie被清除或过期，粘性立即失效。
  • Service的ClientIP粘性依赖kube-proxy的会话记录，默认3小时过期，只要客户端IP不变，粘性持续（除非后端Pod被移除）。

参考配置示例 #

Nginx Ingress会话亲和性配置

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/affinity: cookie
    nginx.ingress.kubernetes.io/affinity-mode: persistent
    nginx.ingress.kubernetes.io/session-cookie-change-on-failure: "true"
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
    nginx.ingress.kubernetes.io/session-cookie-name: STICKY_SESSION
    nginx.ingress.kubernetes.io/use-regex: "false"

Service ClientIP亲和性说明

sessionAffinity :
支持"ClientIP"和"None"，用于维持会话亲和性。启用基于客户端IP的会话亲和性，必须设置为ClientIP或None，默认值为None。

二、同时使用二者是否为不良实践？ #

是的，不建议同时启用两种会话亲和性，原因如下：

• 逻辑冗余与冲突：Nginx Ingress会直接解析Service的后端Endpoints并按Cookie规则转发请求，此时Service的ClientIP亲和性规则会被绕过，完全起不到作用；若Ingress通过Service ClusterIP转发，双重粘性会增加不必要的路由计算开销，甚至可能因规则不一致导致路由错误。
• 排查复杂度提升：出现流量分配异常时，需要同时排查Ingress和Service两层的粘性规则，增加问题定位难度。

三、集群内Pod间粘性会话：仅设置Service ClientIP是否足够？ #

仅设置service.spec.sessionAffinity: ClientIP无法完全确保后端Pod每次连接到同一个数据库Pod，原因如下：

• 后端Pod变动导致失效：当数据库Pod因故障重启、重建或被调度到其他节点时，Service会更新Endpoints列表，原有的ClientIP会话记录会失效，新请求会被分配到新的数据库Pod。
• 客户端PodIP变动：若发起请求的客户端Pod被重建或调度，其IP会发生变化，Service的ClientIP亲和性规则会重新匹配，导致请求分配到新的数据库Pod。
• 数据库会话本身的独立性：即使Service将请求固定到同一数据库Pod，若应用层未处理数据库会话的持久化（如使用连接池、会话绑定），每次请求仍可能创建新的数据库连接，无法保证会话一致性。

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