Kubernetes--Service会话粘性

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

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

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

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

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

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

注意格式~输出后是这样的：

• 可以使用kubectl get svc myapp-svc获取相关的信息输出，都是根据前一篇'Kubernetes--Service资源的基础应用'的资源示例的基础上进行演示的哈

]$ kubectl get svc myapp-svc 
NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
myapp-svc   ClusterIP   10.108.17.20   <none>        80/TCP    46h
#这里可以创建一个临时使用的Pod对象作为交互式使用的客户端进行
]$ kubectl run cirros-$RANDOM --rm -it --image=cirros -- sh
/ #

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

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

这里在验证会话粘性效果之前先使用curl命令对myapp-svc服务的ClusterIP（10.108.17.20）和Port（80/tcp）发起访问请求测试：

/ # curl http://10.108.17.20:80/
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

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

]$ 
/ # for loop in 1 2 3 4; do curl http://10.108.17.20:80/hostname.html; done
myapp-deploy-7ffb5fd5ff-zjnpk
myapp-deploy-7ffb5fd5ff-zjnpk
myapp-deploy-7ffb5fd5ff-zjnpk
myapp-deploy-7ffb5fd5ff-zjnpk
/ # 

测试完成后将会通过输出的信息看到Session affinity机制的功用，它将同一个客户端的请求始终都转发至同一个后端的Pod对象，不过这也就意味它会影响调度算法的流量分发功用进而降低其负载均衡的效果。所以我们开头也说啦 【仅用于介绍功能及实现哦，实践中不推荐的哦~】

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