Kubernetes粘性会话配置位置：Service或Ingress/IngressController？

你最初认为粘性会话应当在Service层面配置的判断不完全错误——Service确实原生支持粘性会话能力，但这只是可选实现路径之一，在你使用AWS Load Balancer作为IngressController的场景下，Ingress层配置是更优选择。

粘性会话可在两个独立层级配置，两层逻辑互不干扰，不要同时开启避免冲突。

方案1：Service层配置（原生通用方案） #

Kubernetes Service资源原生支持基于源IP的会话亲和性，配置不依赖任何IngressController能力，所有集群环境通用。
配置示例：

apiVersion: v1
kind: Service
metadata:
  name: auth-service
spec:
  type: ClusterIP
  selector:
    app: auth-service
  ports:
    - port: 80
      targetPort: 8080
  # 开启基于源IP的会话粘性
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      # 粘性有效期，单位秒，默认10800秒（3小时），可按需调整
      timeoutSeconds: 10800

该方案的特点：

• 优势：配置极简，无组件依赖，所有标准K8s集群都支持
• 缺陷：仅能通过请求源IP做哈希匹配，粒度极粗——同一NAT出口下的所有用户（比如公司内网、同一区域运营商移动网络用户）会被路由到同一个Pod，极易出现负载倾斜；Pod重建、漂移后原有亲和关系直接失效。

方案2：Ingress/IngressController层配置（AWS LB场景推荐方案） #

你当前使用的AWS Load Balancer Controller（即AWS ALB Ingress实现）原生支持基于Cookie的粘性会话，粒度更细，负载均匀度远高于Service层的源IP哈希，是该场景下的首选方案。
配置方式为在auth-service对应的Ingress资源上添加指定注解，无需修改业务代码：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: auth-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    # 开启ALB目标组粘性，基于ALB自动生成的Cookie实现
    alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=86400
    # 如需自定义粘性Cookie名称，可添加以下注解，默认使用ALB内置的AWSELB Cookie即可
    # alb.ingress.kubernetes.io/target-group-stickiness-cookie: auth-sticky-cookie
spec:
  rules:
    - host: auth.your-business.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: auth-service
                port:
                  number: 80

该方案的特点：

• 优势：基于Cookie做用户粒度的路由匹配，不会出现同出口用户被路由到同一Pod的负载倾斜问题；粘性有效期可灵活配置，对业务应用无侵入
• 缺陷：配置依赖IngressController的专属能力，更换Ingress实现时需要同步调整配置规则。

Service层不需要做任何特殊配置，保持默认的sessionAffinity: None即可，核心逻辑如下：

• AWS Load Balancer Controller默认会以IP模式将Service关联的所有Pod直接注册到ALB的后端目标组，ALB自身会维护「用户Cookie <-> 后端Pod IP」的映射关系，请求到达ALB时就已经确定了要转发的目标Pod，后续转发过程中Service仅做常规的数据包转发，不会修改ALB已经选定的目标路由。
• 注意避坑：如果你的AWS LB Controller配置为Instance模式（即ALB先转发请求到节点NodePort，再由kube-proxy转发到Pod），此时绝对不能在Service层开启ClientIP亲和性，否则kube-proxy的二次哈希路由会打乱ALB已经选定的目标Pod，导致粘性完全失效。

关键提醒：严禁同时在Service层和Ingress层开启粘性会话，两层独立的路由哈希逻辑会产生冲突，直接导致请求路由异常、粘性规则不生效。

选型参考 #

• 如果你的集群没有固定的IngressController，或者能接受源IP哈希的粗粒度路由，选择Service层配置即可，通用性最强
• 你当前使用AWS ALB的业务场景，优先选择Ingress层基于Cookie的粘性方案，路由精度和负载均衡效果更好。

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