k8s Service会话粘性

Service资源还支持Session affinity（粘性会话活会话粘性）机制，它能够将来自同一个客户端的请求始终转发至同一个后端的Pod对象，这意味着它会影响调度算法的流量分发功能，进而降低其负载均衡的效果。因此，当客户端访问Pod中的应用程序时，如果有基于客户端身份保存某些私有信息，并基于这些私有信息追踪用户的活动等一类的需求时，那么应该启用session affinity机制。

Session affinity的效果仅会在一定时间期限内生效，默认值为10800秒，超出此时长之后，客户端的再次访问会被调度算法重新调度。另外，Service资源的Session affinity仅能基于客户端IP地址识别客户端身份，它会把经由同一NAT服务器进行源地址转换的所有客户端识别为同一个客户端，调度颗粒度粗糙且效果不佳，因此，实践中并不推荐使用此种方法实现粘性会话。此节仅用于读者介绍其功能及实现。

Service资源通过.spec.sessionAffinity和.spec.sessionAffinityConfig两个字段配置粘性会话。.spec.sessionAffinity字段用于定义要使用的粘性会话的类型，它仅支持使用“None”和“ClientIP”两种属性值。

• None：不使用sessionAffinity，默认值。
• ClientIP：基于客户端IP地址识别客户端身份，把来自同一源IP地址的请求始终调度至同一个Pod对象。

在启用粘性会话机制时，.spec.sessionAffinityConfig用于配置其会话保持的时长，它是一个嵌套字段，使用格式如下所示，其可用的时长范围为“1～86400”，默认为10800秒：

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    ClientIP:
        timeoutSeconds: <integer>

例如，基于默认的10800秒的超时时长，使用下面的命令修改此前的myapp-svc使用Session affinity机制：

$ kubectl patch services myapp-svc -p '{"spec": {"sessionAffinity": "ClientIP"}}'
service/myapp-svc patched

而后再次于交互式客户端内测试其访问效果即可验证其会话粘性效果。

/ # for loop in 1 2 3 4; do curl http://10.233.16.105:80/hostname.html; done
myapp-deploy-5cbd66595b-2lhds
myapp-deploy-5cbd66595b-2lhds
myapp-deploy-5cbd66595b-2lhds
myapp-deploy-5cbd66595b-2lhds

测试完成后，为了保证本章后续的其他使用效果测试不受其影响，建议将其关闭。当然，用户也可以使用“kubectl edit”命令直接编辑活动Service对象的配置清单。