前言

故事的起因是朋友所在的部门最近基于auth2实现单点登录，他们在测试环境单点登录，运行得好好的，但他们把单点登录上到预发布环境，发现单点登录不好使了。他们有部分系统是以授权码式接入，发现第一次登录拿到授权码进行换取token时，会提示授权码失效。而他们测试环境和预发布环境的代码是一样的。

后面朋友和我聊天，我就问朋友两套环境有存在什么不一样的地方，朋友说测试环境是单POD部署，而预发布环境是多POD部署。最后我还从朋友的口中得到一个信息，他们auth2是基于国内开源的sa-token进行实现，刚好我也玩过这个玩意儿，这玩意儿的授权码是基于cookies进行保持。我就跟朋友说可能是因为你部署了多个pod，pod的会话没保持住。然后我就跟朋友提供以下方案

会话保持方案

方案一：通过service进行配置

在service配置配置形如下内容

apiVersion: v1
kind: Service
metadata:namespace: uatname: uat-sso
spec:selector:app: uat-ssoports:- protocol: TCPport: 80targetPort: 80nodePort: 30666type: NodePort# 会话保持3小时sessionAffinity: ClientIPsessionAffinityConfig:clientIP:timeoutSeconds: 10800

其中关键配置如下

sessionAffinity: ClientIP
sessionAffinityConfig:clientIP:timeoutSeconds: 10800

通过指定sessionAffinity: ClientIP开启了session保持。当设置了session保持之后，k8s会根据访问的ip来把请求转发给他以前访问过的pod，这样session就保持住了。其中timeoutSeconds指的是session保持的时间，这个时间默认是10800秒，也就是三个小时。

不过朋友说他配置了这个之后，貌似没产生作用，因为朋友他们单点登录是通过ingress进行转发，于是就有了第二种方案

方案二：通过ingress配置会话保持

配置形如下

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:annotations:nginx.ingress.kubernetes.io/affinity: cookienginx.ingress.kubernetes.io/affinity-mode: persistentnginx.ingress.kubernetes.io/session-cookie-name: routename: uat-sso-ingressnamespace: uat
spec:rules:- host: sso.comhttp:paths:- backend:service:name: uat-ssoport:number: 80path: /pathType: Prefixtls:- hosts:- sso.comsecretName: tls.sso.com

其中关键配置如下

metadata:annotations:nginx.ingress.kubernetes.io/affinity: cookienginx.ingress.kubernetes.io/affinity-mode: persistentnginx.ingress.kubernetes.io/session-cookie-name: route

其中nginx.ingress.kubernetes.io/affinity 属性，启用会话保持, 其值仅仅支持cookie。
nginx.ingress.kubernetes.io/affinity-mode 属性，设置为persistent时，则请求一直请求至同一pods服务，设置为balanced (默认设置)则请求会使用轮询的方式至后端pods服务
nginx.ingress.kubernetes.io/session-cookie-name 属性，自定义cookie名称, 其默认设置为 INGRESSCOOKIE，但我们可自定义，如上文的route。

更多详细的配置可以查看如下链接
https://kubernetes.github.io/ingress-nginx/examples/affinity/cookie/

总结

朋友后面是通过配置ingress这种方式解决问题，本文就作为一个记录