在Kubernetes集群里运行有状态Web应用或需要登录态的服务时，如果请求被随机分发到不同Pod，用户会话就会丢失。Kubernetes提供了多层机制来解决这个问题，最常用的是Service级别的会话保持，以及基于节点或状态的亲和性调度。掌握这些配置能够显著降低后端状态同步的复杂度。
Service会话保持的原理与配置方式
Kubernetes的Service本质上是通过kube-proxy在节点上生成转发规则来实现负载均衡的。当我们在Service中设置sessionAffinity: ClientIP时，kube-proxy会记录客户端IP与后端Pod的映射关系，在设定的时间内，同一个IP的请求都会发送到同一个Pod。这种方式不需要应用层做任何改造，对无状态服务非常友好。
具体的配置体现在Service的YAML定义中，字段sessionAffinityConfig里的clientIP可以设定超时时间。默认超时是三小时，但在实际生产环境中，如果客户端IP是经过NAT或者位于同一出口网关后，大量用户会共享一个IP，此时会话保持反而会造成负载不均。因此在配置前需要确认网络拓扑结构。
下面是一个典型的Service配置示例，展示了如何开启基于客户端IP的会话保持并设置超时：
apiVersion: v1
kind: Service
metadata:
name: web-svc
spec:
selector:
app: web
ports:
- protocol: TCP
port: 80
targetPort: 8080
sessionAffinity: ClientIP
sessionAffinityConfig:
clientIP:
timeoutSeconds: 3600
从原理上看，如果集群使用iptables模式，kube-proxy会为这个Service生成一条recent模块规则来记录源IP；如果使用IPVS模式，则会创建持久连接模板。我们可以通过在节点上执行ipvsadm -Ln或者查看iptables规则来验证配置是否生效。当会话保持没有按预期工作时，首先应检查kube-proxy的运行模式和日志。
服务亲和性在调度与StatefulSet中的体现
除了网络层的会话保持，Kubernetes还提供调度层面的亲和性来控制Pod的放置位置。虽然调度亲和性不直接等于会话保持，但在有状态服务中，让相关Pod尽量靠近或者固定在特定节点，可以减少网络跳转并提升稳定性。比如通过podAntiAffinity避免同服务Pod挤在同一节点，或者通过nodeAffinity将计算密集实例调度到特定硬件。
StatefulSet是另一种与“服务亲和”强相关的资源对象。StatefulSet为每个Pod分配固定的名称和网络标识，配合Headless Service，客户端可以通过固定域名直接访问某个实例。这种方式比Service的IP会话保持更可靠，因为即使Pod重建，只要名称不变，访问入口就稳定，非常适合数据库、消息队列等场景。
以下代码展示了一个StatefulSet配合Headless Service的简化定义，注意Service中clusterIP: None的写法：
apiVersion: v1
kind: Service
metadata:
name: db-headless
spec:
clusterIP: None
selector:
app: db
ports:
- port: 5432
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: db
spec:
serviceName: db-headless
replicas: 3
selector:
matchLabels:
app: db
template:
metadata:
labels:
app: db
spec:
containers:
- name: postgres
image: postgres:14
ports:
- containerPort: 5432
使用StatefulSet时，每个Pod的DNS格式为db-0.db-headless.default.svc.cluster.local，应用层可以基于这个稳定标识做连接池绑定。与单纯依赖Service的会话保持相比，这种方案把亲和性下沉到了实例身份层面，避免了IP变化或NAT导致的映射失效问题，但运维复杂度更高，需要妥善处理存储卷的挂载与迁移。
常见配置误区与排障思路
很多工程师在配置了sessionAffinity: ClientIP后仍然发现会话丢失，其中一个常见原因是Ingress Controller没有透传真实客户端IP。例如使用Nginx Ingress时，如果没有开启externalTrafficPolicy: Local或者没有正确配置proxy_protocol，Service看到的源IP其实是Ingress节点的地址，导致所有用户被映射到同一个后端Pod，不仅没保持会话，还造成了热点。此时需要结合Ingress和Service两端一起调整。
另一个误区是认为会话保持可以替代数据层面的状态共享。实际上Kubernetes的会话保持只是网络转发策略，当后端Pod因为滚动更新被删除时，原有映射会失效，用户依然会被踢出。对于必须零中断的服务，应配合Redis等外部会话存储，或者采用StatefulSet加优雅退出来减少影响。下面的代码片段演示了Deployment的滚动更新策略，通过拉长终止宽限期来降低会话中断：
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
spec:
containers:
- name: web
image: nginx
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 30"]
terminationGracePeriodSeconds: 40
在排障时，建议按照“客户端IP是否真实、kube-proxy模式是否正确、后端Pod是否变动、Ingress是否透传”的顺序逐层验证。可以通过在Pod内启动临时TCP服务并用不同源IP测试连接，观察是否命中同一实例。只要理清了从外部流量进入到Service转发的完整链路，Kubernetes的会话保持与亲和性配置就能稳定支撑业务运行。
Kubernetessession_affinityservice_affinity修改时间：2026-08-16 16:24:14