3个Pod与1个Service场景下Ingress Cookie亲和性工作原理咨询

你提到的Ingress配置确实是通过Service关联后端Pod，但实际请求并非先转发到Service再到Pod——Ingress Controller会直接对接Pod，Service在这里的作用是提供动态的Pod发现能力。结合你配置的粘性会话，完整的工作流程如下：

一、核心逻辑澄清 #

Ingress本质是集群的入口反向代理（这里用的是NGINX Ingress Controller），它的规则里指定Service，是为了自动获取该Service关联的Pod列表（Endpoint），而非把请求转发给Service的ClusterIP。Ingress Controller会定期同步K8s集群中的Service、Endpoint数据，生成对应的NGINX配置，直接和后端Pod建立通信。

二、完整请求链路拆解 #

1. 初始化：Ingress Controller同步集群资源 #

NGINX Ingress Controller作为K8s的客户端，会监听Ingress、Service、Pod的变化：

• 当你创建sticky-session-test Ingress、http-svc Service和3个后端Pod后，Controller会获取到http-svc对应的Pod Endpoint（包含每个Pod的IP和端口）。
• 根据Ingress的粘性会话注解，生成带有Cookie affinity逻辑的NGINX配置。

2. 第一次请求：建立粘性会话 #

• 客户端发送请求到stickyingress.example.com，请求抵达Ingress Controller Pod。
• NGINX匹配到Ingress规则对应的http-svc，从其Endpoint列表中按默认策略（轮询）选中一个Pod。
• NGINX在响应头中添加Set-Cookie: route=<Pod唯一标识>（标识通常是Pod的IP或哈希值），Cookie有效期由session-cookie-max-age设置为2天（172800秒）。
• 响应返回客户端，客户端保存该Cookie。

3. 后续请求：保持会话粘性 #

• 客户端再次发送请求时，会自动带上route Cookie。
• NGINX解析Cookie中的Pod标识，直接将请求转发到对应的Pod，不再执行负载均衡选择。
• 如果该Pod故障被K8s移除，Ingress Controller会更新Endpoint列表，下次请求会重新选择一个健康Pod，并设置新的route Cookie。

三、和Service层面粘性的区别 #

你配置的是Ingress层面的Cookie粘性，和Service自身的sessionAffinity（比如基于ClientIP的粘性）不同：

• Ingress粘性：逻辑在入口反向代理（NGINX）实现，通过Cookie精确绑定到单个Pod，灵活性更高（支持自定义Cookie名、有效期）。
• Service粘性：逻辑在kube-proxy的iptables/IPVS规则中实现，基于客户端IP绑定到Pod，粒度较粗，无法自定义Cookie相关规则。

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