前面的章节已经实现了CI/CD，并且能成功登陆到管理后台，但整个流程中deployment的都是一个节点，现在通过dashboard对TLH服务的deployment伸缩为两个节点。
问题
-
登陆dashboard，扩容
扩容 -
查看Pod的IP地址
kubectl get pods -n tlh -o wide2.png -
重新打开浏览器访问,http://dev.tlh.com/tlh，输入正确的用户名和密码发现有的时候能登陆，有的时候不行，查看ingress的日志，发现请求到达ingress之后转发到的IP(pod)不一致：
IP地址
熟悉nginx负载均衡的同学很清楚这个是什么问题导致的，而出现该问题的原因在于，扩容之后再ingress中会进行负载均衡，每次请求可能会被转发到上游服务的不同的pod中，而该pod中的TLH服务再校验cookie的时候，发现该用户没用登陆，所以就重新跳转到登陆用户，即ingress没有保存住用户登陆的会话，导致同一cookie也会被转发到不同的pod中。 -
-
修改ingress配置文件
kind: Ingress metadata: name: tlh-ingress namespace: tlh annotations: kubernetes.io/ingress.class: "tlh-nginx-ingress" nginx.ingress.kubernetes.io/affinity: "cookie" # 设置依赖的依据，目前只能为这个值 nginx.ingress.kubernetes.io/affinity-mode: "persistent" # 设置会话持久化，不进行负载 -
重新配置
kubectl apply -f ingress.yaml -n tlh
-
重新登陆问题解决
总结
- 再使用负载均衡之后需要考虑会话保持的问题，解决这个问题的方式：
- 在ingress中保持会话
- 在服务端通过session共享的方式来处理，spring提供了spring-session的模块可以很好的解决这个问题，通过服务端将session进行持久化(如：存储到redis中)
