Ingress 不原生支持 ClientIP 会话保持，因其是 L7 资源，而 IP 亲和属 L4 行为；需依赖 Ingress Controller（如 nginx-ingress 通过 upstream-hash-by 注解）或 Service 层 sessionAffinity: ClientIP 或云 LB 实现。
Ingress 本身不直接支持基于客户端 IP 的会话保持（即 L4 层的 IP Hash 或 ClientIP 亲和），这是由 Ingress Controller 实现的，且多数主流控制器（如 nginx-ingress、traefik）默认不提供纯 IP-based sticky session —— 它们更倾向基于 Cookie 的方案，因为更可靠、可跨网络环境。
为什么 Ingress 不原生支持 ClientIP 会话保持
Ingress 是 Kubernetes 的 L7（应用层）资源抽象，其设计聚焦于 HTTP/HTTPS 路由规则。而“基于客户端 IP”的会话保持本质上是 L4 负载均衡行为，属于底层转发组件（如 kube-proxy、云负载均衡器或 Ingress Controller 自身的代理引擎）的职责。
所以：不是 Ingress 资源能配置 sessionAffinity: ClientIP，而是要依赖 Ingress Controller 是否在代理层实现了类似 Nginx 的 ip_hash 指令。
nginx-ingress 中模拟 ClientIP 会话保持的可行方式
虽然官方不推荐，但 nginx-ingress Controller 支持通过自定义注解启用 IP 哈希负载均衡，绕过 Cookie 机制：
- 添加注解：
nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr" - 该配置会让 Nginx 使用客户端原始 IP（
$remote_addr）做哈希，将同一 IP 的请求始终打到同一个 upstream Pod - 需确保
use-forwarded-headers: "true"未开启，或正确配置compute-full-forwarded-for: "true"，否则可能取到的是 Ingress Controller 前置 LB 的 IP - 注意：若集群前有 CDN、NAT 网关或代理，
$remote_addr将失真，此时应改用$http_x_forwarded_for并配合白名单可信 IP 段（通过proxy-real-ip-cidr配置）
与 Service 的 ClientIP 方案对比
如果你真正需要的是“纯 IP 绑定”，更简单直接的方式其实是绕过 Ingress，改用 Service 层的 sessionAffinity: ClientIP：
- 适用于 NodePort 或 LoadBalancer 类型 Service
- 配置
sessionAffinityConfig.clientIP.timeoutSeconds控制绑定时长（默认 3 小时） - 缺点明显：受 NAT 影响大，移动网络易断连，且无法在 HTTPS 终止、路径重写等 Ingress 特性下使用
云厂商负载均衡器的替代路径
当使用云托管 Kubernetes（如 EKS、AKS、GKE），可通过 Ingress 关联的云 LB 启用 IP 亲和：
- AWS ALB：用注解
service.beta.kubernetes.io/aws-load-balancer-stickiness-type: "lb_cookie"或"source_ip" - Azure：通过
service.beta.kubernetes.io/azure-load-balancer-internal: "true"+ 后端池粘性策略 - GCP：在 BackendConfig 中设置
sessionAffinity: CLIENT_IP
这类方案由云平台底层 LB 实现，不经过 Ingress Controller，延迟更低，但失去 HTTP 层控制能力。
