K8s 的 sessionAffinity: ClientIP 失效主因是流量路径中 IP 被 SNAT 或 Ingress/云 LB 二次转发掩盖；实操需绕过 Ingress 直连 ClusterIP、确认 kube-proxy 模式、合理设 timeoutSeconds（推荐 10800），并应用层用 Cookie+Redis 补足会话保持。
为什么 sessionAffinity: ClientIP 在 Go 应用里经常失效
不是 Go 本身不支持，而是 K8s 的 sessionAffinity: ClientIP 依赖于 kube-proxy 的实现模式和流量路径。当集群启用了 ipvs 模式（默认），且后端 Pod 位于不同节点时，ClientIP 可能被 SNAT 掩盖；更常见的是，Ingress 或云厂商 LB 做了二次转发，真实客户端 IP 根本没传到 Service 层。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先确认流量是否经过了 Ingress：如果用了
nginx-ingress或云 LB，ClientIPaffinity 基本不可靠，得换方案 - 检查 kube-proxy 模式：
kubectl get configmap -n kube-system kube-proxy -o yaml | grep mode，iptables模式下 ClientIP 更稳定（但性能略低） - 若必须用 ClientIP，需确保所有请求都直连 Service ClusterIP（绕过 Ingress），且集群未开启
externalTrafficPolicy: Local（它会干扰 session hash）
Go HTTP 服务怎么配合 K8s 实现真正可控的会话保持
K8s 层面的 affinity 是“尽力而为”，真要稳，得在应用层补一手：用 Cookie + 后端一致性哈希或外部 Session 存储。Go 标准库的 http.ServeMux 不带 Session 管理，但你可以轻量接入。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
gorilla/sessions配合 Redis 存储：避免单点、支持横向扩容，Store实例全局复用，别每次请求 new 一个 - Cookie 名别用默认的
session，改成带服务名前缀的，比如myapp-session，防止多服务共域冲突 - 设置
HttpOnly和Secure（HTTPS 环境下），但别设SameSite: Strict——K8s Service 域名和前端域名通常不一致，会导致 Cookie 不发送 - 如果前端是 Vue/React 单页应用，注意 fetch 默认不带 credentials，得显式加
credentials: 'include'
service.spec.sessionAffinityConfig.clientIP.timeoutSeconds 设多少才合理
这个值不是越大越好。它控制的是 ClientIP 的哈希映射缓存时间，超时后 K8s 会重新做负载均衡决策。设太短（如 60 秒），用户可能频繁跳 Pod；设太长（如 86400），滚动更新时旧 Pod 下线后，缓存还在指向它，导致 502。
创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。 时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。 关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 生产环境建议设为
10800（3 小时）：平衡稳定性与更新友好性 - 如果业务有明显会话生命周期（比如下单流程最长 15 分钟），可设为略大于该值，如
1800 - 别依赖它做“长期登录态”——它只管调度层路由，不保证应用层 Session 存活
- 修改后需滚动重启相关 Deployment，否则新配置不生效
用 Istio 替代原生 Service 做会话保持更靠谱吗
是的，但代价是引入 Sidecar 和 CRD 复杂度。Istio 的 DestinationRule 支持基于 Header、Cookie 或自定义字段的 sticky session，比 K8s 原生 ClientIP 更灵活、更可控，而且不受 kube-proxy 模式影响。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
trafficPolicy.loadBalancer.stickySession配置，优先选cookie类型（支持httpCookie和consistentHash） - Go 应用无需改代码，只要返回带
Set-Cookie: myapp-sticky=xxx的响应，Istio 就能自动识别并绑定 - 注意
maxAge要和你的 Cookie 过期策略对齐，否则 Sidecar 缓存可能比应用还“长寿” - 调试时看
istioctl proxy-status和istioctl pc cluster $POD，确认 sticky 策略已加载
真正难的从来不是配哪个字段，而是搞清流量到底经过了几层代理、每层改了哪些 header、谁在做 SNAT、谁又在删 Cookie。K8s Service 的 sessionAffinity 是个“弱承诺”，Go 应用层不兜底，线上出问题时基本只能翻 access log 对 IP+Cookie+Pod 日志三者时间戳。
